Объяснительная

[vit_r]

Лет 15 назад я был страшным фанатом всяких волшебных МЕТОДОВ. Потом посмотрел, как работают настоящие архитекторы и инженеры (те, которые в камне и в железе); почитал, как первые версии CMM на студентах доказывались; покрутился в больших и очень сертифицированных фирмах; пообщался с теми, кто сертификации придумывает; ознакомился с уровнем "среднего программиста". Сейчас я стал слишком циничным, чтоб воспринимать многие вещи всерьёз.

Ниже собраны разрозненные замечания, в основном из обсуждения

1. Самый типичный, самый повсеместный и самый тайный паттерн поведения:
   - Мы и UML. Мы и шаблоны. Мы и javadocs. Мы и V-Modell. Только сейчас фаза у проекта важная. Так что нам ерундой заниматься некогда. Но как только, так сразу исправим.
   Типичная ситуация в любой фирме. Если в мелких и простых на документацию, от который код ушёл далеко-далеко просто держат как прикольные воспоминания, то в крутых и сертифицированных нанимают людей, которые занимаются восстановлением связей и смысла. Ну, в том объёме, в каком это возможно.
   Потом эти филькины грамоты подсовываются сертификаторам со словами Как положено. Как по процессу. Вот на основании этих документов мы код и делали.
   Чего-то я сегодня ядовит. Слова можно и помягче выбирать... Ладно. Репутация давно испорчена, так что выдам без реверансов.
2. Молящиеся на agile любят проповедовать, что документы, особенно документы по архитектуре и общему взгляду на систему делать вообще не нужно.
   Да. Это правильно и хорошо. Но до тех пор, пока заказчик на столько глуп, что получает кайф от процесса создания, а не от результата.
   Впрочем, большинство заказчиков глупы, отделов ИТ боятся и, избегая опасности выглядеть глупыми и некомпетентными, резонные важные правильные вопросы не задают.
3. Комментарии документацию не заменяют. Точка.
   В большинстве контор комментарии, если и пишутся, то объясняют только самый нижний уровень - проблемы в коде. Причём, исправления комментариев сильно отстаёт от изменений в коде.
   А, чтоб меньше было переписывать, комментировать стараются поменьше.
   Опытные, конечно, пишут много. Но в смысле не наделать в будущем ошибок, чтоб компилятор не ругался и баги не вылезали. То есть, работают на отдел тестирования, а не на клиента.
4. Там, где оформление чётко задано стандартами, большая часть комментариев по сути своей является просто информационным шумом. Тем более прикольным получается UML с документацией по дизайну.
5. Комментарии "для других" большинство делать не умеет. Как правило, "стиль" берётся из учебников. А там пишут
   i++; // i = i + 1
   Причём, код давно изменился, а студенческие комментарии остались.
6. Времени для написания комментариев и приведения кода в "эстетический" порядок всегда не хватает. В большинстве случаев программа "нужна вчера". То есть, в работу идёт первая функционирующая версия. "Причёсывание" кода - это инвестиции в будущее, которые для большинства менеджеров являются потерями. Потому как ресурсов (как правило людских) не хватает.
7. В большинстве случаев "приведение в порядок" - это не повышение понятности, читаемости и устойчивости к изменениям, а выполнение формальностей и написание кучи отчётной документации.
8. Комментарии бывают разные. Самый полезный комментарий, что я видел - это "!!!". (В своё время я достаточно много копал этот вопрос)
9. По сути, комментарии - это способ коммуникации во времени. Практически, этот аспект никто мерить не умеет. Каждый пишет, "как умеет".
   В школе всех учат писать, но писателей - единицы, зато графоманов полно. C комментариями так же. А с учётом того, что у большинства программистов умение писать связные человеческие тексты не развито, ситуация ещё острее стихоплётсва.
10. Самые хорошие и самые плохие примеры комментирования прислали мне профессора. В одном случае всё было понятно. То есть, любая уборщица, владеющая английским языком, могла сказать, что модуль делает. В другом было что-то невообразимое, и на мой вопрос автор ответил "Тут все с высшим образованием. Так что разобраться любой сможет"
11. Open Source - это не альтернатива. Потаённых знаний дофига. Только они на внешних носителях - в форумах, блогах и пр. И никакого давления и сроков промышленной разработки.
    Если сравнивать эффективность, даже средненькая промышленная разработка эффективнее и результативнее. Не забываем, что в реальной коммерческой фирме всё то время, которое на блоги, форумы, мейлы и тусовки, придётся оплачивать.
