Кто тут писал про тупую работу кодера от забора и до обеда?

[metaclass]

[...]
Это форум программистов, или форум детского сада?

Программист - это такое существо, которое обязано разбираться в очень широком диапазоне тем. Кроме того, программист - это инженер, а общее инженерное фундаментальное образование, вообще-то, предполагает и знание ТРИЗа, и знание методов иммитационного моделирования, и теорию вероятности с мат. статистикой, и основы экономики, и много чего прочего. Без такой базы программист дерьма не стоит, поскольку заказчику проще самому сделать, чем недоучке объяснять свою предметную область.

Жаль, нельзя на собеседовании потенциальных сотрудников подвергать методам Луговского. Потому что c вышенаписанным я согласен полностью, а не руководствуюсь этим делом на работе, чтобы не сузить множество потенциальных новых сотрудников до пустого.


PS: Программист выполняет функции инженера: проектирует и реализует устройства, выполняющие некую функцию. То есть, программист - это инженер. А если не инженер - то это и не программист, поскольку он не может выполнять своих служебных обязанностей.

Comments

[inhate.livejournal.com]

В "кровавом ентерпрайзе" есть пара понятие аналитика/постановщика задач - который каленым железом вытягивает из заказчика его предметную область, как это должно работать, творчески перерабатывает, пердусматривает, зачастую верно предсказывая фичи которые могут потребоваться и основу которых дешевле заложить на начальном этапе - и выражает это в виде ТЗ, по которому уже рисуется UML.
Я искренне считаю крайней степенью идиотизма использовать рабочее время человека способного лучше чем заказчик понять проблему (а это действительно надо для создания успешной системы) в качестве простого кодера, ровно как и нанимать оферквалифайд кодеров. Хватит с кодера и владения _своей_ предметной областью - производства ПО - абы понимал как работает релиз-цикл в данной конторе, делал свою часть и не мешал другим.

[metaclass.livejournal.com]

Я не видел ни одного человека, который, не понимая предметной области, мог бы написать что-то вменяемое. Если использовать UML и прочие методы формализованной постановки и проектирования - это практически то же самое что писать код самому. Сложность разработки подробного проекта, необходимой для его передачи кодерам практически эквивалента сложности писания самому. Плюс оверхед на коммуникацию.

[guamoka.livejournal.com]

>>
Я не видел ни одного человека, который, не понимая предметной области, мог бы написать что-то вменяемое.
<<
все разработчики, участвующие в определенном проекте, так или иначе начинают разбираться в предметной области. но от этого они не становятся экспертами, и не обязательно способны на постановку задачи в рамках всей системы. однако они способны помимо своих прямых обязанностей имплементации принимать квалифицированные решения в рамках подсистем/компонент потому что а) обладают необходимыми знаниями, полученными от аналитика; б) знают, что и у кого спросить по предметной области в ситуации неопределенности.

>>
Если использовать UML и прочие методы формализованной постановки и проектирования - это практически то же самое что писать код самому.
<<
нет. далеко не одно и то же. потому что UML диаграмы могут писаться с различной степенью детализации, и зачастую в них нет необходимости специфицировать каждый программный шаг или же особенности имплементации. да и не всегда получится, или же не всегда имеет смысл.
наличие кратких и исчерпывающих UML диаграм или других проектных документов помогает не только проектированию и специфицированию продукта, но и гарантирует, что при дальнейшем развитии продукта логика не будет потеряна, вновь пришедшие проектировщики и разработчики смогут увидеть систему в целом и по отдельности в более сжатые сроки. кроме того, делегирование обязанностей- обычная и оправдывающая себя практика в более-меннее крупном и _управляемом_ проекте.

ЗЫ. имхо, оба утверждения скорее субьективны, и обусловлены небольшими размерами конторы, в которой над одним и тем же продуктом в течение многих лет всегда работало не более двух человек. обычно, проблемы наподобие "кругом одни тупицы неразумные" начинают возникать, когда назревает необходимость просто принять на работу нового человека взамен ушедшего, или расширить продукт и привлечь к разработке новых людей. увы, не вы первые, не вы последние.