Здравствуйте byur, Вы писали:
M.NET>>Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.
B>Сильно task sensetive ...
Факты на бочку! Если программа делает то, что от неё требуется, то проект закончен, если нет, то нет. Третьего не дано. Никто не будет оптимизировать программу, если за это не платят (это факт!).
M.NET>>Теоретики чего-то пишут, это точно. Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики. В любом случае знать теорию хорошо, но наступает момент, когда надо знать не то, что может технология, а то что она не может, а это как раз практика. За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах, поскольку занимаюсь реальными задачами (я, например, очень хорошо понимаю что ООП в чистом виде — это зло 
). И когда дело дойдёт до поиска работы — меня возьмут быстрее, чем человека без реального опыта (кто хочет поспорить?).
B>Рассуждение как у кодера после колледжа ... не developer'а. Взять то может Вас и возьмут, вот только толку для компании -- не много. Для разовой задачи без развития -- нет проблем. А вот для создания серъезной системы -- вы наваяете кучу кода, и потом свалите туда где больше платят. И что делать менеджеру и другому разработчику с вашей практичностью -- километровыми обработчиками OnClick? А если систему нужно будет писать потом на др. языке программирования?
Я не developer и не coder, а software arhitect
И проектирую я серьёзную систему, конкретнее, программное обеспечение для госпиталей в UK и Ireland. Пока что оно держится на 1 месте по популярности. Так что у меня есть основания что-то утверждать. Если я надумаю сменить работу, то всё будет продолжать работать, поскольку всё в умах людей, а их здесь много.
M.NET>>Резонно таскать опыт, что в проектировании выражается в форме паттернов. Но не все это могут — не каждый может быть архитектором. Code reuse — это зло, как я уже говорил. В больших системах используется генерация кода, а не его повторное использование. Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
B>Вы видите системы только с точки зрения кода ... а не с точки зрения системы.
А при чём здесь система? Я говорю, что UML может помочь в описании паттернов, но сами паттерны и без UML живут хорошо. Паттерны знать должен каждый архитектор, а вот для программеров — это желательно, но не обязательно.
B>Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?
Архитектурные паттерны — то есть как всё организовать, здесь достаточно поверхносто знать требования к системе. Затем прорабатывая детали конкретного этапа проекта, пытаемся использовать паттерны проектирования, чтобы быть готовым к возможным последующим изменениям. То что потом делают программисты, это уже их забота.
