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

[metaclass]

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

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

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


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

Comments

[vp.livejournal.com]

В случае программирования можно обойтись знанием только "языка" или "тулса" только в одном случае - если ты пишеш флеш или веб. Вот там да, действительно. Сайты будут всегда почти одинаковы по смыслу, и ничего специального знать не нуна.
А в случае работы с кровавым ентерпрайзом, то, чем занимается владелец дневника и то, чем занимаюсь я, для того, чтобы что-то родить нужно в совершенно новой предметной области конкретной отрасли экономика разбираться ЛУЧШЕ, чем специалисты этой отрасли, которые будут работать с твоей системой! Это же самоочевидно. Именно потому и возникают такие требования.
Не знаеш радиофизику? Пожалуйста, пример, как систему, основанную на RF-ID поставили на предприятии, где были помехи на этих частотах, и все пошло в зад. И т.п. и т.д.
И речь о том, что человек с фундаментальной подготовкой В СОСТОЯНИИ за ограниченное время способен разобраться в ЛЮБОЙ предметной области. Начиная от мясокомбината и заканчивая нефтеперегонкой. А кодер тупой - нет. Потому что он ограничен по определению

[guamoka.livejournal.com]

>>
В случае программирования можно обойтись знанием только "языка" или "тулса" только в одном случае - если ты пишеш флеш или веб.
<<

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

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

кстати, брукс выделяет в описываемой модели операционной бригады языковеду и инструментальщику не только отдельную, но и важную роль.

>>
Не знаеш радиофизику? Пожалуйста, пример, как систему, основанную на RF-ID поставили на предприятии, где были помехи на этих частотах, и все пошло в зад.
<<

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

[inhate.livejournal.com]

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

[metaclass.livejournal.com]

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

[guamoka.livejournal.com]

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

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

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