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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что-то никак не хватает времени написать полноценную статью. Надеюсь, завтра этим займусь.

Так что, просто выкладываю совсем необработанные раздумия.

Я прошел через несколько мелких фирм, которые вырастали. Везде были одни и те же проблемы, как быстро сделать из группки молодых программистов, группу зубастых профов.

Как по мне, правильный ответ - никак. Быстро это сделать не удастся. Можно только, медленно и постепенно и то, не все станут профами.

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

Ладно, оставим вторых. Сконцентрируемся на первых.

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

Второе, что приходит в голову - давать правильные книги. Занимает меньше времени, но гораздо менее эффективно.

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

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

Редкие налеты в виде просмотра код раз в месяц, как по мне не дают фактически ничего. Это может помочь уже толковому программисту, который и так растет каждый день, чуть ускорить рост. Но, это явно не столкнет с места новичка.

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

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

Представьте себе, идет серьезные переговоры в кабинете директора. Приехали большие потенциальные заказчики. Без стука, заходит завхоз в грязных сапожищах, ничего не спрашивая, подходит к директору и заявляет: “Э… тут ручка поломалась, нужна десятка, чтобы купить новую”, директор извиняется перед заказчиками, начинает рыться в портмоне, находит десятку, отдает завхозу. Через десять минут тоже самое повторяет с фразами «Закончилась туалетная бумага» или еще чего-нибудь. Ну, как вы догадываетесь переговоры проходят, ну очень успешно и больше о этих заказчиках никто ничего не слышал.

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

Как вы считаете, должен ли директор:

- Тратить свое время на выдачу такой суммы лично

- Контролировать траты таких размером

- Прерываться, на решение вопросов данного уровня

Я искренне надеюсь, что вы ответили «нет».

Теперь другой вопрос, почему, собственно, он не должен этого делать? Да потом, что час работы директора, скажем условно стоит $60/ч (это не его ЗП, а скорее стоимость его воздействия на фирму). Так, вот для того, чтобы решить даже такую мелочь, он отвлечется скажем на 5 минут (это еще хороший случай, так как, если мысля думается и ее сбить, то она долго может не возвращаться). Как результат, он потратит $60/ч*5/60 = $5, для того, чтобы даже не сэкономить, а просто выдать $2. В результате туалетная бумага, купленная завхозом, по цене будет ближе к золотой парче

Соответственно напрашивается несколько выводов:

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

- У него есть предел до который он имеет тратить не спрашивая (например, $30 в месяц).

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

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

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

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

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

Идем дальше, добираемся до менеджеров. И вот тут мысль спориться окончательно, почему-то, если программист имеет право тратить $5/месяц без запросов вперед, то менеджеру могут выделить ну дай бог $7/месяц, ну в самом крайнем случае $10.

Опять же, менеджер уже способен запороть не просто один проект на пару тысяч, а штучки три проекта, которые на нем висят, включая работу еще штук 5 программистов, которые ему подчинены. Но опять же выделить ему лимит в $50/месяц…. у… не, страшно и низзя.

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

Как мне кажется, примерная формула предела для большинства IT работников, что человек имеет тратить в месяц до 1% * количество людей в иерархии подчиненных ему (включая самого человека) * на свою ЗП. Для программиста - это 1% от его зарплаты, для менеджера младшего менеджера с 5 подчиненными получается 6% от его ЗП, для старшего менеджера – 5 прямых подчиненных у каждого из которых 5 своих – 26% от ЗП.

Замечу, это не ограничения сколько он вообще может потратить, это ограничения сколько он может тратить и оповещать об этом пост-фактум.

Завхоз в этом смысле исключение, так как заранее известно, что ему понадобиться больше, чем 1% от ЗП.По этому поводу ему можно/нужно выставить сумму прямым образом (без учета формулы). Кстати, он и не IT работник, так что формула к нему пожалуй еще и поэтому поводу не применима.

P.S. Пост основан на реальных событиях. Это просто меня убила сегодня ситуация, когда менеджер у которого суммарно в иерархии порядка 30 человек (с зарплатами от $4k до $8k в месяц) пошел к своему начальнику, чтобы тот одобрил трату в $1.2k.

P.P.S. Прошла неделя с тех пор как начала обсуждаться это покупка. Она уже прошла через менеджера, фин. директора, админа и пока еще не куплена. Магазин где ее можно купить находится в 5 минутах от офиса.

P.P.P.S. После полторы недели, меня достало ожидание, пошел к фин. директору и вопрос был решен в течении 5 минут. Замечу, что на разные разговоры и обсуждения уже было потрачено часа полтора.

Очень у многих (особенно  у наемных рабочих) есть проблема, что они не ценят/не оценивают свое свободное время.

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

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

Тем не менее, нужно иметь какую-то внутреннюю оценку стоимости своего нерабочего времени. Тогда получается, если вы имеете оценку нерабочего часа условного говоря $2/ч, то вы не станете тратить 4 часа, на поиск скидки в $2 доллара.

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

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

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