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

[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

[russian-sla.livejournal.com]

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

[vit-r.livejournal.com]

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

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

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

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

[russian-sla.livejournal.com]

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

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

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