12. "Промышленная разработка" - это в общем понимании не "красивое", а для зарабатывания денег. То есть, как делают большинство в большинстве мест.
    Не надо ссылаться на работы теоретиков, рассказывающих сказки про конвейеры. Конвейер в ИТ - это нарезание дисков или инсталляция на хард. Остальное - разработка нового. А это уже инженеры, которые свои изделия в мастерской напильником дорабатывают.
    Да. На самом деле напильником. И в руках подержать надо. Потому как все чертежи - это модель. Модель не полная. Даже 3D не пощупать, вес на руке не прикинуть.
13. Методики и практики - это не для качества и блага клиентов. Это только попытка внести в мозговую деятельность элемент предсказуемости. КПД работы может повышаться. А может понижаться.
    Второе более вероятно, потому как люди продолжают делать, что делали. Но при этом вынуждены прятать подпольные процессы под горами отчётной документации.
    Сами внедрители - люди адекватные. И, конда не перед клиентами на трибуне, вполне говорят в приватном порядке, что получается плохо. Всё в основном для сертификатов и отчётов.
14. В принципе, набрав очень хорошую команду в менеджмент и хороших программистов для разработки, сделать можно всё, что угодно. Только оно всё разваливается, как попадает в массы.
    И стоит помнить, что ошибки, катастрофы и неудачи в "научные статьи" и "сборники лучших практик" не попадают. Да и, вообще, информация редко когда проползает вовне. Потому как большинство ошибок - ошибки менеджмента. А они не любят говорить о себе плохо.
15. Естественно, в любой методике дофига всего разумного и правильного. Только оно всё достаточно ортогонально. И внедрением занимаются консультанты, которые помимо своей религии приносят какие-то полезные знания.
    Переход от полного идиотизма к более разумному завсегда даст прирост производительности, удовлетворённости и эффективности. Да и про эффект мотивации от изменений забывать не стоит.
16. CMMI 5 - это набор красивых буковок. Для клиентов все эти сертификаты в смысле сроков, цены и удовлетворения никакой пользы не приносят.
17. Бумажки хорошо прикрывают задницу менеджеру закупающей конторы. Потому их и любят. А во многих областях они обязательны.
    В этом смысле всё равно, что сертифицировать: CMMI, SCRUM или танцы с бубнами.
    Эффективность и польза? Когда консультанты начнут продавать новое всепобеждающее, они найдут убедительные аргументы.
    Для бубнов тоже найдут. И в цифрах измерят.
18. При введении сертификатов, стандартов и методов лучшие люди начинают покидать фирму. И совсем не потому, что они из себя все такие талантливые и свободные. Просто эффективность их работы снижается из-за разрушения их внутренних устоявшихся процессов.
19. У меня подозрение, что индийцы потому стали лидерами по сертифицированности, что у них национальная особенность - во всех ситуациях кивать головой и говорить "Да".

Comments

[luchnik76.livejournal.com]

ХVII и ХVIII по личному опыту справедливо и для других отраслей.

[vit-r.livejournal.com]

Бюрократия - она везде одинакова. Да и принципами Правильного Менеджмента Не Взирая На Область Деятельности гарвардская школа заражает все отрасли индустрии. Сейчас наблюдаю, как эффективные менеджеры уничтожают немецкую систему здравоохранения.

[yajohn.livejournal.com]

По поводу документации исходников. Последний проект делал на FALK. Небольшая задача, 25 человеко дней. Исходники документировал по ходу, достаточно подробно. В конце их программист сделал ревью. То бишь просмотрел все ключевые моменты и отметил все что не понял. 30 с чем-то TODO пунктов. Которые я откомментировал и отметил как DONE, соответственно. После этого (впервые в моей жизни) исходники были признаны "достаточно документированными".

п.с. среди комментариев был в частности и "а почему здесь не применен патерн ХХХ?". Ответ (в виде комментария) "потому как здесь это из пушки по воробьям" всех вполне устроил.

