Я когда-то уже писал о рефакторинге тут.
Просто, мне вспомнилась забавная история. Был большой и достаточно жуткий проект. Жуткий в том смысле, что писан был он большим количеством людей, без какой-либо толковой архитектуры и понимания, что делает каждая часть и как они должны взаимодействовать. Причем туча кода, писалась, хоть и толковыми парнями, но все же пока студентами, что опять же придавало проекту дух … э… ну, в общем студенческий дух. То есть код, вроде есть, вроде что-то делает, но скорее все это было похоже на переросшую (причем дико) лабораторную работу.
И вот один из продвинутых студентов (не я 🙂 ) , начал выбивать рефакторинг, чтобы переварить всю эту кучу (хотел сказать говна, но решил сказать кода) в что-то более менее удобоваримое. Ну и начал он выбивать под это время. Естественно проект не маленький, поэтому время он пытался выбить тоже немало (уж очно не помню, но что-то типа 6-9 ч/м), на что в общем ему ответили, что иди мальчик – подыши свежим воздухом, столько бабок мы лучше в пофикс проекта вложим или скажем в новую функциональность.
Кстати, что меня, прикололо (и послужили поводом для статьи), то, что главный разработчик тоже похерил эту идею на корню (хотя он уж точно должен был поддержать). Не буду дословно цитировать, но что он сказал – что код нормальный, единственное иногда непонятно, что он делает. Поэтому единственное, что надо — больше комментариев писать.
Да, так вот, во первых могу с высоты нынешнего полета заверить – нормальностью там и не пахло. Как я уже писал, полное отсутствие архитектуры, кучу дублирования, жесточайшие заплатки на заплатках.
Вернемся к тому продвинутому студенту. Товарищ поразмыслил и сказал, блин если вы такие жлобы, что не хотите давать 6 месяцев, то давайте хоть все начнем придерживаться единого стиля написания (название переменных, отступы и т.п. штучки).
И вот эту идею уже похерил я (не будучи даже главных разработчиком на проекте). И собственно я и сейчас готов отстаивать бессмысленность идеи. С одной стороны, вроде ясна логика студента, блин если нельзя сделать все красиво и качественно, то давайте делать, хоть что-то красиво и качественно. Но, тут есть одно «Но».
Две аналогии. Перед вами стоит жуткий, шатающийся дом с выбитыми окнами, поросший бурьяном и без крыши. Ваша задача его привести в божеский вид и у вас нету денег чтобы сразу сделать это целиком. Вопрос – имеет ли смысл вытирать ноги при входе в дом и вешать красивые зановесочки на окна?
Вторая аналогия. У человека перелом ноги, малярия и чесотка. Нам нужно его вылечить. Имеет ли смысл человеку для лечения давать детскую дозу витаминку C?
Оба раза можно ответить – ничего плохого действие не принесет, но задачу это действие сто процентно не решит и вероятнее всего будет просто трата времени и денег (в пример с домом гораздо более актуально, наверное в примере с человек чуть более спорно).
Так вот, возвращаясь к коду. Если код плохой, то его нельзя вылечить витаминкой C (правильным именование переменных), его можно лечить только более серьезными лекарствами (например понемногу начать разгребать/рефактирить кусочки проекта).
Иначе все эти именования переменных будут простой тратой времени. Можно вполне положить скажем неделю, на то, чтобы все переменные назывались правильно. А можно ту же неделю положить на то, чтобы расчистить один модуль. Как по мне второе, гораздо более эффективно.
В общем, это я о том, что не всякая польза хороша. Важно делить результат пользы на потраченные усилия. И как только это соотношение падает меньше определенного значения, то вероятнее всего – это дело, хоть теоретически и полезно, на практике оно так же бесполезно, как вытирание ног, перед захождение в грязный, заброшенный дом.
P.S. Несколько вещей, которые были затронуты в комментариях. Отвечу сразу всем.
— Откуда вязалась неделя?
Идея паренька была не просто придерживаться новых мелких хорошестей, но и изменить текущий код, чтобы соответствовать им. Именно это и была та самая неделя (на изменения)
— Был ли это legacy проект?
Проект, содержал legacy части, но сам он не был legacy. Причем, его не собирались выкидывать
— Идея, не прогужения в гавно.
Я бы сказал, есть тонкая разница. Если вы по колено в говне, то идея не погружения очень разумная.
Если говно покрывает вас с головой, то нужно не «не погружатся» а всплывать, иначе дышать тяжело будет.
— Форматирование пробелов можно делать автоматически
Да. Я об этом знаю. Там было больше чем форматирование. Там был достаточно длинный список в основном визуальных изменений, многие из которых нельзя было автоматизировать.
Остальное в комментариях.
Вы привели неправильные аналогии. Логичнее такая
—
Если дом грязный, и в будущем мы предполагаем его полностью отмыть, то имеет ли смысл добавлять фикалий в него сейчас?
—
По моему опыту, если уже есть беспорядок, то просто недобавлять в него ещё говна — уже хорошо.
Та идея, что Вы похерили, была наиболее здравой в сложившейся обстановки. Она смогла бы ощутимо снизить скорость погружения в дерьмо проекта, а значит могла бы дать шанс не только вытащить его из грязи но и привести к более интересным результатам.
+5000
Я написал P.S. к статье.
Самая здравая идея была понемногу постоянно рефакторить проект и таким образом приводить его в божеский вид.
В рефакторинге переименнование переменных и т.п. мелкие визуальные улучшения не является приоритетом номер 1.
Приоритет N1 — архитектура, убрать дублирование, убрать мертвый код.
Поэтому предложение, которое затрагивает приоритет N3, как мне кажется не актуально.
Абсолютно согласен с предыдущим комментатором.
Я отписал P.S. к статье и комментарий к предыдущему комментарию.
Прав автор статьи и прав первый комментатор. Всё зависит от того на сколько данный проект важен, нужен, перспективен. После прочтения напрашивается вывод, что данный проект наследие прошлого, и он постепенно умирает и будет заменён в будущем другим проектом.
Да, возможно есть ситуации, когда решение переименования переменных будет логично.
Я таких еще не видел.
Насчет legacy, я в P.S. написал.
Стиль написания ИМХО с одной стороны не очень важен, но с другой стороны он воспитывает дисциплину разработчиков и привычку следовать каким-то канонам и правилам. То есть если не рефакторинг, то хотя бы не писать ничего нового ужасного.
Я считаю, что важно воспитывать понимание/написание архитектуры, а не правильное именование переменных.
Разработчик предлагал изменения в новом коде? Тогда откуда неделя? Проблема с «отступами и т.п. штучками» решается почти полностью автоформатированием кода в той или иной форме. Обсудить ваши стили, прийти к общему, дать задачу инициатору загнать это в автоформатер. Работы не день, и, на мой взгляд, только выиграете.
Беда в том, что автоматическое форматирование, каким бы хорошим оно ни было, все же автоматическое, не учитывающее всех «нюансов». Естественно можно как-то настроить, как-то подхачить. Я вообще сторонник тотального автоформатирования ибо это, по моему, самый простой способ удерживать единый стиль. Но есть люди, и как показывает опыт,- таких немало, которые говорят: «да ну его (автоформаттер), он мне всю красоту портит!» И вот тут уже нужно как-то достигать единства на уровне идеологии. Подозреваю, что единственный верный вариант — диктатура
пролетариатаединого стиля.Есть такие, которые говорят — да ну его и ставят по середине SLSB System.exit(0); Это к тому, что всякие есть. Только автоформатер в этом не виноват 🙂
Я написал P.S. к статье. Да он предлагал изменить текущий код.
Т.е. с одной стороны стиль не важен, с другой — без него новое получается ужасным 🙂 Что-то я запутался совсем.
О…. Это отличное запутывание.
Я сейчас мелкую статейку напишу, о нужно/важности и приоритете.
Холивары, холивары 🙂
Господа, как правильно заметили 2 товарисча в комментах,
— «Она (идея с `чистым кодом`) смогла бы ощутимо снизить скорость погружения в дерьмо проекта»
— «Проблема с “отступами и т.п. штучками” решается почти полностью автоформатированием кода в той или иной форме.»
Так что я думаю, что это была здравая идея.
Понятно, что не стоило ограничиваться ей одной и таки выбивать рефакторинг 🙂 с другой стороны, непонятно, кто бы его провел из всей студенческой бригады.
Еще могу заметить вот что. Все любят очень долго говорить о том, что «прототипы — в газенваген», что «счас мы РАхитектуру-то сделаем, фигли нам».
А на деле часто бывает так- сначала пишется proof of concept, покрывающий 80% mainstream use-case’ов, потом на этом mock-up’e срочно растят продукционный код, а затем все отказываются от рефакторинга и улучшения, потому что «ёмайо, тут ищщо багфиксов гора!!» — дружно клепают заплатки на оставшиеся 20% особых случаев 🙂 Такими микроспринтами (80% функций -> прототип вроде работает —> продукционный код —> 20% костыли-заплатки) работает значительная часть моих знакомых — и в большом, и в малом. За свою недолгую карьеру IT сам стал свидетелем.
Грустно 🙁
Стиль не важен сам по себе. Важна дисциплина в мозгах если ее планируется как-то использовать в будущем. Если не планируется, то не стоит морочить головы разработчиков.
Уважаемый Виктор,
мне предельно ясна стержневая идея стороны разработчика: удержать проект на плаву и довести его до «успешного» завершения. А то, что вместо ёлки получился арбуз, так это мы исправим первым же патчем…
Очень приятно было прочесть комментарий meowth. Когда я сам был студентом, и изучал проектирование, мне тоже казалось, что quick-start — это правильно и верно. Грустно, что из этих студенческих пеленок не выбралось большое количество настоящих компаний разработчиков. Страшно, когда они занимаются не разработкой хлева, а строят здание больницы, если вы понимаете о чём я…
Если бы мне поручили руководство вышеописанным проектом на той стадии, которая описывается постом, я бы затребовал у высшего руководства отмены проекта (cancel), либо же полного его рефакторинга: исходя из вышесказанного — сроком в один год.
Именно: либо пан (толковый проект), либо пропал (отмена проекта).
Что же до второго предложения студента (структурное программирование), проект бы оно не спасло, и не вылечило. Но принять его нужно было обязательно. Если зрелых кадров нет, это еще не значит, что их нельзя воспитать.
На месте руководства, я бы затребовал у тебя покинуть компанию 🙂 Я с подозрением отношусь к людям, которые «исходя из вышесказанного» называют сроки «в один год». Почему не два?
Георгий, будьте так любезны, потрудитесь полноценно представиться, прежде чем демонстрировать свои навыки управленца.
Принимать решения в условиях ограниченной информации для руководителя любого уровня является необходимостью. Если просят «6-9 ч/м» на рефакторинг, то это крупный проект с большими проблемами (об адекватности кадров, дающих экспертную оценку речи не идет: работать нужно уметь с теми, кто есть), и потому для реабилитации проекта необходимо не только запрашиваемое время, но и буфер рисков, который в условиях имеющейся определенности имеет соответствующую погрешность. Для старта проекта она может достигать 200%, для 2.0 проекта в движении риски более 50% говорят о его нецелесообразности. А уж проект 1.0 в исполнении группы студентов вообще планированию не поддается.
>Если бы мне поручили руководство вышеописанным проектом на той стадии, которая >описывается постом, я бы затребовал у высшего руководства отмены проекта (cancel), либо же >полного его рефакторинга: исходя из вышесказанного — сроком в один год.
>Именно: либо пан (толковый проект), либо пропал (отмена проекта).
С этой частью согласен.
>Что же до второго предложения студента (структурное программирование), проект бы оно не >спасло, и не вылечило. Но принять его нужно было обязательно. Если зрелых кадров нет, это >еще не значит, что их нельзя воспитать.
А вот с этой нет. Трата денег для того, чтобы человек пошел не по верному пути и через год это осознал? М… Я не слишком за такое ратую.
Кстати, я пытался тогда объяснить студенту в чем собственно проблема каждого варианта.
Стандарт стилевого оформления кода на предприятии должен быть обязательно! Если его нет, его нужно выработать коллективно и утвердить. Я такой когда-то писал лично. Все должны писать одинаково. А не хочешь писать как все в команде — иди из команды. Зато потом получается, что код написанный восемь (!) лет назад понятен с одного взгляда. Это стоит того.
И на автоформаттеры рассчитывать не стоит — куча случаев, когда ведут себя неадекватно. Хотя и облегчают дальнейшее разгребание кода.
Хотел написать про стандарты кодирования — что это один из _непременных_ атрибутов разработки, признак выроста из «студенческих» штанов, наряду с scm и системами continuous integration типа ccnet, но уже и так копи
Хотел написать про стандарты кодирования — что это один из _непременных_ атрибутов разработки, признак выроста из «студенческих» штанов, наряду с scm и системами continuous integration типа ccnet, но уже и так копий сломано предостаточно =) чего еще раз обсуждать
Вот теперь больше похоже на холивар 🙂 Ссылка в урле. Так пойдет?
Артем, я оставляю за собой право демонстрировать все, что мне угодно. Анонимность не мешает мне иметь свою точку зрения и выссказывать.
>На месте руководства, я бы затребовал у тебя покинуть компанию.
В таком случае я могу быть спокоен за своё рабочее место. Видите ли, «ставить себя на место руководства» любит каждый, — не секрет, что у нас каждая кухарка умеет управлять государством.
Тем не менее благодарю за то, что удовлетворили мою просьбу, Георгий.
На ваши права никто не покушается, но раз взялся за гуж, не говори, что не дюж:
Поясните свою точку зрения, а также ответьте на вопрос: почему вы так уверены, что квалификации Senior Developer достаточно, чтобы принимать адекватные решения уровня топ-менеджера (например, о степени целесообразности проекта, правильности бизнес решений из спектра кризис-менеджмента, или профпригодности руководителя проектов по его экспертной оценке?). Аргументы приветствуются.
P.S. А еще вспомнился анекдот: в каждой организации есть человек, который знает что и как нужно делать. Этот человек должен быть уволен.
Ок. Давайте, доставайте свой. Померяемся. Какой смысл?
Давайте так — поверьте мне на слово, я знаю, что значит принимать решения на уровне проекта. Проходил я через это и в мелких и в крупных компаниях.
Свою точку зрения я пояснил: информации недостаточно, решение принмимать никто не застваляет, а называются конкретные таймлайны. Ничем не обоснованные, с моей точки зрения. Зачем? Зачем сотрясать воздух лишний раз?
Про ваши выпады по поводу Senior Developer: чем вам так не понравился мой title? 🙂 Ко мне на собеседование приходят тимлиды с пятилетним опытом, а послушаешь минут 15 и потом хочется спросить, что он все эти пять лет делал. А бывает и наоборот. 2 года опыта и фору многим даст еще.
И прошу вас, перестаньте переходить с одной темы на другую: я не говорил о целесообразности проекта и о правильности бизнес решений. Я сказал о том, в чем, как мне кажется, разбераюсь неплохо: если человек берет цифры из воздуха и при этом еще и требовать чего-то хочет — нам с ним не попути.
Григорий, меряться чем-либо, это несколько неспортивно, не находите?
А вот представиться, и получить представление о компетентной области собеседника — весьма информативно. Особенно перед тем, как верить на слово.
Информацию обо мне вы можете получить здесь: http://www.linkedin.com/in/prigorov
Могу предположить, что причина вашей воинственности в некорректной формулировке с моей стороны: «сроком в один год». Имелся в виду человеко-год, прошу прощения, если проблема именно в этом — мне следовало быть кокретнее.
Однако это не отменяет факта, что ваша точка зрения мало обоснована, поскольку принятие решений уровня топ-менеджера (а выделение дополнительных 12 человеко-месяцев работы, что есть бизнес решение, или определение профпригодности руководителя проектов, затребовавшего такой доработки) выходит за предел компетенции и уж тем более юрисдикции разработчика, неплохо, или даже очень хорошо разбИрающегося в программировании.
Аргументы комплексной оценки рефакторинга смотрите в моем комментарии выше.
Прошу прощения, что совсем не в тему.
Расскажите джуниору, как стать Senior Developer на Java за полтора года?
Я вот почти 2 работаю, а программирую — лет 5 как, и все JA? =).
Meowthжет, компания моя неправильная?
В гугле бывают девелоперы со стажем 10 лет и синеоры со стажем 20. Тайтл — это условность в большинстве случаев. Я знаю компанию, в которой нет ни синеоров, ни джуниоров — одни принципал девелоперы.
Ясно 🙂 т.е. классификация нашей фирмы JunA->JunB->JunC->ExpDev->SenDev-> .. maybe PM =).., видимо, исключительно наша? 🙂
Спасибо за информацию.
Виктор Ронин, по-моему, вы сами начинаете себя запутывать.
«Идея паренька была не просто придерживаться новых мелких хорошестей, но и изменить текущий код, чтобы соответствовать им. »
«Там был достаточно длинный список в основном визуальных изменений, многие из которых нельзя было автоматизировать.»
— вот так появятся несколько десятков мелких, но важных дополнений/уточнений, которые доказывают, что ваше решение в тот момент было правильным.
Не надо доказывать свою правоту — ни тогда, ни сейчас — никто не собирается осуждать Вас лично. Вы были правы, в том, что отстаивали судьбу проекта. Главное, что вы (и мы все) сделали (я надеюсь, сделали) верные выводы из этого урока, а именно
Я думаю, читатели и так понимаю, что
а) стиль кода — это хорошо
б) рефакторинг — это хорошо
в) архитектура, а не рахитектура проекта — это замечательно.
г) все это надо делать С САМОГО НАЧАЛА проекта, иначе, как вы сказали, витаминкой С больного с переломом не спасешь.
Кстати, вы так и не сказали, что стало с проектом в конце? 😉 выжил ли он или раздавил сам себя?
Спасибо.
Насчет правоты, я всего лишь упомянул это, чтобы не осталось двоякого впечетления, что мол тогда я об этом сказал и непонятно, как бы я поступил сейчас.
>Кстати, вы так и не сказали, что стало с проектом в конце? 😉 выжил ли он или раздавил сам >себя?
Проект выжил, я таки выбил настоящий рефакторинг через некоторое время.
>>я таки выбил настоящий рефакторинг
Ура! справедливость восторжествовала 🙂
Восторжествовала, потому что больше не было вариантов нести эту
кучу гов..гору быдлоко..тяжкую ношу, я думаю 🙂В общем, как в рекламе — выбор очевиден 🙂 Даешь coding_style.doc и рефакторинг в массы на самых ранних стадиях!
(про себя: интересно, сколько вам дали времени на выбитый тяжким трудом рефакторинг)
В результате рефакторинг занял порядка 3 месяца * 3 человека.
Хотя, я против больших рефакторингов, но этому проекту нужна была шоковая терапия.
Зато после него наступил кайф.
Ждем 🙂
Артем, это был сорказм. Ну да ладно. За грамматику спасибо!
Показали бы раньше ссылку на профиль — съэкономили бы кучу времени мне и себе.
Обоснованность мое
Артем, это был сорказм. Ну да ладно. За грамматику спасибо!
Показали бы раньше ссылку на профиль — съэкономили бы кучу времени мне и себе.
Обоснованность моей точки зрения не может быть фактом впринципе.
Удачи,
Георгий
Как-то странно у вас, Виктор, комментарии постятся.
Та да, я никак не разберусь с этой проблемой.
Почему-то иногда комментарии вниз соскакивают.
[…] Browse other articles in Мысли вслух, Эффективность categories. « Поднятие качества. Либо пан, либо пропал. […]
Думаю что рефакторинг такого рода как ты описал должен делаться за деньги заказчика. Поэтому это задача не столько техническая, сколько маркетинговая, тоесть надо его убедить что это надо делать. Любая работа должна быть оплачена, а когда фирма занимается той работой за которую не платят то ничем хорошим такое растранжиривание не может закончиться, не зависимо насколько «дермовый код».
Когда пишеться свой продукт то там конечно другие принцыпы, но идея все таже самая: рефакторинг — это не самоцель, это средство решения проблем и экономии.
Хотел бы я посмотреть на заказчика, который сознательно оплатит рефакторинг. Пока таких не видел.
Вас послушав, я начинаю думать, что рефакторинг — этор целевая статья по расходу денег заказчика, и его надо сразу с ней ознакомить 🙂
На самом деле, вы только скажите заказчику, что 30-50% его денег уйдут оплату переделки, он вырвет себе и нам волосы на за.. ну, вы поняли, где 🙂
Мое видение таково — рефакторинг — это необходимая процедура итеративной разработки продукта. Нет итераций — нет рефакторинга. Вот и все. Это вам не magic wand — ба-бах, и вот, новый шедевр готов =)
На чьи деньги должен он проводиться — это не здесь должно обсуждаться. это зависит от навыка исполнителя. И наглости. 🙂 Шутка
Есть еще вариант — пилим бюджетные деньги. Тогда можно писать хоть 100% бюджета на рефакторинг.
Зависит от заказчика (в том числе если фирма пишет сама продукт).
Опять же вопрос в том насколько плох проект и под каким соусом подать рефакторинг.
Что могу сказать, что его мало кто любит в начале (так как пилюля откровенно кислая), зато после того, как стабильность и качество проекта улучшается, то его начинают воспринимать нормально.
Ну это когда итеративно вы разрабатываете продукт с самого начала, а когда он уже вам в руки попал то там уже итерациями по ходу дела толком ничего не сделаешь…
Да, чаще всего схема следующая
а) Первых программистов просят состряпать proof of concept. Они делают простенький не расширяемый вариант программы.
б) Тех же или следующих сажают в сверхсрочном порядке довести концепт до версии номер 1, слезно им клянясь что потом дадут время на привести его до ума.
в) В еще более срочном порядка, так как пошли продажи, дают следующим программистам (хотя бывает и тем-же) делать версию номер 2.
г) И где-то к версии номер 3-4, обнаруживается что код преставляет из себя полную жопу, так как каждый раз сроки горели и не о каких чистках кода программистам и подумать не надо было.
К тому времени, все старые программисты сваливают, потому что им надает разгребать говно лопатой, при горящих сроках.
Приходят новые, которые либо продолжают срать в код. Либо таки выбивают время на улучшения (обычно выходит либо если заказчик/босс понятливый, либо если стабильность продукта уже совсем на нуле).
Так, что полностью согласен, пока идет этап а), б) и в) обычно задача стоит так, что программисты даже потенциально не мог написать хороший код и итерационно его улучшать. А к пункту г) там уже становится сложно двигаться итерациями, приходится брать время на хотя бы первоначальную расчистку площадки.
Вы уж извините Виктор, но я с вами одновременно и категорически согласен, и категорически нет 🙂
Из вашего комментария следует:
а) именно то и именно так, как я и писал в своем первом комментарии к этому посту;
б) создать качественный продукт просто невозможно по причине левых факторов, вплоть до «космических лучей», как прокомментировал Георгий. Вот те факторы, что вы перечислили (мои комментарии):
— «каждый раз сроки горели» (очень странная разработка — web стартап круглосуточно?),
— «обычно задача стоит так, что программисты даже потенциально не могут написать хороший код» (одно из отличий хорошего программиста, что даже под воздействием «демотивирущих» факторов {задача плохо «стоит» — падает, что ли:)} он способен писать достойный, расширяемый код)
— «слезно им клянясь что потом дадут время на привести его до ума.» (ф топку тимлида и ПМа, которые пообещали и не дали время)
— «ни о каких чистках кода» (мне кажется, вы неверно воспринимаете рефакторинг оторванным от написание кода. AFAIK это не так — написание кода и рефакторинг должны быть одновременны, а не носить характер «чисток» и «зачисток»)
Как это вижуя на любой провал и демотивирующий фактор можно отыскать причины и устранить их (к сожалению, редко возможно устранить этот провал, но есть задел на будущее), а не пытаться оправдываться, что мы делали-делали, но все так плохо и так всегда было плохо, что мы «неасилели»
Я вас ни в чем не обвиняю, может, я не так что-то понял.
На самом деле, я просто описал типическую ситуацию.
Я полностью согласен, что эта ситуация полное гавно.
И нужно в топку
а) Программистов, которые пишут говно код, когда им на голову садиться менеджер.
б) Программистов, которые и не умеют писать хорошего кода, так что им такая ситуация очень на руку (чтобы была отмазка)
в) Менеджера или тимлида, которым всегда важна кратковременный результат по сравнению с долгосрочным.
На самом деле, я описал ситуацию, так как был в разных ролях в очень похожих ситуациях. И честно говоря уже утомило быть в любой роли в таком говне.
Хотя сейчас чаще работаю в команде спасателей проекта, но как-то это настроение тоже не подымает.
Виктор, вам не кажется, что вы забыли отправить в топку основых виновников? 🙂
Побывав на всех местах в вашем списке, я могу сказать, что как правило, все начинается с того, кто хочет проект продать. Не важно, внутренний это заказчик или внешний — всегда есть кто-то, кто продает. И этому кому-то важен не продукт, а продажа.
Проблема не уникальна для IT. Но в IT она стоит остро, как и в любом другом производстве, где основной инструмент — мозг.
Продавец должен продать. В большинстве случаев он получает от этого премию. Или не получает по голове от начальства, что можно трактовать как премию.
Учитывая, что у продавца есть одна метрика — количество продаж, он, как правило сильно опасается за свое место. У программиста виден прогресс (сделали 50% фич), у продавца не может быть контракта, заключенного на 50%. Он либо есть, либо его нет.
Как результат, продавец постоянно напрягает всех вокруг. У него нет другого выхода. Он играет в другую игру. Краткосрочную. Разработчики же видят (или думают, что видят) долгосрочную перспективу.
Добавлю: Часто можно слышать от программеров, что мол вот они (менеджеры, продавцы) набьют шишек и научатся. Не будет этого :). Редкий человек способен сказать себе, да, я тормоз, я не послушался и набил эту шишку. Единицы это могут сделать. И эти единицы, как правило, уже прошли этап набивания шишек.
Пример из личного опыта: пришел на проект, там один тимлиб был, больше никого. Все друг друга нелюбят, на письма не всегда отвечают 🙂 (менеджеры в самой умной стране, через океан). Тим лид уходит через месяц. Теперь я вроде как один. Просят эстимейты по задачам. Скажем, я написал 2 года для одного меня. На что мне сказали, что все хорошо, но делать будет за год, и т.к. уже прошло 6 месяцев с начала проекта, то за полгода. Только потом я узнал, что эстимейты мои были уже третьи по счету. Все три примерно совпадали. Откуда взялся эстимейт в один год — никто не знал. Проект был для себя.
Т.е. ситуация еще хуже. С самого начала люди осознано шли на завал проекта. Понятно, что сначала мы выбросили половину требований «на будущее», и даже с половиной опоздали на 2 месяца.
Подводя черту: Гиками (разработчиками) очень легко пользоваться. Кнут и пряник. Страх потерять клиента и оплата сверхурочных. Пока программисты ведут себя как быдлокодеры, к ним так и будут относится.
Тоже работает и в отношение программеров (они тоже люди, из того же материала): много программеров скажет себе, мол, да, я чмо и лох, меня использовали и я повелся, теперь я ковыряю этот дерьмокод? Единицы. Остальные покупают себе перекидной календарь с мантрой на каждой странице: «во всем виноваты тестеры», «все вокруг быдлокодеры, один я в белом», «начальник сказал, что надо быстро — следовательно виноват он».
Да. Согласен.
Это одна из проблем, что гигантское количество программистов с одной стороны не может и не хочет дать отпор, а с другой стороны винят всех вокруг потом.
>>Откуда взялся эстимейт в один год — никто не знал. Проект был для >>себя.
>>Т.е. ситуация еще хуже. С самого начала люди осознано шли на >>завал проекта. Понятно, что сначала мы выбросили половину >>требований “на будущее”, и даже с половиной опоздали на 2 месяца.
Йордон в своем «Смертельном Марше» поясняет прекрасно, откуда берутся такие фантастические сроки и как они получаются у «основных виновников» _торжества_ 😀
А так же — как это не допустить, но об этом более скромно 🙂
Опятm-таки, основной вывод — для успеха нужны старания, мотивация и понимание процесса на всех слоях IT-иерархии.
Однако мы уходим от обсуждения поднятия качества.
2Viktor:
Как насчет отдельного поста «эффективная команда от и до»? 🙂
Один из моих методов поднятия качества — говорить правду. Всегда. Начать следует с себя 🙂 Перестаньте врать себе. Нет, эту фичу не сделать за два дня. Нужна неделя.
Мой случай был экстримальным. Как правило, ПМ не напишет эстимейт, пока вы его не подтвердите. Не дайте ему уговорить себя :).
Правда, страшная штука. Проблема только, что она зачастую субъективна.
А еще хуже, когда правда высвечивает, что кто-то не делает своей работы хорошо. Вот тогда начинаются песни и пляски.
>Как насчет отдельного поста “эффективная команда от и до”? 🙂
Ох… Если бы я знал как сделать от и до, то сейчас бы не блог писал, а попивал пивко в гамаке, на личном острове :))
Но, может, что-то в этом ключе напишу 🙂
Не, sales в топку нельзя :)) Иначе денег фирме не будет.
А если серъезно, изначально конечно в таких проблемах обычно виновато политика партии.
Когда sales и технари идут не в ногу, то либо получается продукт, который никому не нужен, либо куча говнокода, который пытаются продать.
Согласен. Вопрос финансирования вопрос не технический.
Технический вопрос, что делать при данном уровне финансирования или как продать правильно идею рефакторинга. Опять же это одной ногой технический вопрос.
Проблема возникает, когда я использую http://gbolyuba.moikrug.ru/ как openid
У меня было подозрение, что это как-то связанно с openid, но подтвердить не мог.
Спасибо, покопаюсь в этом направление.
Если это таки оно, то с меня пиво (как только окажемся в одном городе 🙂
У меня в блоге та же проблема. IMHO слетает параметр ответа на конкретный коммент после openid-аутентикации на внешнем хосте. Сейчас отвечаю на коммент, где ты обещал человеку пива :), но уверен, что окажется внизу.
Ура. Таки правда. Не знаю в ЖЖ есть такая проблема или нет.
По крайней мере причина ясна и есть метод повторения бага, дальше дело техники.
Интересно, а с ЖЖ та же проблема ? Сейчас попробую использовать их в качестве openid-сервера.
Угу, с ЖЖ та же фигня. Сдается мне, что жабаскрипт, используемый в brian’s threaded comments просто не передает (или не выставляет) свой параметр в форму openid.
Хм…. Чувствую я, на выходных залезу по локти в brainthreaded код и буду копаться.
Я и так там по мелочи уже переделки делал.
Мда, проджект-манагер принимает решения о рефакторинге… что-то в доме совсем плохо 🙂
технически-детальное я имею в виду, конечно
сорри, не обращайте внимания, у меня глюки 🙂
Это сказывается вечер длинной среды 🙂
Можете предложить альтернативу субъективной правде? Если она не идет в разрез с тимплеем и это как раз правда, а не тухлая попытка прикрыть задницу — тогда она и субъективная сгодится.
На самом деле, я согласен — правда это единственный метод работы.
Я просто сказал, что чаще всего это болезненное дело ее говорить и ее слушать.
Никто не обещал, что будет легко ;). Поэтому первый шаг так сложен — нужно начать говорить правду себе. А это означает, что и слушать ее будешь ты сам.
Студент похож на меня 3 года назад 🙂 Только я выводы правильные сделал — уволился нафиг по собственному желанию и за полгода в одиночку сделал систему аналогичную той что делало 8 человек, но при на порядок меньшем количестве кода. 🙂
Нашел инвесторов, они сделали ЗАО, я получил 30% дохода и теперь те, кто не согласился со мной тогда — грызут волоса у себя на жопе, мы их выдавим нахуй с рынка :)))
Подход правильный :). Будь я на месте ваших работодателей, я бы посмотрел, можно ли поиметь что-то с вашего ЗАО (Может информацию какую вы получили в служебном порядке 🙂 ). Однако, в России (?) с этим туго, так что да, все правильно сделал.