Написал вчера пост о том, что мелкими действиями плохой проект не спасти и натолкнулся на удивительный отпор

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

А в этом посте, хочу привести один пример.

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

Внимание вопрос. Стоило ему пытаться спасаться? Я думаю - ответ “да”. Полезно ли чистить зубы? Ответ тоже “да”. Какого же фига нужно спасаться от пожара, а не чистить зубы?

То, что я хотел сказать (и в прошлом посту и в этому), что в мире есть миллион полезных вещей. В программирование этих полезных вещей не меньше.

Сделать ВСЕ полезные вещи нереально. Следовательно нужно расставлять их по приоритетам. Зачастую приоритеты зависят от сложившейся ситуации.

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

Из моего лично опыта, если человек делает даже приоритет N2, вместо приоритета N1 - это уже обычно на длительном отрезке времени ведет к проблемам. Если человек делает приоритет N10 , вместо приоритета N1 - то это полный пипец (даже на коротком участке времени)

Резонный ответ из зала. Но, все равно, лучше делать N10, чем N20 или чем вообще ничего не делать.
Моя саркастическая фраза: Да, конечно, в момент пожара лучше чистить зубы (N10), чем читать газету(N20). Это гораздо эстетичнее и красивее.

Опять ответ из зала: Так, что же вообще ничего не делать? Я скажу так, что если кто-то не решаете приоритет N1 или N2, то толк от человека фактически равен ничего не деланию. А если этим еще и расходуются деньги фирмы на деланье приоритета N10, то лучше вообще чтобы такой человек ничего не делал (был уволен).

Я когда-то уже писал о рефакторинге тут.

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

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

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

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

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

И вот эту идею уже похерил я (не будучи даже главных разработчиком на проекте). И собственно я и сейчас готов отстаивать бессмысленность идеи. С одной стороны, вроде ясна логика студента, блин если нельзя сделать все красиво и качественно, то давайте делать, хоть что-то красиво и качественно. Но, тут есть одно «Но».

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

Вторая аналогия. У человека перелом ноги, малярия и чесотка. Нам нужно его вылечить. Имеет ли смысл человеку для лечения давать детскую дозу витаминку C?

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

Так вот, возвращаясь к коду. Если код плохой, то его нельзя вылечить витаминкой C (правильным именование переменных), его можно лечить только более серьезными лекарствами (например понемногу начать разгребать/рефактирить кусочки проекта).

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

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

P.S. Несколько вещей, которые были затронуты в комментариях. Отвечу сразу всем.

- Откуда вязалась неделя?

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

- Был ли это legacy проект?

Проект, содержал legacy части, но сам он не был legacy. Причем, его не собирались выкидывать

- Идея, не прогужения в гавно.

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

Если говно покрывает вас с головой, то нужно не “не погружатся” а всплывать, иначе дышать тяжело будет.

- Форматирование пробелов можно делать  автоматически

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

Остальное в комментариях.

Короткая заметка на полях.

Если вы хороший разработчик/менеджер и т.п. позаботьтесь о том, чтобы об это знали не только ваш менеджер, но и параллельные ему менеджеры или менеджеры над вашим менеджером.

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

А лучше берите деньгами, причем авансом. А еще лучше, вольные хлеба…

Мне кажется в какой-то из статей я уже задевал эту тему. Меня немного, когда пишут – компания успешно выполнила скажем 500 проектов.

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

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

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

Кстати, обычно переход уходом какого-то человека производят передачу дел и деление опыта. Это обычно полный ужас-ужас. Я видел единицы случаев, когда передача происходило нормально. Обычно, человеку который уходит уже все пофиг, человеку который принимает дела некогда, так как на нем и так лежат три проекта.

Я уже писал в статье, что накопление опыта, происходит только благодаря тому, что делаются ошибки, анализируются и потом делается правильно. Хитрость состоит, что если в компании спрашивают, почему был завален проект X, а люди отвечают, потому что Вася долб@еб его завалил (уже уволен). И при этом никто не может ответить конкретно, как его Вася завалил и почему так вышло и чем он собственно такой тупой это Вася, то вероятнее всего пришедший на его место Петя или Коля с таким же успехом завалит следующий проект.

http://victorronin.com/2008/04/14/opytnyj-znachit-oshibavshijsya/

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

Это и только это позволит компании иметь память вне людских голов.

Я опущу вопросы, какую информацию собирать и как анализировать. Для разных компаний – это будет по разному. Просто хочу сразу вскрыть основную проблему, почему фактически ни одна компания это не делает.

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

Компания N1 (США) за свое деятельность поменяла 3 или 4 офшорных фирмы. С всеми фирмами были похожие (практически идентичные) проблемы (в большинстве своем инициированные компанией N1). Каждый переход на использование новой офшорной фирмы происходил с серьезными потерями финансов (ну скажем порядка $200-300K, при оборотах фирмы в несколько миллионов) и производительности (толком даже измерять не могу). Очередной менеджер, решил, что проблема в офшоре (и решил от него избавляться), хотя на самом деле, проблема в стратегии поведения Компании N1. Таким образом, из-за отсутствия данных, я думаю суммарно фирма прибила несколько миллионов на борьбу на самом деле с достаточно простой проблемой, то, что она толком не составляла контакт. Даже, если учесть, что достаточно сложно заставить выполнять контракт фирму находящуюся в другой стране, все равно, проблема остается в том, что нигде не были записаны/озвучены точные требования, ожидания и ограничения в работе.

Итак, возвращаясь к статье. Основная проблема с тем, почему информацию не хранят, заключается в следующем:

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

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

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

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