[vit-r.livejournal.com]

среди комментариев был в частности и "а почему здесь не применен патерн ХХХ?".

В смысле "почему?" или в смысле "а знает ли автор вот такое красивое слово?" :-)

[alexott.livejournal.com]

подпишусь под каждым словом...

[vit-r.livejournal.com]

Судя по концентрации индусов, а теперь и китайцев, в американских фирмах, разницы особой нет, Штаты или Индия.

[russian-sla.livejournal.com]

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

[vit-r.livejournal.com]

В определённой среде решающая посылка: "хочу Евроремонт". Чтоб потом всем рассказывать, сколько это стоило.

У руководства в ИТ задачи примерно аналогичные.

Ещё проблема в том, что тем, кто понимает, МЕТОД, МЕТОДИКА и бумажки не нужны. Потому как они на третьем уровне по Cockburn и собирают своё, оптимальное для их задач и условий. Хотя, подстройка под любые модели, методы и пр. для них наиболее безболезненна.

В этом смысле мне нравится идеология Тойоты. Правда, они рассказывают только о конвейере, а методики инженерных отделов держат в строжайшем секрете.

[russian-sla.livejournal.com]

"В определённой среде решающая посылка: "хочу Евроремонт". Чтоб потом всем рассказывать, сколько это стоило.

У руководства в ИТ задачи примерно аналогичные."

Абсолютно в точку! :) В российских-белорусских-украинских IT-компаниях этот "подход" силён черезвычайно (есть с чем сравнивать). не всегда даже вопрос в том, чтобы рассказать - сколько это стоило. Вопрос именно в том, чтобы показать - а я круче многих, у меня сделан евроремонт.

[pmant.livejournal.com]

***При введении сертификатов, стандартов и методов лучшие люди начинают покидать фирму. И совсем не потому, что они из себя все такие талантливые и свободные. Просто эффективность их работы снижается из-за разрушения их внутренних устоявшихся процессов.***

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

[vit-r.livejournal.com]

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

Благо, им есть куда уходить.

Худшие как раз остаются.

[(Anonymous)]

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

[vit-r.livejournal.com]

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

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

[sab123.livejournal.com]

Чтобы писать хорошие комментарии, надо сначала читать много чужого кода. Читать код нигде не учат, и вообще о важности этого занятия в институтах не говорят. Вот так вот, "чукча не читатель, чукча писатель". Опенсорс в этом смысле чрезвычайно полезен, поскольку предоставляет уйму кода для чтения.

[vit-r.livejournal.com]

Полезен-то полезен. Но не стоит забывать, что пишут его, когда есть свободное время. И в больших проектах проходит он столько ревью, сколько в нормальных компаниях денег не хватит.

[sab123.livejournal.com]

Э-э-э, я не уверен, о чем мы тут спорим. Но на всякий случай :-) Во-первых, код, написанный в свободное время по определению лучше, чем код, написанный быстрей-быстрей чтоб уложиться в план. Во-вторых, вроде никаких особенных ревьюев я никогда не видел, даже в больлих проектах. Другое дело, что если что-то где-то криво, то с хорошей уверенностью в больших проектах найдется кто-то, кто это исправит.

[vit-r.livejournal.com]

Время - самый важный ресурс в реальных проектах. Так что код открытый хорош, но не оптимален. В смысле эффективности в терминах доллар / доллар.

[sab123.livejournal.com]

Чтобы учиться читать - это перпендикулярно. Не гвооря уже о том, что множество открытого кода пишется на самом деле вполне коммерческими способом.

[vit-r.livejournal.com]

Обычные комментарии и стили берутся из книг. Особенно, для новых языков.

А там авторы загоняют под формат страницы и чёрно-белого текста.

Потом, код не читают. С ним работают.
Но это, как-нибудь в другой раз.

[sab123.livejournal.com]

Вот именно об этом речь: брать комментарии из книг - глупо. Смысл комментариев - помогать в чтении кода. Чтобы понимать, как комментарии помогают в чтении кода, надо иметь практику чтения кода.

И его, естественно, читают. Никто же не пишет программы с нуля. Всегда приходишь - а там уже многия тыщи строк есть. Чтобы с этим кодом работать, его надо сначала прочитать и понять.