Код — это инструмент
Написание кода не является работой программиста. А является ей создание приложения для решения определенных задач. Да, код — это основной инструмент, который для этого используется, но все равно это всего лишь инструмент. Так же как работа столяра не заключается в использовании молотка или пилы — она заключается в производстве чего-либо при помощи этих инструментов.
Однако, некоторые действия могут привести к ошибочному мнению, что именно код является продуктом. Например, рефакторинг: что мы улучшаем с его помощью: код или продукт? Если ответ код — ни один менеджер не даст времени на это занятие. Но стоит объяснить, что это может исправить существующие ошибки или поможет внедрить новую возможность, и, внезапно, время на это найдется.
Приложение, прежде всего, оценивается целиком. Об этом следует помнить при написании каждой строки кода. Если продукт непривлекателен, смысла обсуждать что-либо дальше просто нет. Даже если все инструменты отлично использованы, работа провалена, если продукт получился плох.
Это не означает, что код не является чем-то ценным и не должен проверяться в контексте требований к продукту. Обеспечение безопасности и отказоустойчивости требует мастерства и использования правильных библиотек. Вот где код должен делать свою работу, остальное не должно выделяться. Чем быстрее рецензент пройдет такой код — тем более он будет удовлетворен.
Идея «Код — это инструмент» является причиной важности знаний нескольких языков и фреймворков; причиной пользы знаний математики и теории сложности, однако отсутствия необходимости в таких знаниях; причиной, по которой среда разработки может оказаться как замечательной находкой, так и самой страшной ловушкой. Все это является мерилом гибкости для программиста, которая напрямую зависит от разнообразия его инструментария.
Упор на характеристики
Возьмем, к примеру, встречу с ПМом или заказчиком. Что ты ему расскажешь? Сколько строк кода написано, сколько классов создано, как работают скрипты, обрабатываются исключения и как устроена база?
К сожалению, часто ответ на все эти вопросы «Да, именно это я ему и расскажу». А его лицо в это время ты видал? Ему скучно. Ему бы поскорей перейти к следующим пунктам. Эти детали не имеют для него ни малейшей ценности. Не то, чтобы он не понимал, о чем речь, его просто это не волнует.
Представь, что дизайнер начнет рассказывать тебе об использованных им слоях в Фотошопе, о том, как много у него там объектов, какие градиенты использованы на каких кистях и какие крутые анимационные скрипты он написал. Тебя это не интересует. Тебя интересует, можно ли уже забирать картинки.
Общаться надо на уровне состояний готовности: импортирование готово, но не хватает поддержки того и этого; приложение работает на большинстве телефонов, но на вот этом все еще подтормаживает; клиентское приложение уже работает, но функционал пока убогий. Вот что важно для менеджера или заказчика. Вот что несет для него информацию, полезную в контексте планирования дальнейших действий.
Твоя библиотека ничего не стоит
Я часто встречаю вопросы в интернете, связанные с защитой исходного кода. Программист пишет код для заказчика и использует для этого свою личную библиотеку. И вот, клиент требует исходный код всего проекта, и программист задумывается: не хочется отдавать ценный код своей библиотеки.
Сперва подумаем, зачем вообще клиенту может понадобиться исходный код. Возможно, для уверенности в возможности продолжения разработки, даже если программист внезапно исчезнет. Возможно, для проведения аудита безопасности или соответствия лицензий. Сам по себе код ему не нужен, он опять-таки просто играет роль инструмента для выполнения какой-то другой задачи.
И хотя личная библиотека может быть стоящей вещью, она не является ценностью сама по себе. Важной она будет лишь для тебя, так как она позволяет тебе работать быстрее. Собственно она может быть самой важной частью твоего бизнеса, но другой программист может отбросить ее как ненужную.
Но что, если библиотека действительно ценная? Если действительно есть уверенность, что она сама может быть продуктом. Тогда можно поделиться ей, или же даже продать, может, что и выйдет. Стоит только учитывать, что очень немногие такие продукты достигли хоть какой-нибудь успешности.
Такое упражнение вообще полезно для любого программиста. Оно приводит к осознанию того, как мало других программистов интересует твоя работа. Да взять хоть даже твой собственный проект. Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?
Да, но...
Это что, значит, можно писать отстойный код? Нет, не значит. Для создания качественного продукта необходимо мастерство. Несмотря на то, что код никого не интересует, он все же основной инструмент для достижения цели. И хоть перфекционизм может быть проклятьем, но если неэффективно этот инструмент использовать, то задачу мы не выполним.
Возвращаясь к аналогии с плотником, грязный молоток забьет гвоздь не хуже начищенного до блеска, а вот ржавый может запросто сломаться при ударе и даже поранить.
Целью программиста является улучшение продукта, а не кода. Для максимальной эффективности нужно отталкиваться от того, что должен делать продукт и понимать, в чем заключается истинная ценность результата.
Комментарии (199)
NorthDakota
20.04.2015 17:02+46Мой код никого не интересует.
Мой код интересует команду в которой я работаю, так же как и меня интересует их код.
Claud
20.04.2015 17:56+1В реальности это слишком маленькая аудитория, и в большинстве случаев к сожалению куда важней фактор быстрого завершения задачи.
fetis26
20.04.2015 18:36+2Потому что у вас кодобаза общая. если 1 из команды работает, допустим, над серверной частью, а другой над клиентской. то как написал тот товарищ волновало бы вас мало. вы туда никогда не полезете, главное чтоб не падало и отвечало заявленному АПИ
tenoclock
20.04.2015 20:14А в обратной ситуации очень бы даже волновало, еслиб быстронаписанный код выпадал по таймауту на половине запросов от клиента(негуманный поиск или сортировка, однопоточные запросы к сторонним апи, что угодно) и Вам пришлось бы весить на это костылики.
fetis26
20.04.2015 22:22-3Вам было бы легче, если бы падал хорошо написанный код?
Ashot
21.04.2015 00:08+2Упасть может любой код. В хорошем коде просто баг правится и правится быстро, скорее всего. Если код плохой, то исправляться, как заметил tenoclock, это будет скорее всего костылём, который в добавок вполне может спровоцировать ошибку в другом месте.
vedenin1980
21.04.2015 00:15+2На самом деле, плохой код вызывает и плохие ошибки. То что в хорошем коде просто выкинет понятный exception сразу как произойдет ошибка, в плохом может привести к незаметному игнорированию ошибок, блокировкам, зацикливаниям, утечки памяти, падению производительности, а то и повреждению данных.
vedenin1980
21.04.2015 00:12+3Конечно, так как хорошо написанный код:
1) легче исправить,
2) проще отладить,
3) в конце концов, он просто не падает на глупых вещах (и падения не приводят к катастрофическим последствиям), запутанный плохо написанный код без всякого тестирования легко может содержать баги вроде полного удаления базы на продакшене, а вот в хорошо написанным коде такие вещи легко видно невооруженным глазом.fetis26
21.04.2015 01:58Вы, как и остальные минусующее, забываете мой изначальный тезис. Вы используете некий сторонний продукт, пусть даже созданный в вашей компании, который удовлетворяет вас по параметрам Стабильность и Функциональность. Я не знаю почему в этой ситуации вас должно беспокоить как это написано.
vedenin1980
21.04.2015 02:09Даже если сторонний продукт, я пишу на Java и один из самых главных плюсов — ты можешь открыть любую стороннею библиотеку/продукт, в которой случилась ошибка, и посмотреть что там произошло. Много раз таким образом находил причину ошибок, пару раз отправлял pull request в эти сторонние библиотеки, пару раз разобрался с недокументрованными возможностями, например, монги, иногда делал форки и создавал свои собственные реализации библиотек в которых исправлял ошибки.
Но плохой код все это осложняет в десяток раз.
Alexufo
20.04.2015 23:07прибыль вашей компании складывается не от продажи кода, а от вашего продукта. Все что вы пишите кроме ваших внутренних участников процесса ни кого не интересует.
vedenin1980
21.04.2015 00:21+1Не совсем так, продукт должен быть соответствующего качества. Скажем, за одну ошибку в ПО космической ракеты компания может просто разорится. Да, можно добиться нужного качества на самом ужасном коде, но намного легче выйти на нужное качество при определенном уровне качества кода.
Понятно сам по себе «красивый» код нафиг никому не важен, но если он ускорит разработку, облегчит поиск ошибок или сопровождение, то он вполне себе принесет прибыль. Грубо говоря если на стройки работают одни джамшуты в худшем смысле этого слова, то она легко может оказаться «золотой» при приемке дома. С другой стороны, на строке никому не нужны и великие гении-художники, которые десять лет будут шедевральный кафель класть в одной комнате.Alexufo
21.04.2015 01:04Сказать про ракеты ничего не могу, кого там что волнует) в любом случае полёт это цель. Качество совершенно сложное определение… Ну вот wordpress продукт качественный или говнокод? И да и нет.А битрикс? Ясно одно — его цель это популярность и она огромна.
Можно до посинения ругаться на его говнокод но никого это не волнует, кроме горстки гениальных программистов на гране нервного истощения. Там такое комьюнити что любой говнокод перекрывается двумя щелчками мышкой. Где там качество как скажут многие? Замените это слово на «спрос» и многое станет понятно.
Идеально можно переписать продукт который уже умер и с ним уже ясно как нужно было его писать.
До тех пор пока в команде существует некий дух, говнокодный продукт будет продолжать существовать и всегда как то находить решения и продолжать развиваться и переделываться.
Скорее всего вы говорили не о качестве а о неком духе связывающих вас и ваших коллег.vedenin1980
21.04.2015 01:20Скорее всего вы говорили не о качестве
Именно о качестве. Понимаете при серьезной разработке, есть и серьезные уровни качества — критическая бага и штраф в десятки тысяч долларов.
Качество совершенно сложное определение…
Очень простое, качество это кол-во критичных багов во время работы продукта. Например качество хостинга измеряется временем когда он был недоступен или частично недоступен. Качество программного продукта тоже имеет вполне формальное выражение — кол-во потерянного времени пользователя (полностью, если продукт вообще не работал или частично если не работала лишь часть функций).
Да, в ряде случаев маркетинг может продвигать некачественный продукт, как например Internet Explorer, но рано или поздно функции и качество другого продукта возьмут свое над маркетингом и рекламой.
Поверьте, качество кода напрямую влияет и на скорость разработки и на качество и на простоту поддержки.khim
21.04.2015 01:39+2Да, в ряде случаев маркетинг может продвигать некачественный продукт, как например Internet Explorer
Вот только не нужно на Internet Explorer баллоны катить. Там были вбуханы безумные деньги в разработку и в те времена, когда он занимал 90% рынка он был, вполне себе объективно, лучшим браузером. Это потом, когда его развитие было заморожены на годы (до версии 6 каждый год выходило по версии, а версия 7 вышла через 5 лет и была очень-очень слабым изменением по сравнение с MS IE 6) он стал «притчей во языцах».vedenin1980
21.04.2015 01:48а версия 7 вышла через 5 лет и была очень-очень слабым изменением по сравнение с MS IE 6
ну, хорошо в ряде случаев маркетинг может продвигать морально устаревший на годы продукт, как например Internet Explorer, но рано или поздно более качественный и современный продукт возьмет своеClaud
21.04.2015 11:55+1А про более качественные продукты узнают без маркетинга, что-то я сомневаюсь что хром обошел бы даже сафари будь за ни не google.
BupycNet
21.04.2015 01:15+6К слову код интересует людей очень сильно в одной области уж точно — opensource.
wizi4d
21.04.2015 12:15Полностью согласен. В OpenSource проектах очень даже интересует.
Сразу становится понятно какое количество боли будет вызывать использование той или иной OpenSource библиотеки.
svscorp
21.04.2015 09:59Согласен. А если грамотно «продавать» необходимость обслуживания кода и уменьшение technical debt бизнесу, то и «его» будет интересовать твой код, т.к. он позволит снизить расходы на его поддержку в будущем, время на поиск и устранение проблем (уменьшенеи расходов), ускорить процесс разработки новых фич (опять же, выливается в уменьшенеи расходов), уменьшит риск отвала клиентов из-за нестабильности приложения и т.д.
fogone
03.05.2015 01:47Более того, проблема бизнеса здесь заключается в том, что хороший программист хочет работать с приличным кодом, а если бизнес не рассчитывает на перманентную оплату технического долга, то часто он не может рассчитывать и на приличных наемных рабочих, которого, что не удивительно, в первую очередь беспокоит его комфорт и благополучие. Конечно, можно платить таким сотрудникам втридорого, но на мой взгляд проще всё же учитывать не только необходимость бизнеса в фичах, но и потребность программиста в приличном коде. Ведь работодатель как-то пытается сделать офис соответствующим ожиданиям работников, почему же он не должен делать то же с кодом?
dozent
20.04.2015 17:07+7Если программист работает над проектом один (а статья как будто бы и писалась под такой случай), то его код может не интересует никого. А когда в команде, ваш код, думаю, еще как заинтересует ваших коллег, ведь им его и поддерживать.
Lovesuper
20.04.2015 17:10+16Ваш код заинтересует вас тогда, когда вы начнете его поддерживать. Или когда нужно будет внести модификации. Читайте Фаулера, батенька.
Dreyk Автор
20.04.2015 17:20+5Я вижу, большинство не согласно с автором) (не забывайте, что автор не я)
Конечно, нельзя писать код абы как (об этом тоже есть в статье), но основная идея в том, что не надо ставить код во главу угла, так как главное — проектAlexufo
20.04.2015 23:31+2Это скорее не несогласие, а протест. Вы же видите комментарии,
очень многим не хватает просто признания в своей работе как и мне. Многих программистов статья вообще не колышит. У них завидный экшн))
DrPass
21.04.2015 16:07В статье, грубо говоря, выстроена аргументация, что строитель должен думать о строящемся доме, а не об укладке кирпичей. Лично мне это кажется абсурдным. Второе — неотъемлемая и важная часть первого. Программист должен думать о коде, и стараться писать качественный код, и думать о выполнении поставленных задач, и о конечной цели думать, и о жене вечером должен думать. Много о чем думать, в общем. Поэтому к чему автор выстроил весь этот антагонизм кода и проекта, мне непонятно.
Sartor
20.04.2015 17:21+3Странная статья. Такие резкие утверждения, которые потом чуть ли не сам автор опровергает. Ваш код может никого не интересовать пока не придёт новый человек и вас не уволят за говнокод, с которым ничего нельзя сделать. Просто не надо (не всегда) заморачиваться на идеальности кода.
ncix
20.04.2015 22:39+2За говнокод не увольняют, а оставляют в наказание исправлять. Ведь больше никто не справится.
abby
20.04.2015 17:28+23В целом большинство моментов справедливы, но аналогия неправильная:
Так же как работа столяра не заключается в использовании молотка или пилы — она заключается в производстве чего-либо при помощи этих инструментов.
Инструменты: молоток и пила — IDE и компилятор. А качество кода — это качество дерева. Если дерево гнилое, то результат работы столяра сломается при первом же прикосновении.
В этом ключе, получается, что код — это не инструмент, а материал. И для хорошего решения как правило требуются определенные свойства материала (каленое железо, сухое дерево, мягкое или жесткое дерево, гладкая поверхность соприкасающихся подвижных частей).
Получение материала с теми или иными свойствами — вот это и есть мастерство.
Поэтому и заказчику или кому бы то ни было нужно не показывать сколько строк написано (сколько дыр просверлено или как гладко отполировали), а объяснять, что отшлифовали те и те детали, и сумели сделать сложное отверстие таким образом, что деталь теперь одна цельная, а это значит, что двигатель сможет нормально работать и не взорвется на презентации.puffy
20.04.2015 22:34Хотел тоже написать про неправильную аналогию кода с инструментами, но увидел ваш комментарий.
Я бы провел аналогию кода со строящимся домом. Если у дома плохой фундамент — то и качество, и характеристики, и эксплутационный срок всего дома плохие. Или если технология возведения стен не соблюдена (каким бы хорошим не был материал), или допущены серьезные ошибки, то и здесь аналогично…
janson
20.04.2015 17:30+101. ты просто пишешь программы. Как умеешь.
2. начинаешь глубже изучать язык, пробуешь внедрять новые штуки.
3. для каждого случая находишь наиболее правильное решение, соответствующее паттернам из GoF, рекомендациям Фаулера, Мартина и других правильных пацанов.
4. Ты просто пишешь программы. Как умеешь.Mefistofe1
20.04.2015 22:17+31. ты просто пишешь программы. Как умеешь.
…
4. Ты просто пишешь программы. Как умеешь. Но это другие программы.
G12ES
20.04.2015 17:36+1Ваш код должен интересовать в первую очередь самих вас, ведь вам с ним работать и вам его поддерживать. Самомотивация должна присутствовать в любом деле.
Pinsky
20.04.2015 17:52Я тоже думал, что мой код никому не интересен. В комментариях оставлял «коаны программирования».
А потом весь тех отдел лежал в истерике, когда на них наткнулись.
berezuev
20.04.2015 17:56+7>> Например, рефакторинг: что мы улучшаем с его помощью: код или продукт? Если ответ код — ни один менеджер не даст времени на это занятие.
Вот именно по этому менеджеры никогда не должны ставить задачи разработчикам. Это должен делать только тим-лид, знающий матчасть.ncix
20.04.2015 22:41Тимлид как правило не имеет права самовольно расходовать труд.ресурс без санкции рук.проекта.
tenoclock
21.04.2015 16:41Грамотный ПМ ещё как даст.
cproject
24.04.2015 12:39+2И да и нет.
У грамотного ПМа будет тим лид которому он доверяет и который проверен временем. Все технические аспекты он будет делегировать ему. ПМ должен заниматься стратегией, тактикой, бюджетом и договорами и решением споров команды и заказчика. Если в проекте agile, то роль ПМа сводится именно к этому. Все коммуникации с заказчиком будут лежать на команде и тим лиде.
Если тим лид для ПМа новый, он не даст санкции на расход ресурсов. Он будет контролировать чтобы убедится в отвественности и грамотности тим лида.
Если ПМ доверяет тим лиду, а тим лид доверяет команде, то всё будет нормально с проектом. И понимать все друг друга начнут. И отвественность разделять. И программисты не будут гнуть свою линию, и причёсывать код в ущерб срокам. Все эти действия должны быть согласованы. В первую очередь с ПМом, так как он первый кто несёт отвественность за сроки и бюджет.
Claud
20.04.2015 18:04+2А я согласен с автором, как это не прискорбно. Всегда хочется усовершенствовать, попробовать приделать что-то новое, или перейти с какого-нибудь angular 1 на 2 для этого переписав все к чертям, но реальной пользы для достижения конечной цели от этого будет немного, и оправдать ее получится только будучи программистом. По этому и делают проекты на всяких там wordpress.
Но черт возьми без, а давайте перепишем вот здесь, работа скатится в унылое…
amarao
20.04.2015 18:11+2Обычно с PM'ом можно уточнять, как следует сделать: «на совесть» или «как попало».
fetis26
20.04.2015 18:37+1И часто ПМ берет на себя смелость ответить «как попало»?
amarao
20.04.2015 18:46+6Хороший ПМ — да. (И это отличный метод отличить труса, перекладывающего свою ответственность на команду, от хорошего тимлида). Хороший может ответить «мне нужно сейчас наговнякать к завтрашнему утру, а потом будем уже разбираться можно это сделать, нет, и если да, то насколько хорошо».
Ведь чуть ли не половина гениальных идей «надо сделать» часто оказываются нужны один или два раза.
А задачей команды будет при случае сказать «мы вот тут вот наговнякали, если мы это собираемся дальше тянуть, то его надо писать по-нормальному».
Разумеется, это требует хорошего отношения между PM и командой. Но в его отсутствие, как процесс не назови, всё равно будет плохо, не то, и медленно.
Yuuri
20.04.2015 18:58+6У нас не раз было как-то так:
— Нам нужно наговнякать за месяцок прототип, посмотреть, может ли оно взлететь вообще. Потом переделаем хорошо.
(через месяц)
— Значится так, прототип уже летает и мы его продали с допфичами, поэтому никаких вам переделать, а пилить допфичи.
В ответ на трепыхание разрабов менеджеры говорили словами из этой статьи :(amarao
20.04.2015 19:14+2Нет коммуникации между PM'ом и программистами. Либо PM плохой, либо он нанял плохих программистов. Либо, если он не контролирует HR-политику, то работают они вместе в хреновой конторе. Обычное дело такое.
qw1
21.04.2015 08:59Никто тут не плохой. Это высший пилотаж переговорщика, как купить феррари по цене лады.
Хитрый ПМ специально заказывает «наговнять», чтобы снизить начальные сроки, а затем программеры в мыле меняют на ходу движок (это ведь им больше надо) вместе с пилением фич, вместо того, чтобы пилить фичи и попивать чай, читая хабр.khim
21.04.2015 15:02Покупка феррари по цене лады в большинстве случаев попадает под категорию «мошенничество». Так же и тут: либо PM действительно нифига не понимает «в колбасных обрезках», либо он сознательно выжимает из программистов больше, чем то, на что они подписывались.
И в любом случае такой PM плох: в первом случае он просто не исполняет своих функций и ему во многом зря платится зарплата (хотя ему можно помочь — смотри ниже), во втором — он сам ставит себя в позицию «кто — кого». Это может привести в выигрышу в краткосрочной перспективе, но в долгосрочной — дело будет швах: раз PM поставил разработчиков в позицию «либо я вас на№%бу, либо вы меня», то рано или поздно он получит ответку, когда команда разработчиков будет, по бумагам, пыхтеть в поте лица, а на практике будет чаи гонять и придумывать какой бы ещё лапши на уши PMу навесить.
А вообще это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда (по-первости-то результаты улучшаются!), а к тому моменту, когда начинается развал он успевает свалить в другой отдел (часто на повышение). В конце-концов получается Стиве Элоп, который гробит компании с десятками тысяч сотрудников, а ему ещё и аплодируют. В маленьких же компаниях они обычно не выживают (вернее могут выжить если вовремя и удачно продадут компанию), так как расхлёбывать последствия приходится им же самим.
Упаси нас бог от таких PM'ов.Idot
21.04.2015 17:53>Это может привести в выигрышу в краткосрочной перспективе, но в долгосрочной — дело будет швах
Когда, дело действительно станет швах, то главный виновник всего шваха — просто уйдёт в другую фирму. И ему глубоко насрать на то, что стало с прежней фирмой.
>это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда
… по причине дурных HR, считающих себя всех умнее, и лучше разбирающимся в том какие люди нужны фирме, отсеивая нормальных кандидатов, чтобы своим отсевом заниматься Имитацией Бурной Деятельности.
amarao
21.04.2015 17:16А почему при этом программисты «в мыле»? Вообще говоря, если PM вас хочет гонять «в мыле» — то это повод либо проявить трудовой героизм (если в этот момент экспа идёт), либо заняться исследованием альтернатив (если экспа не идёт или не нужно).
Повторю, если PM хочет поставить программистов в ситуацию, когда от них ожидается качество, а на качество ресурсов не выделяется, то это проблема PM'а и тех, кому не повезло с ним работать (hint: второе исправимо).
Но важно понимать, что есть моменты, когда PM точно знает, что ему надо _наговнякать_. Прямо тут. Херак-херак, и на продакшен. И забыли. PM и только PM понимает business value для того, что делается. А задачей команды является донести до PM'а, сколько ресурсов для данного качества нужно выделить на инфраструктурную часть (то есть на «качество» кода). Это довольно неформальный процесс, часто на грани ненормативной лексики.
Зато на выходе имеется, что всё важное написано хорошо (с покрытием тестами и рефакторингом), а миллионы строк кода, которые не особо-то и нужны в сопровождении в будущем, написаны наотъе… сь, и стоили компании немного. При попытке их развить и начать использовать как код, а не как костыли, PM это понимает (и ему объясняют!) и выделяются ресурсы на приведение в порядок.
То есть проблема обычно в коммуникации между PM и командой. И тут должен быть и хороший PM (который понимает программистов) и хорошие программисты, которые понимают, что иногда надо вчера и говнокод.VolCh
26.04.2015 08:27+1Часто проблема в том, что ПМ не сообщает, что ему надо весь проект наговнякать, что любые заделы на будущее его не интересуют, а то и вредят бизнес-модели, не позволяет раздувать бюджет заказчика.
khim
26.04.2015 13:28Видел очень мало таких. Вернее видел много таких, кто готовы рассказывать про важность быстрого выпуска продукта и прочего, но достаточно попросить завизировать своей подписью простую бумажку с парой фраз (типа по результатам обсуждения решено, что выпуск прототипа должен состояться в как можно более сжатые сроки без затрат времени на создание задела по возможной модернизации, так как окончательная версия будет реализована с нуля без использования каких-либо частей протипа) и они вдруг «прозревают».
Нужно отделять желание «на чужом горбу въехать в рай» от «непонимания ситуации». Одно дело — рассказывать про то, какой ты молодец, как отлично у тебя всё получается и как твои последователи всё разваливают и совсем другое — подставлять свою задницу.
khim
20.04.2015 20:49+10Это уже другая история. И при это тоже писали.
Если вы хотите, чтобы ваш прототип воспринимали как прототип, то и сделайте, чтобы он выглядел как прототип. Чтобы у него кнопки были убогими. И чтобы он тормозил нещадно. И запускался через раз. Поверьте — это несложно,
А если вы сделали прототип, который выглядит как готовое изделие, то менеджер и будет считать, что у вас уже готовое изделие.
Опять-таки — это проблема не только программистов, просто почему-то непрограммистам это проще понять. Вы видели «протипы» железячников? Когда из картонной коробки торчат какие-то провода, запускается всё засовыванием проводов куда-то вместо щёлкания тумблерами и т.д. и т.п. Неужели же сложно сделать красивую коробочку, напечатать корпус на 3D-принтере и вообще «сделать красиво»? Можно — но тогда заказчик начнёт задавать совсем уж странные вопросы типа «когда мы сможем получить от наших подрядчиков серийные образцы?»…
fetis26
21.04.2015 01:47Ок, тогда я повторю свой вопрос, но немного в другом ключе. Как часто встречаются такие хорошие и правильные ПМ?
amarao
21.04.2015 01:49Чтобы оценить вероятность надо сделать большую выборку. У меня такой нет. Но хорошего ПМ я нашёл, и всё отлично. Подозреваю, что если искать работу не по критерию «ЗП/близость к дому/любимый ЯП», а по критерию «толковый и вменяемый ПМ», то работа легко найдётся.
tenoclock
21.04.2015 18:05У меня ПМ тоже отличный. Но тем не менее я как-то не представляю, как по этому критерию можно искать работу. Сам процесс неуловимо ускользает :)
amarao
21.04.2015 20:12Ну, беседа при собеседовании. Например, компании, где HR до последнего человека ведёт, а PM'а не видно, наверное, не лучшее место для трудоустройства. Личное впечатление о человеке. Поговорить о возможных проектах, где предстоит работа и т.д.
Idot
21.04.2015 20:29Увы, в большинстве крупных компаний с хорошей зарплатой у HR (как правило) — слишком большая роль. А PM появляется, только если HR разрешит.
А однажды, вообще был клинический случай
0. HR — была в отпуске
1. успешно поговорил с PM и уже обговорили устройство на работу
2. HR — возвращается из отпуска
3. объявляют, что требуется обязательное одобрение HR
4. HR — зарубает, и хрен кто что может поделать
(самое обидное, что зарплата там была очень и очень нехилая, да, ещё тогда Кризис был, и с работой было туго)amarao
21.04.2015 20:35+1Признак плохой компании. Если HR может зарубить человека, которого хочет PM, и это не фатальные основания (судимость-стоплист-проблемы с гражданством), то PM слишком слаб, либо его проект не играет никакой значительной роли в компании.
khim
21.04.2015 20:52Да ладно вам. В Российском офисе Гугла PM'а вообще в штате не было несколько лет ни одного — и ничего, как-то же удавалось нанимать людей и получать премии «за лучшее место работы».
amarao
22.04.2015 00:48Мы же говорим про PM'ов, а не про «работу вообще». И я думаю, в гугле так или иначе есть люди (lead'ы, project owner'ы, как не назови), которые имеют интерес в развитии продукта и представляют себе каким он должен быть.
khim
22.04.2015 02:45В Гугле есть и PMы и TLи и OWNERы и много кто ещё, но они не общаются с кандидатами при приёме на работу. Вернее общаются — но только с теми кандидатами, которые устраиваются на должность PMа :-)
Temirkhan
20.04.2015 18:49+6Ваш код интересует Вашу команду.
Ваш код интересует тех, кто готов и желает почерпнуть знаний и хорошей практики.
Ваш код интересует заказчика уже тогда, когда костыли или неправильная архитектура обваливают всю программу при малейшем выходе «за рамки».
Ваш код интересует Вас — эгоцентризм в лучшем своем проявлении требует нас поступать правильно из самых разных соображений. Никто не готовит борщ в кастрюле из которой еще не вычистили остатки пусть даже другого борща.
kirill89
20.04.2015 18:58Многие заметили совершенно правильно — прежде всего код интересует команду. Качество кода сильно влияет на скорость с которой новый сотрудник сможет адаптироваться. Оно влияет на возможность качественно заделать ваши баги когда вы в отпуске. Хороший тимлид никогда не допустит гниющего кода, потому что каждый человек, работающий над проектом, становится трудно заменим.
Но безусловно, во всем надо знать меру.
engine9
20.04.2015 20:40Не одних программистов это касается. Трехмерщики полируют топологию, дизайнеры двигают пиксели, геймхудожники перерисовывают текстурки. Нельзя однозначно сказать, что это задротство никто не оценит. Еще как оценит, на себе проверено. Но, самое важное это разумный подход. Нужно четко понимать, когда нужно сделать добротно и тупо, а когда вылизывать до идеала.
Krypt
20.04.2015 20:50+1> Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?
А вот кстати, таки кодом. Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.
ilyaplot
20.04.2015 20:54+1Хороший код может содержать больше багов, чем плохой. Качество кода не всегда влияет на качество продукта.
Krypt
20.04.2015 21:10+2> Хороший код может содержать больше багов, чем плохой
Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.
В результате после просмотра кода ты имеешь представление, что от этой библиотеки ожидать, и если там что-то сильно не так — лучше я добавлю недостающий функционал другую библиотеку, чем возьму эту.
qw1
21.04.2015 09:18+1Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
У меня был недавно инцидент. Надо было regex-библиотеку прикрутить к дельфи-проекту. Взял какой-то TRegex, написан вроде прилично, по всем гайдам. Но на практике тормозит нещадно и падает на паттернах в пару КБ. Просто автор в алгоритмах не понимает ничего, что такое автоматы, грамматики и т.п. Просто взял и в лоб накодил.
Кончилось тем, что я взял страшный вырвиглазный pcre и завернул в dll. Вот и весь сказ про «красивый код».Krypt
21.04.2015 15:06От этого никто не застрахован. Стандарт может быть не соблюдён вне зависимости от качества кода. Но всё таки лично для меня при выборе библиотеки из множества вариантов качество кода выступает первым фильтром. Фанатизмом не страдаю, но откровенный говнокод не возьму.
ilyaplot
20.04.2015 20:53-1Если для пользователя нет видимых изменений, значит я за день ничего не сделал. Хороший код нужен самому себе, либо группе разработчиков, которые тоже над этим кодом работают.
GrigoryPerepechko
20.04.2015 21:39+3Ну так это потому что вы визуальщиной занимаетесь. Подозреваю что далеко не всем такая работа интересна.
SerJook
20.04.2015 21:26+15А меня не интересует, чего хочет заказчик. Меня интересует только код и моя зарплата.
Dim0FF
20.04.2015 22:31Но разве вы не пишете код для того, чтобы решить какую-то проблему? Неважно что за задача, если вы её решаете за деньги, значит кому-то она настолько важна, что он готов заплатить.
Не из решения проблем ли состоит программирование, и только потом уже из кода?qw1
21.04.2015 09:31Бывает, что больше половины кода вылетает в помойку. Поэтому не стоит переживать, если код не решил задачу. Не получилось — заходим на следующую итерацию. Если не воспринимать кодирование как игру, можно потерять мотивацию (я столько думал, кодил и всё напрасно). А так — я играю, мне платят. Получилось что-то полезное — хорошо, но на деньги это как правило не влияет.
VolCh
26.04.2015 08:42Результат программирования — решение проблемы, а состоит оно из изменения кода. Есть два основных подхода к ним: решаем за минимальное время озвученную проблему или увеличиваем время решения с целью избежать в будущем новых проблем.
ol_an
20.04.2015 22:29А вот интересно, есть ли примеры проектов, где код блестящий, а конечный продукт не огонь?
ncix
20.04.2015 22:43+2Я в практике постоянно с этим сталкивался. Прекраснейшие архитектуры складывались «в стол» потому что никак не помогали продукту лучше удовлетворять пользователя и лучше продаваться.
vedenin1980
20.04.2015 23:55Как можно назвать архитектуру прекрасной, если она не помогала продукту? Это равносильно «мы сделали замечательный дизайн-концепт автомобиля, одна проблема — он ездить не может».
qw1
21.04.2015 09:35Пока мы делали блестящий автомобиль, конкуренты сделали рельсы и ржавый паровоз он нас обошёл по всем пунктам, кроме лоска.
VolCh
26.04.2015 08:59+2Это равносильно скорее «мы сделали самый быстрый в мире автомобиль, но никто не хочет его покупать потому что дорого». Или, в общем, «мы сделали лучший по таким-то критериям продукт, но не можем найти тех, кто по этому критерию выбирает»
Архитектура не может помочь продукту, если ошибочны требования к продукту.
khim
21.04.2015 00:54Сколько угодно. Последний пример — Windows Phone. По многим признакам видно, что код там куда лучше, чем, скажем, в Android'е. Одна беда: пока Microsoft порождал на основе передовых концепций самый лучший код Android захватил весь рынок и теперь отвоевать хоть малюсенький кусочек будет проблемой.
vedenin1980
21.04.2015 01:34+1По многим признакам видно, что код там куда лучше, чем, скажем, в Android'е.
По каким признакам? Вы делали синтактический анализ качества Java кода Android и C# (вроде он там) Windows Phone? Да, я могу поверить что код Android'а менее протестирован, но это не значит что там писали говнокод.
Подозреваю что проблема совсем не в том что в гугле говнокодили, а в Microsoft'е вылизывали код, там на самом деле куча других причин почему Android обыграл Microsoft.vedenin1980
21.04.2015 01:43-3На всякий случай добавлю Android построен на оперсорсном Линуксе, а Windows Phone на усеченной винде. Традиционно многими винда исторически считалась более прожорливой и менее качественной чем Линукс (честно говоря не знаю как на самом деле сейчас дела обстоят), так что о качестве кода (производительности, отлажености ядра) тут можно поспорить.
khim
21.04.2015 01:55+3Ядро у Android'а — действительно ничего. Но вот всё что выше… Harmony, Dalvik и многое другое из Android 1.x в сравнении даже с Windows Phone 7 — это просто велосипед по сравнению с самолётом. Но вот беда: Android 1.0 вышел на рынок в 2009м году, а Windows Phone 7 — только через год, NDK для Android'а — появился в 2009м и работал на всех телефонах начиная с Dream'а, а в Windows Phone 7 поддержки нативного кода не было, а Windows Phone 8 с его поддержкой появилась аж в 2012м году. И т.д. и т.п.
Многие «болячки» Android'а с тех пор исправили, конечно, но есть куча вещей, о которые разработчики до сих пор постоянно спотыкаются.
areht
01.05.2015 14:31> Традиционно многими винда исторически считалась более прожорливой
Традиционно многими Земля исторически считалась плоской (честно говоря не знаю как на самом деле сейчас дела обстоят, меня не берут в космонавты...)
Klaster
20.04.2015 22:59+1Разумеется, я не спрашиваю водителя когда он менял резину и тех. жидкости, моя задача доехать из п А в пункт Б. Разумеется это проблема водителя. Как и водителя когда он приходит в магазин, не интересует, регулярно ли платит магазин налоги, как и руководителя магазина… У каждого есть своя доля ответственности, соблюдение которой дает плюшки, не соблюдение определенные проблемы. В случае с кодом, плохой код, плохо отлаживать и сопровождать.Сложность процесса ухудшает результат за который ты как раз получаешь деньги.
khim
21.04.2015 00:58Тем не менее сплошь и рядом видишь как люди бьются за вещи, которые напрямую к результату не относятся. Когда вместо «количества ошибок» оценивается «покрытие тестами», а вместо решения конкретных задач появляются фабрики фабрик фабрик.
vedenin1980
21.04.2015 01:35+1вместо решения конкретных задач появляются фабрики фабрик фабрик.
это кстати пример плохого кода
akrupa
21.04.2015 07:04Тут нельзя забывать, что программист в команде не один. Программисты по большему счету соревнуются друг с другом в том, как быстро они выполняют задачи, потому как от этого зависит зп, бонусы и т.п. Особенно это справедливо для больших команд. В результате, при отсутствии должного контроля за качеством кода, качество зачастую приносится в жертву в угоду скорости и срокам (программистами). С качеством кода наблюдается эффект аналогичный "трагедии общинного поля". Чтобы этого избежать, отчасти, вводят кодинг гайдлайны и ревью кода, которые сами по себе вносят большой оверхед в разработку (т.к. требуют время программистов, и, иногда, много).
Klaster
21.04.2015 07:10Это ровно две крайности одна habrahabr.ru/post/256175/?reply_to=8385619#comment_8385461 (первый ответ на мой комментарий) вторая та которую описываете вы. Но их то как раз просто не должно быть, должна быть грань разумного, так и водила может колотить ходовую, не разбирая дороги и забыть про ТО или наоборот переползать через каждую ямочку и торчать по полдня в автосервисе при каждом чихе(что разумеется будет нервировать тех, кого он возит).
akrupa
21.04.2015 07:13Поэтому ТО делается не водителем и есть ГИБДД, которое его проверяет. Т.к., иначе, про ТО забудут все. Со временем.
Klaster
21.04.2015 07:24ТО имелось ввиду не техосмотр, а техобслуживание. И да меня волнует техническое состояние автомобиля и тех узлов которые проверяют на ТехОсмотре тоже. На данные момент ТехОсмотр проходится, не подходя к моей машине, взнос заплатил? Давай бланк. Я регулярно проверяю состояние машины, потому что это моя безопасность, вне зависимости от требований ГИБДД.
akrupa
21.04.2015 07:31+1Это как раз не важно. Вот что получается, когда все пытаются ехать как можно быстрее по своим делам, на чем под руку попалось, с максимальной возможной скоростью, при полном несоблюдении ПДД:
Сверхскоростями тут и не пахнет. Тут можно пешком ходить и выглядеть крутым перцем ;-)Klaster
21.04.2015 07:38Как аккуратно сюда добавилось еще и несоблюдение ПДД. Я разве говорил, что они не должны соблюдаться или что они крайность? Я говорил вроде про другие крайности.
akrupa
21.04.2015 07:49Я разве говорил, что они не должны соблюдаться или что они крайность?
Не говоили. Но, кто ж меня заставляет ограничиваться рамками вашего примера? Машина — ресурс личный, как время программиста. А вот дороги и дорожное движение — общий, как код проекта и CI для команды. Каждый заботится о своей машине, но не заботится о дорогах и удобстве другого. В отсутствие контроля — неизбежно получается «индийский траффик», а точнее — его программный аналог. Поэтому, помимо программистов, кто-то ещё должен быть заинтересован в качестве кода. Иначе, время возмет свое.Klaster
21.04.2015 09:50>>Но, кто ж меня заставляет ограничиваться рамками вашего примера?
Тогда смысл и суть спора пропадает.
Есть правила которые участник дорожного движения\программист в команде обязан соблюдать, как раз по вышеобозначенным причинам. Эти правила продиктованы опытом, написаны кровью и являются вполне себе жизненной необходимостью. И вот как раз не обсуждается в статье. Насколько нужно\не нужно соблюдать правила принятые в команде, про это вообще речи не было.akrupa
21.04.2015 16:25В каждой команде правила свои. Они не берутся в потолка. Да. Они вырабатываются кровью и потом. Но, программисты сами по себе не самоорганизуются. Без участия мэнеджера у них не появится само по себе CI, Code Review и тесты. Всё это требует времени, которое распределяет и выделяет мэнеджер. Поэтому, он должен интересоваться кодом. Или, хотябы полагаться на мнение лида, или другого, специально выделенного лица. И, планировать на это время.
Klaster
21.04.2015 17:02Я ж вроде как раз говорю, что и статья, и беседа изначально не об этом. Есть должностные инструкции выполняй, о чем мы сейчас разговариваем то? Извините за французский: Что б было меньше пиздежу, делай все по чертежу.
poxu
22.04.2015 13:50+1Слова CI, Code Review, тесты и менеджер вместе не употребляются.
Ты говоришь менеджеру тесты, он слышит — задачи будут закрываться на неделю позже.
Ты говоришь ему Code Review, он слышит — на одну задачу придётся выделять в 3 раза больше народу.
Ты говоришь ему CI, он слышит — деплой я сделаю не сейчас, а через 2 дня, после того, как всё настрою.akrupa
22.04.2015 17:59Когда минута простоя стоит тысячи долларов, — менержер не просто готов про всё это слушать. Он, зачастую, готов этого требовать.
qw1
21.04.2015 09:40Программисты по большему счету соревнуются друг с другом в том, как быстро они выполняют задачи, потому как от этого зависит зп, бонусы и т.п.
Поэтому, если ввести метрики, программисты будут работать на метрики.khim
21.04.2015 15:14Поэтому, если ввести метрики, программисты будут работать на метрики.
А разве это плохо? Просто метрики должны соответствовать состоянию проекта. Если у нас клиенты жалуются на то, что продукт всё время падает — поощряем тех, кто фиксит баги, если у нас скоро релиз — тех, кто допиливает фичи, если у нас код такой, что его править невозможно — вводим плюшки за покрытие тестами (по согласованию с PM'ом, конечно) и т.д. и т.п.
Если же вы про то, что нельзя установить раз и навсегда какие-то метрики за которыми только и следить, то это, как бы, самоочевидно… хотя удивительным образом не всем почему-то.qw1
21.04.2015 15:41Фантастика. Цикл обратной связи месяца два? Чтобы заранее сказать: «следующий месяц метрики по тестам». А з/п по периоду дадут только в начале следующего, при быстрой смене в голове у всех каша, за что платят. Если же срочно заказчику приспичит внедрить фичу «А», которую ему пропиарили где-то на тренинге, то разработчики только недоумённо посетуют «Какая фича? А нас месяц тестов».
И зачем поощрять багфиксы метриками? Ставишь вверх по приоритетам и на митинге напоминаешь: «Коля, что ты сегодня делаешь? Фичу? Нет, бросай фичу, тут баг есть повыше».
А метрики по тестам это как? Бинарно писал/не писал, или по количеству? В любом случае очевидно, что делать, чтобы программисту максимизировать прибыль при минимизации затрат времени.
VolCh
26.04.2015 09:06Проблема в том, что зачастую решение писать код качественно или нет, лежит в зоне ответственности не программиста, если качество требует дополнительных затрат.
Glebcha
21.04.2015 00:26+1Когда не по себе от качества «быстрых решений», сажусь и рефакторю/пишу свои старые/новые идеи в свободное время. В итоге хватает уверенности начать писать правильно сразу в большинстве случаев ввиду регулярных тренировок.
Ну и конечно есть радикальный вариант — смена работы и стабильный проект (все же в этом случае куда больше шансов быть услышанным).
R0ckwi11
21.04.2015 00:30Автор перевода не угадал с аудиторией. Программиста очень сложно переубедить, что код — это не вещь в себе, а лишь средство решения проблем. И если бы эти проблемы решались вообще без кода и стоило бы дешевле — все бы так и делали.
vedenin1980
21.04.2015 00:42+5Нормального опытного программиста легко. Если я могу решить задачу написав формулу в Excel'e за 15 секунд, я напишу формулу в Excel'e, а не буду пытаться написать класс. Нормального опытного программиста сложно переубедить, что хороший код и плохой код с точки зрения прибыли одинаковы, потому что у каждого программиста есть свое кладбище загубленных баз данных, глупых ошибок на много нулей в долларах, модулей на много тысяч человекодней, который проще выкинуть и переписать заново, чем пытаться понять.
Везде должна быть золотая середина: код не искусство, это лишь средство. Однако, глупо покупать набор отверток за десятки тысяч $, но и пользоваться китайской фигней за 10 центов/набор тоже не очень умно.
mifki
21.04.2015 00:43-1Ну наконец кто-то понял, что рефакторинг, метрики, паттерны и вот это вот всё — не самоцель.
Alexufo
21.04.2015 01:13Вы что, толкаете размышления в самое страшное — неопределенность?)
Хотите сказать, что метрики и паттерны так популярны из за того что были призваны её уменьшить?)
PapaBubaDiop
21.04.2015 02:48+7Код — как спальня. Всегда могут нагрянуть гости. Или гостья. А у вас не прибрано.
akrupa
21.04.2015 04:58+1Если мэнеджера совсем не интересует код, то, регулярные косяки от всех разработчиков по очереди с оценками в $ заставят его начальство задуматься, что в этой сказке не так.
Но вообще, да. Код это не самоцель. Усилия по поддержанию кода в порядке должны как-то соответствовать рискам.
k12th
21.04.2015 07:22+5Сколько раз я слышал это блаблабла продукт блаблабла инструмент. И ни разу — от действительно хороших программистов.
Программисты неплохо получают, и у них закрыты почти все уровни пирамиды Маслоу, кроме самоактуализации. Если тебе не нравится продукт, который ты делаешь на работе, если он тебе безразличен или если тебе не дают принять участие в его проектировании, то единственная возможность творчества и самовыражения — это твой код.
Это не значит, конечно, что нужно все время потратить на непрерывный рефакторинг и написание Общего Ядра Всего, но говнячить прикрываясь девизом «я делаю продукт» тоже не стоит, можно и канделябром-с получить…
Lavir_the_Whiolet
21.04.2015 08:02… © Б. Мейер. Основы объектно-ориентированного программирования, глава о критериях качества ПО.
По статье: а как же такие критерии, как расширяемость и модульность?
Fedorkov
21.04.2015 08:07+2Мой код интересует того склонного к насилию психопата, который знает, где я живу.
mrjj
21.04.2015 09:48Качество кода означает:
1. уменьшение вероятности собственных ошибок
2. уменьшение вероятности ошибок тех, кто будет с ним работать в дальнейшем, а также экономию их времени
3. уменьшение сложности решения
Тем не менее, нельзя не приветствовать отсутствие интереса к качеству кода и ориентацию на короткосрочную перспективу при решении задач. У меня будет меньше конкурентов на рынке труда.
akubintsev
21.04.2015 10:27+1Это статья для руководителей разработки, поскольку с них спрашивают результат, а не листинг кода.
Соответственно, вполне предсказуемая отрицательная реакция со стороны разработчиков, поскольку написание хорошего кода есть главный мотив к тому, чтобы вообще работать (не хлебом одним сыт человек).
maxru
21.04.2015 10:581. Любой рефакторинг должен быть согласован с руководителем
2. В данном случае руководитель прав — с него спрашивают функционал, а не код, поэтому при оценке «что сделал» оценивается реализованный функционал.
3. Качество кода анализируется отдельно техническим специалистом. После этого в код вносятся правки, а к разработчику применяется животворящий паяльник для корректировки поведения.
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.
Regis
21.04.2015 15:58+21. Рефакторинг не должен быть соглсован с руководителем. Рефакторинг должен быть постоянным процессом, идущим совместно вместе с любыми задачами. В этом варианте затраты на поддержку кода в хорошем состоянии будут минимальны. Иначе, да, всё будет накапливаться и выполнение «рефакторинга» станет само по себе настолько тяжеловесной задачей, что вам придется «продавать» это PM-у. И он скорее всего не купит. И будет прав (2).
3. Каким «техническим специалистом»? Тем, что работает в этой же команде? Если да, то почему бы это не сделать частью процесса?
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.
Именно поэтому бизнес не должен принимать технических решений. В частности о том, делать рефакторинг или нет.maxru
22.04.2015 14:531. В результате «самопального» рефакторинга вы скорее всего после очередного просранного срока просто окажетесь на улице. Это раз.
Рефакторинг должен быть постоянным процессом, идущим совместно вместе с любыми задачами.
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.
3. Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.
Именно поэтому бизнес не должен принимать технических решений. В частности о том, делать рефакторинг или нет.
Не должен и, вообще говоря, не обязан. Но бизнес должен понимать сроки и риски, потому что на эти параметры также завязывается и целесообразность/окупаемость внедрения той или иной фичи.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.
Правильный ответ в данной ситуации (для «бизнеса») такой: «В данный момент мы не можем это реализовать технически, но если мы доработаем ПО (+ 2 недели), то задача будет выполнена в течение недели после завершения доработки».
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.khim
22.04.2015 16:56+1Привыкайте, что рефакторинг бизнесу нужно уметь продавать.
Кстати обратной стороной медали будет то, что люди бизнес-стороны начнёт задумываться и о том, что иногда стоит «сделать правильно» с самого начала.
Пока весь нобходимый рефакторинг вы делаете по ночам или срывая сроки и жалобно потом оправдываясь — бизнесу кажется что все эти ваши заморочки есть суть ваша некомпетентность, если вы чётко связываете решение «забить досками год назад, чтобы ускорить релиз на два дня» и сегодняшние «доработки», которые займут две недели, то менеджмент неожиданно окажется куда более сговорчивым и в вопросах выделения времени на то, чтобы всё было сделано правильно.
Вообще для того, чтобы понять как «общаться с бизнесом» нужно усвоить очень простой факт: они другие. Их сила — в другом. Они неспособны «глубоко вникнуть» в суть дела, зато могут держать в голове одномоментно столько факторов из разных, не связанных между собой областей, сколько вы и в тетрадку не запишите. А практически это выливается это в то, что во всех письмах читается одно предложение. Первое. Ну хорошо — может быть два. Первых. Дальше — ну просто в исключительных случаях. Отсюда и любовь бизнес-людей к топ-постингу, кстати. Все ваши многоуровневые построения вылетают в трубу. Вы подробно описываете кучу ньюансов, где-то в 10м абзаце задаёте вопрос, а потом ждёте ответ? Вы его не получите: после прочтения (с приложением героических усилий) трёх абзацев ваше письмо было классифицировано как «бла-бла-бла» и… выкинуто. Как не имеющее содержания. При этом могут быть и очень длинные письма, которые бизнесмен прочтёт — но они всё равно должны начинаться с заключения (чего конкретно сейчас конкретно от получателя письма ожидается) и дальше — может быть цепочка, которая отходит от вопроса и показывает откуда он взялся. Тогда — да, тогда письмо будет прочитано целиком. В надежде найти ошибку в цепочке и ничего не делать :-)maxru
22.04.2015 17:08Кстати обратной стороной медали будет то, что люди бизнес-стороны начнёт задумываться и о том, что иногда стоит «сделать правильно» с самого начала.
Бизнес не будет и не должен об этом задумываться, об этом задумываться должен CIO, это его работа.
Ко всему остальному это тоже относится. Прекращайте решать, как нужно думать бизнесу, это подростковый эгоцентризм.khim
22.04.2015 18:43Ко всему остальному это тоже относится. Прекращайте решать, как нужно думать бизнесу, это подростковый эгоцентризм.
Похоже тут опять столкнулись представители разных миров. Если ваш бизнес заключается в разработке софта «под заказ», то да, может быть бизнесу и не стоит об этом задумываться. А вот если речь идёт о «коробочном» ПО, то это чуть ли ни основное о чём в принципе должен думать бизнес. Как уже говорилось выбор может быть совсем не таким, как хочется перфекционистам, но его нужно делать и это именно бизнес-решение.
Regis
23.04.2015 00:34+2Что такое «самопальный рефактоинг»? Рефакторинг, который не был официально подписан PM-ом? )
В результате «самопального» рефакторинга вы скорее всего после очередного просранного срока просто окажетесь на улице.
Я не встречал проектов, в которых над уровнем когда следят и при этом хронически фейлящих сроки. Зато встречал проекты, где всё делалось «побыстрее», на технический долг регулярно забивалось и в итоге в один прекрасный момент оказывалось, что для исправления накопившихся проблем проще (и быстрее) всё выкинуть и переписать с нуля. Удивительно, правда?
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.
Это дОлжно быть оговорено им (архитектором/техлидом) и всей командой в целом один раз и навсегда, еще на старте проекта. PM-а это касается только косвенно. Поддержка качества кода проекта должна присутствовать в каждой задаче, а не делаться задним числом. Это как сначала писать приложение, а потом добавлять в него «безопасность».
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.
То, что вы описываете — это не проблема, а следствие проблемы. Если функционал приходится «стабилизировать» — значит он изначально был сделан хреново. Это значит, что либо код не проходил ревью (ССЗБ), либо проходил, но ревьюеры это пропустили (вдвойне ССЗБ).
Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.
Если ревью занимаются по сути сторонние люди, а не другие члены этой же команды, то вы теряете канал передачи между разработчиками ифнормации о том, что вообще на проекте происходит, как именно что делается, какие были обнаружены ошибки/недочеты/замечания по коду и т.д. Ревью должны делать все. В том числе джуниору весьма полезно ревьювать то, что делает техлид/архитектор ибо это весьма способствует улучшению понимания проекта джуниором.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.
Соверешенно верно. Называя срок «неделя» вы должны в том числе учитывать, что вы точно будете делать рефакторинг. Потому что вы всегда должны делать рефакторинг. Как часть каждой задачи. Постоянно.
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.
Еще раз: бизнесу не нужно и не положено знать про рефакторинг вообще. Оценки времени — да. Риски — да. Как именно оно «внутре» работает и что именно входит в оценку реализации конкретной задачи — нет.Idot
23.04.2015 17:54Когда сроки жмут, то лучше потратиться на тщательное проектирование, что поможет избежать обязательности рефакторинга. Проектировать нужно так, чтобы заранее избежать и ситуации кода нужно переписывать всё с нуля, и необходимости рефакторинга.
poxu
23.04.2015 20:03Это возможно только если ваши пректы похожи один на другой как две капли воды.
Idot
23.04.2015 20:25Необязательно все похожи и одинаковы, просто, если есть большой опыт, то легче примерно представить на что это будет скорее всего похоже и как скорее всего будет работать. Даже, если проект абсолютно новый, то все равно лучше потратить пару дней на тщательное проектирование ДО начала написания кода, чем потом потратить пару недель (если не больше) на исправление ошибок, переписывание заново, рефакторинг итд итп в том же духе.
poxu
23.04.2015 21:06Ну собственно все, кто практикует аджайл методологию, с этим не согласятся.
khim
23.04.2015 21:50И снова мы упираемся в разные миры. Да, конечно, если вас не очень волнует качество результата, у вас нет времени на вылизывание и продумывание и вы вообще не очень понимаете в начале работы чего вы, собственно говоря, хотите, то постоянный и непрерывный рефакторинг — единственный выход. Если же вы делаете ПО, которым будут [предположительно] пользоваться миллионы или, скажем, такое ПО, которое будет практически невозможно обновить — тогда увлечение рефакторингом скорее вредно. По одно простой причине: если вы отлично понимаете что делает ваш код, то рефакторинг не нужен ибо вы и так понимаете, чего хотите добиться, если же нет — никакие тесты вас не спасут и ошибки и глюки вы насажаете всё равно. В «заказном» ПО — это нормально, во многих других типах ПО — нет.
qw1
23.04.2015 22:54Обычно и сроки жмут, и требования меняются. А когда меняются требования, тщательное проектирование хорошо, но не достаточно.
Idot
24.04.2015 03:45Во время проектирования самое время, ДО написания кода, самое время тщательно проанализировав требования выявить в них мутные места и недоговорки, и задав вопросы внести ясность. Лучше приступить к написанию кода позже, но без переписывания заново или/и ломания структуры программы.
poxu
24.04.2015 10:32+1В эти мутные места нельзя внести ясность. Клиент — не в курсе что там будет. А если думает, что в курсе — то скорее всего ошибается. Разработчик, если он опытный — понимает что будет в этих мутных местах лучше клента, но тоже не владеет всей полнотой информации. Работать по мутным местам имеет смысл когда они прояснятся — не раньше. А до этого имеет смысл применить самое простое решение из возможных.
khim
24.04.2015 13:53Клиент — не в курсе что там будет. А если думает, что в курсе — то скорее всего ошибается. Разработчик, если он опытный — понимает что будет в этих мутных местах лучше клента, но тоже не владеет всей полнотой информации.
Погодите — а что в этой связке делает PM? Вообще-то это как раз его задача поговорив с разработчиков и [потенцильными] клиентами нарисовать некую «картину мира», которую потом разработчики будут воплощать.
Но в любом случае слово «клиент» (один!) опять наводит на нехорошую мысль о том, что нам снова впаривают решение из совсем другого мира. Того мира где нет и никогда не будет каественных программ без глюков, того мира где нет и никогда не будет вылизанных интерфейсов. И вообще там много чего не будет. И это нормально.
Но почему эти идеи снова и снова пытаются притянуть за уши в совсем другие области?poxu
24.04.2015 16:07PM он один из разработчиков. В том смысле, что он с нашей стороны команды. И если клиент сам не вполне понимает, что ему надо, то PM может решить за него. Но только если таких проектов у PM уже было много. И все они одинаковые. А если это не так, то слишком подробную картину мира лучше не рисовать — это незибежно влечёт за собой горы работы впустую.
Ну и я говорю о мире номер один. Который ширпотреб в русском варианте и Shrinkwrap в английском.khim
24.04.2015 17:42Ну и я говорю о мире номер один. Который ширпотреб в русском варианте и Shrinkwrap в английском.
Тогда совершенно неясно откуда взялся «клиент» и ещё более неясно почему нельзя понять чего вы хотите сделать в версии продукта номер N без ежедневных «вихляний задом».
А если это не так, то слишком подробную картину мира лучше не рисовать — это незибежно влечёт за собой горы работы впустую.
Картина мира (настолько подробная, насколько получится) рисуется на один релиз. Потом собираются отзывы, проводятся исследования и выпускается следующий релиз. Так как сбор достаточного количества отзывов занимает несколько месяцев (а то и год), то всякий аджайл отпадает, уж извините. Некому там высказывать мнения каждый день или даже каждую неделю.poxu
24.04.2015 18:26Клиент один, потому что он один в данный момент времени. Нельзя же разрабатывать например сайт Сбербанка для нескольких клиентов. Может быть слово заказчик тут лучше подходит.
Понять, чего хочет заказчик на один релиз ещё более-менее реально, хотя сложно. Но понять, чего он захочет в следующем релизе может только Ванга.
Когда цилы релизов долгие, с аджайлом тяжеловато, да. Но в идеале релиз можно выпускать каждый месяц, а сбором отзывов заниматься перманентно, постоянно корректируя направление разработки согласно результатам.khim
24.04.2015 20:54Может быть слово заказчик тут лучше подходит.
Тут много слов подходит. И очень мало цензурных.
Клиент один, потому что он один в данный момент времени. Нельзя же разрабатывать например сайт Сбербанка для нескольких клиентов.
Если мы говорим о мире номер один? Можно и нужно, конечно. Ибо главное в [этом мире] том, что такое ПО будет установлено и будет использоваться тысячами или миллионами людей. Сколько у вашего чуда-юда пользователей — неважно: если у этих пользователей по существу нет никакого выбора, так что им придётся как-то уж с ним уживаться, то это второй мир. Ну или, может быть, Консультационное ПО, которое хотя и притворяется ширпотребом, но высокая стоимость реализации означает, что оно больше похоже на внутреннее.
Когда цилы релизов долгие, с аджайлом тяжеловато, да. Но в идеале релиз можно выпускать каждый месяц, а сбором отзывов заниматься перманентно, постоянно корректируя направление разработки согласно результатам.
И что вам даст этот «сбор отзывов»? Его ещё обработать нужно. А то у вас любители Linux'а в первый приоритет попадут: они составляют 1% пользователей, причём если по деньгам взять, то, скорее всего, ещё и меньше, а вони от них столько, как если бы они составляли 90% всех посетилей какого-нибудь YouTube.
Отличие «ширпотреба» от «внутреннего ПО» в первую очередь в том, что в случае с ширпотребом вам никто не скажет — что именно вам нужно делать, это вам самим нужно определить и решить. Угадаете — молодцы, несколько раз промахнётесь — и вам уже никто не поможет, конкуренты сожрут. И вот это: «понять, чего он захочет в следующем релизе может только Ванга» — это тоже признак далего не «ширпотребного ПО». Так как заказчика нет, а есть конкуренты, то вы очень часто, чтобы выпустить хоть что-то, вынуждены отказываться от части фич. Понятно, что вот именно они и будут реализованы в следующей версии в первую очередь.
Как сказал Джоел:Подумайте, откуда говорящий. Стив МакКоннелл, Стив Магуайр и я все из одной песочницы: мира ширпотребных электронных таблиц, написанных в Редмонде, штат Вашингтон. И у таких у нас высокая планка на лёгкость в использовании и низкая для ошибок. Большинство других гуру методологии зарабатывают свой кусок хлеба, консультируя внутренние корпоративные разработки, поэтому о них они и говорят.
Аджайл — это для низкой планки на лёгкость в использовании и высокой — для ошибок, а никак не для «ширпотреба».
VolCh
26.04.2015 09:26Рефакторинг — это не трата времени из-за недостатка времени на проектирование, это перенос части проектирования на время когда проблема уже решена.
GarryC
21.04.2015 12:13+1Возвращаясь к аналогии с плотником, грязный молоток забьет гвоздь не хуже начищенного до блеска,
, если не выскользнет из рук и не пробьет потолок при размахе, а грязный молоток намного легче это сделает, чем чистый.
Позволю себе цитату — мы пишем код не для компьютера а для других людей (а среди них и мы сами).
brewerof
21.04.2015 12:37+2Написание кода не является работой программиста. А является ей создание приложения для решения определенных задач.
А код и приложение — это какие- то ортогональные вещи? После этой фразы читал уже по инерции. Не статья, а манифест говнокодера.Idot
21.04.2015 17:42Очевидно, манифест того, кто мнит себя Системным Архитектором, свободным от написания какого-либо кода, с охенной зарплатой, а написание кода считает работой говно-кодеров, работающих если не за жрат, то за гроши => в результате имеем, что вместо одного нормального программера, программу пишут десяток говно-кодеров, а руководит ими Его Величество Системный Архитектор (три раза «ку!»), который ни хрена в коде, который пишут кодеры — не смыслит, так как считает себя выше этого => так что, получаем заваленные сроки проекта.
brewerof
21.04.2015 18:40Нет, мой манифест — манифест человека, который много часов и нервных клеток потратил на разгребание «макарон», оставшихся после таких «творцов».
fogone
21.04.2015 13:54+3Мысль статьи ясна, но предпосылка совершенно неверна. Для разработчика итоговый «продукт» не входит в его сферу ответственности. В его сферу ответственности входит тот код, который он пишет. И именно он является его продуктом. А коммерческим продуктом этот код делают менеджеры, которые его продают, которые формулируют требования, которые ставят реквесты команде разработчиков и тд. Потому что им за это платят. А программистам платят за написание кода (или удаление в хорошем случае). И в общем случае бизнесу и не надо знать о рефакторингах, для него просто есть время выполнения той или иной задачи. На стыке этих сфер есть ПМ, который в курсе происходящего в двух мирах и именно он переводит с языка разработчиков на язык бизнеса и обратно, формирует сроки с учетом рефакторингов и тд, а разработчик — пусть занимается своим делом, пусть пишет код, и пусть делает этого хорошо, не надо на него вешать компетенции вне его ответственности. Хорошие границы ответственности — залог здоровой компании.
saboteur_kiev
21.04.2015 14:35Все уже давно пережевано.
Все стандарты, паттерны и так далее — придуманы программистами для программистов, чтобы упростить работу в команде.
Все стили правильного кода придуманы для того, чтобы удешевить и ускорить работу с кодом в ДОЛГОЙ перспективе. Это никак не касается исправления бага или вводом фичи. Просто грамотная команда понимает, что лучше сразу придерживаться некоего стандарта, чем потом рефакторить. Если есть много времени/денег, можно больше потратить на красивый и читабельный код. Но это опять таки только для долгосрочной перспективы в плане поддержки и дальнейшей разработки.
CentOS
21.04.2015 15:33Но ведь код в первую очередь не столько важен для других, сколько для себя. Самому через неделю/месяц/год надо будет что-то добавить, улучшить… В конечном счете просто поддерживать. И от качества кода зависит на сколько продуктивна будет поддержка и развитие этого кода.
foxmuldercp
21.04.2015 16:25Для начала — понимание своего кода, и как следствие его поддержка и развитие, как мне кажется.
Если я три года назад написал приложение, какую нить домашнюю бухгалтерию для семьи, оно три года работает, и тут я понимаю что вот то, то и вооон то надо переделать вот так и так, открываю код и не понимаю в нём уже ничерта — это был плохой код.
Да, это не отменяет того, что через три года я изменю и количественно и качественно параметры написания своего кода с учетом новых знаний/практик (не учитывая Фреймворки/ЯП), улыбнусь коду трехлетней давности, и его неспешно переделаю.
Idot
21.04.2015 17:33Твой код нужен — не твоему заказчику, для которого программа — как чёрный ящик, внутри которого что творится — не известно, но, зато он выдаёт нужные результаты, и код которого для него столь же интересен и понятен как для тебя зубчатые колёсики и шестерёнки внутри Rollex'а.
Твой код нужен — прежде всего тебе самому, чтобы когда тебе через N месяцев вдруг придётся, что-то доделывать/приделывать, ты смог бы с лёгкостью разобраться в коде, про который ты уже успел подзабыть как он вообще работает.
Oleg_Sh
22.04.2015 20:30Расскажу историю из практики. Был я в длительной командировке в одной достаточно отдаленной стране. Писали большое-большое внедрение — проект реально без начала и без конца, но зарплату платят, все довольны. Команда была интернациональная. Индусов не было, что удивительно, но были местные бледнолицые братья. Один из них нес титул ТМ-а и неформальную роль эксперта, а фактически писал некий свой кусок, независимый от всего остального, так что в его код никто не лез.
На этом проекте были внедрены разные продвинутые практики типа парного программирования, большого экрана с красной лампочкой, которая загоралась, если падали автотесты, и т.п., а еще там проводились раз в неделю собрания по улучшению качества кода. И вот этот заграничный товарищ, который ТМ, очень занудно объяснял, как писать красивый код, чтобы функции не длиннее одной страницы, чтобы имена переменных не слишком длинные и не слишком короткие, и т.п. Лично я на одном таком собрании изо всех сил старался не упасть со стула, если совсем засну.
Потом пришло время вставлять разработку этого ТМа в CI. Он, фактически, писал вторую версию какого-то движка, который преобразовывал интеграционные запросы от внешней системы к нам. Поставили его вторую версию, и тут же начали падать автотесты. А на том проекте было заведено так: кто-то комитит — сразу запускается сборка, потом всевозможные тесты. Если тесты падают — загорается красная лампочка, при этом комитить может только кто-то из узкого круга тим лидов, которые можгут грамотно поправить ошибку. Но тут тесты падали случайным образом независимо от того, что было закомичено. Неделю разбирались — оказалось, что дело в той приблуде, которую написал ТМ. Тестов прогонялось много, и они пулялись сотнями в секунду. Первая версия этой приблуды проглатывала и не давилась, а когда поставили код ТМа — вторая версия стала падать из-за чрезмерной нагрузки. От этого валились автотесты и загоралась лампочка. Откатиться назад на первую версию было нельзя, т.к. вторая версия содержала какие-то необходимые фичи, на которых базировался код, разрабатываемый остальной командой. Экспериментальным путем выяснили, что на 4 тестах в секунду все проходит с вероятностью больше 50%. Спросили ТМа, когда он поправит ошибку — тот запросил где-то месяц.
Целый месяц работа команды была не то, чтобы парализована, но омрачалась тормозами и досадными ложными срабатываниями лампочки. Самое обидное, если лампочка срабатывала после комита из бэк офиса ночью по местному времени — бэк офис оказывался парализованным до того, как проснется кто-то из резидентов отдаленной страны и перезапустит сборку.
После той истории ТМа стали за глаза называть ТН — толстозадый нерд. Мораль сей басни такова: не столь важен код, главное, чтобы работало.
dcc0
23.04.2015 09:17«Мой код никого не интересует».
Можно немножко поспорить, мне встречались люди, которые смотрят на то, как программа написана. Некоторые из этих людей имеют к IT косвенное отношение. Зачем, спрашивается?
«Стиль и общее оформление кое-что говорят о программе». Вернее, об ея авторе.
Но в целом, да. Код никого не интересует, важно, что программа визуально работает корректно, внутри может быть сколько угодно ошибок.
Люди смотрели и смотрят на оформление, на коробку. Изучение оформления кода — примерно то же самое, те же мотивы.
voff
24.04.2015 16:47Как минимум, качество моего кода интересует того, кто будет с ним работать после меня
Еще
marenkov
19.05.2015 17:47+1Вот-вот, как раз сейчас сижу над правкой такого кода, при написании которого считали, что код не важен. В результате то, на что должно было бы уходить 5 минут, занимает 5 часов.
SamKrew
Типичный разговор с ПМ:
— Что вы делали всю итерацию и почему задачи не закрыты?
— Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.
— Мне пофиг, почему задачи не закрыты?
putnik
Если задачи были критичными и нужными именно в это итерацию — программисты не правы и занимались фигнёй. Если же не были, и через пару итераций это позволит нагнать темпы — не прав ПМ.
tenoclock
Для этого и стоят статусы в задачах же, и для этого вспомогательные классы для x,y и z тоже должны быть заранее учтены в спринте. В общем, я с вами согласен :) Но не спросить, почему так вышло, тоже было бы неверно со стороны ПМ.
edogs
Ответ программистов в принципе неверен, более того, какой-то не программистский:)
Корректнее такой диалог
— Что вы делали всю итерацию и почему задачи не закрыты?
— Что делали — писали вспомогательные классы. Почему задачи не закрыты — приоритет их закрытия был ниже (их невозможно было закрыть без написания вспомогательных классов, etc).
ПМ не хватило прямого ответа на вопрос «почему», собственно поэтому ему пришлось его повторить.
tenoclock
Почему этих задач(вспомогательных классов) не существовало тогда? — спросил бы ПМ
boblenin
Чем занимался ПМ если он об этом узнает только в конце итерации? Может быть ему стоило хотя бы иногда смотреть хотя бы на burn-down chart?
Gendalph
А если ПМ неправильно оценил сроки?
А если ПМ заведомо неправильно указал сроки?
А если из-за x продукт падал в 10% случаев, а из-за y — выпиливал базу в 1%?
kvas
Всё верно. Если ПМ оценивал сроки — это неправильно :)
khim
Если их создание — достаточно важно для дальнейшей работы, то они там должны были быть. Если нет — то нафиг вы о них вообще вспоминаете.
Программирование — тут ни разу не исключение. Рассмотрите в качестве примера бухгалтерию. Если бухгалтера наняли на работу и он обнаружил, что бухгалтерия, фактически, не велась, так просто квитанции в папку подшивались, то он, разумеется, выкатит немалый счёт за «восстановление бухучёта». Но если он просто засядет и начнёт «проводить рефакторинг» не согласовав это дело с руководством, то его за это вряд ли похвалит.
«Создание классов x, y, и z» всегда должно выводиться из реальных задач. И исходя из потенциальной важности решения этих задач менеджер уже и решит — стоит ими заниматься или нет. А если вы не можете придумать ситуацию, когда ваши вспомогательные классы чему-то помогут — то зачем они вообще нужны?
kraidiky
Если бы ПМ-у можно было объяснить зачем в программе конкретные классы, он был бы не ПМ, а ТимЛид и ПродуктОунер. В реальности почти никакому ПМ-у и почти никогда не хватит квалификации чтобы понять какие классы есть в его продукте и почему должны быть именно они. Причём квалификации не хватит раз в 8, где-то.
Если ПМ, этого не понимает, а в примере выше он этого, очевидно не понимает. Значит он неквалифицирован не только как ПМно и как менеджер и всю оставшуюся жизнь вынужден будет писать на Хабре обиженные комментарии на программистов жаловаться, что что-то пошло не так. Потому что так как надо у него никогда не пойдёт. Разве что случайно, если у проекта по недосмотру появится лид и оунер, который вытянет проект вопреки ПМ-у.
Суровая такая вот правда жизни.
vedenin1980
ПМ не должен понимать зачем в программе конкретные классы, он должен:
1) контролировать приоритеты и выполнения задач (для этого не нужно ничего понимать в программировании),
2) на ответ " Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.", должен задать вопрос какие именно задачи и на сколько в будущих итерациях эти «вспомогательные классы» должны ускорить разработку. И отсюда уже делать вывод от «ребята молодцы, сократили мой план на итерацию 10 на две недели» или «какого фига вы потратили месяц на фраймворк сортировки бабочек, если мы никогда ими не будем заниматься»
То есть хороший ПМ, совершенно не разбирающийся программировании, может прекрасно рулить техническими задачами исключительно из КПД полезности (текущей и будущей).
kraidiky
К сожалению почти всегда менеджер не понимает почему плохое решение в коде что-то замедлит и когда оно это сделает, а программисты не имеют возможности улучшение кода менеджерам продать. Как потому, что плохо умеют это делать, это вообще-то не входит в круг их прямых обязанностей, так и потому что ПМ их просто не слушает в этой части.
Поэтому, у меня другое видение, как мне кажется, умный ПМ не пытается решать этот вопрос самостоятельно, тем более не пытается составлять детальный план сколько копеек это ему съэкономит через год. Потому что такие подсчёты почти всегда будут профанацией. Вместо этого он находит промежуточное звено, ну или выделяет это промежуточное звено из имеющихся у него программистов, и делает из него крайнего за принятие и обоснование таких решений.
Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию — мне кажется далеко за пределами возможностей не только ПМ-а, но и вообще человека. Грубо говоря Бест-практикс по архитектуре именно потому и являются бест-практикс, а не получаются каждый раз заново методом анализа КПД по планам, что никто, даже самые круты чуваки из GoF не смогут вам такой план составить. Вот, собственно поэтому GoF пропагандировали паттерны, и Фаулер рефакторинг.
khim
Иногда, правда, можно дать возможность людям делать то, чего они хотят просто, чтобы поддержать уровень морали, но тут надо тоже меру знать.
kraidiky
Про меру согласен. Про не несут — не согласен.
Сейчас, например, переделываем ядро одной игры, как раз потому что предыдущие кодеры наделали… Со строгим соблюдением сроков в первой части проекта. Закладываюсь на то что в игре будет резво добавляться правил и геймплея и под это код, котоырй управляет моделью данных более сложен и содержит возможности для быстрого увеличения количества правил и варианта геймплея в разы. Однако когда дойдёт до дела хрен его знает как повернётся, может они с геймплеем будут активно вяло экспериментировать, а со статистикой и рекламой активно. тогда половина наших наворотов останется не у дел. Сейчас этого не знают ни они, подвязавшиеся ждать когда эта архитектура будет, ни мы, взявшиеся её делать. Но если будут с геймплеем экспериментировать — экономия будет о-го-го.
Конечно разные отрасли — разные ситуации, но там где я работал, — в игрострое, когда начинаешь работать контуры того, как будет устроена игра через пол года не просматриваются даже в сизой дымке.
vedenin1980
Тем не менее, вы же вполне можете объяснить: если будет сценарий 1 мы сэкономим столько-то времени, потратив сейчас столько-то, а если сценарий 2 то столько-то и столько-то. Вообще, ПМ'а как раз с вероятностями пи рисками должен работать по хорошему (вероятность, что разработчик поссорится с женой и его работоспособность резко упадет, вероятность что пол команды решит уволиться, вероятность что заказчик вообще не захочит платить за сделанную суперфичу.)
khim
А это уже риски, которые оценивает как раз PM. Если он оценивает вероятность развития событий так, что вариант, для которого вы собираетесь «соломки подстелить» весьма высоковероятен — он вас поддержит, если он решит, что «мы туда ходить не будем» — он вам скажет делать что-то другое.
Будущего не может знать никто, это понятно, но если вы не можете привести обоснование для вашей деятельности в терминах предметной области (не в «в среднем размере функции» или, прости госсподи, в «проценте покрытия тестами», а во «времени на изменения одного правила» или в «цене создания нового монстра») — то это значит, что обоснования у вас нет.
wartur
Холивар, но все же.
=== По поводу менеджера:
Плохой прожект менеджер это такой прожект менеджер, который как раз не дает писать «дополнительные классы». Это рано или поздно заваливает проект и он сходит с рельс. Прожект менеджер должен знать где требуются архитектурные решения, а где требуются 2 гвоздя с доской. Если он не знает, а думает только метриками типа «отлично сэкономим, тут — ну вы же сказали же да?», то надо его садить либо на аутсорс, либо куда подальше.
Все другое мол это «никого не интересует» в топку обиженных ПМ-ов. Смотря на каком уровне и для кого, все это интересует.
А вообще очень важно, что бы на каждом уровне были профессиональные и мотивированные люди, а схема взаимодействия плоская, а не древовидная во главе с Боже упоси ПМ-ом. А с ПМ-деревом все вокруг покроется убогими досками, и все сгниет на корню.
=== По поводу девелопера
Девелопер действительно должен понимать, что код для кода это бессмысленно. Главная задача решить задачу с возможностью масштабирования кода на одну-две итерации вперед, кроме выраженных конечных случаев где такое масштабирование не будет (забить досками). Соответственно, если по этому коду масштабирование все же требуется произвести, то будет дополнительный оверхеад на переработку архитектуры, о чем разработчик должен уведомить менеджера — мол мы это забили досками, поэтому надо надо сломать и забетонировать.
=== Резюмируем
Самый первый комментарий это гнилой базар ПМ-а. Потому что разработчик сказал, что он делал. ПМ должен разобраться и направить в нужное русло, а не вонять.
khim
Потому «Мне пофиг, почему задачи не закрыты?» — это, конечно, отвратительный PM. Сходу говорить о том, что раз мы об этом не договаривались, то и делать ничего такого не нужно — это признак двойной некомпетентности. Просто потому что он чего-то упустил: если команда занималась не тем, чем планировалось заниматься, то это, во-многом его вина.
Нет, всё возможно: бывает так, что вся команда (особенно небольшая) учиталась очередной новомодной книжкой и какую-то фигню творит, но так бывает всё-таки не слишком часто. Обычно если уж какие-то вспомогательные классы создаются, то тут есть какая-то цель и задача PM'а — понять что это за цель, нужна ли она нам и т.д. и т.п. Иногда стоит эту деятельность и прекратить, но сразу «мне пофиг» — это неконструктивно. Вообще позиция «все кругом идиоты, а я один — д'Артаньян» не очень конструктивна.
wartur
Ну. Как-то так. Да.
areht
Давайте проведём мысленный эксперимент. Дано:
Вы в коде сделали сортировку пузырьком, но не так и не там. У вас есть варианты:
— Оставить как есть и всё. В следующий раз написать с нуля
— Оставить как есть и запомнить где. В следующий раз найти, откопипастить и исправить существующий код. Коллеги сами пусть мучаются.
— Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.
— Вынести во вспомогательный класс, класс вынести в отдельную библиотеку, Написать документацию.
— свой вариант
Как вы заглядываете в будущее и показываете полезность метода N, если начальство при любом раскладе смотрит на вас уставшим взглядом и говорит «да ну, когда ещё сортировка нам пригодится»?
Тот же вопрос по прошествии года, когда в коде уже 12 сортировок пузырьком, а начальство по-прежнему смотрит на вас уставшим взглядом и говорит «да ну, теперь то ещё сортировка нам точно не пригодится»
Проходит ещё год, сортировок уже 150, но больше доделок ну вот совсем не планируется. Ну может быть вот ещё последняя, но точно последняя.
khim
Только не нужно всё воспринимать догматично. Скажем переход на новую архитектуру процессора происходит-таки регулярно (в соответствии с пословицей), но происходит это примерно раз в 10 лет в среднем, так что для большинства проектов это то, что «больше никогда не случится».
Так что ждать пока появится 150 сортировок не стоит, но и выделять что-то в отдельный модуль не имея двух-трёх точек, где оно используется — тоже не стоит. Оптимальное число, пожалуй, всё-таки как раз три а не два: вам нужно продумать интерфейс, а практика показывает что два варианта использования таки маловато. Вообще чем больше мест где ваш модуль будет использоваться тем проще спроектировать его интерфейс — но и тем сложнее все места переделать.
areht
Практика показывает, что
1) на большом проекте люди не в курсе, что эта копипаста и вообще где-то есть ещё, поэтому каждый раз — второй.
2) 2 одинаковых копипасты не бывает. Их нельзя просто взять и обобщить не пойдя, как минимум, по третьему варианту.
А в мысленном эксперименте я специально не сделал опции «2 места» или «3 места». У вас есть или одно место, которое абстрагировать не за чем. Или дюжина, которые обобщать долго и дорого. Или совсем задница.
Как это получилось — не суть важно (те люди тут уже не работают).
Но вам надо с этим жить, пока начальник с тем же усталым видом говорит «Только не нужно всё воспринимать догматично».
khim
И из этих двух вариантов первый — гораздо лучше. Ибо в смысле поддержки он примерно столь же ужасен как и последний, но времени на его разработку и на работу с ним уходит меньше. А после налаживания взаимодействия между командами и людьми вы можете выделить-таки время на рефакторинг и реализовать одну «самую правильную» версию сортировки тоже будет проще (заменить реализацию «по месту» на вызов универсальной реализации обычно проще, чем объединять «универсальные реализации», так как в реализации «по месту» есть только то, что конкретно в этом месте нужно, а в куче «универсальных реализаций» обязательно найдётся куча фич, которые непонятно как реализовать в одной «универсальной реализации»… и которые, в общем-то никому нафиг не нужны).
Вот потому я и предлагаю ваш «универсальный класс» писать после появления третей реализации. А для того, чтобы этот момент заметить при копировании кода из одного места в другое в обоих местах нужно добавить комментарий, объясняющий, где находится второе место. Ну или если случай простой, то вместо копирования можно уже на втором разе выделить общий класс, описать его интерфейс и т.д. и т.п.
В таком случае нужно это обсудить с теми, кто работает и, возможно, даже переписать заново пару компонент.
areht
> В этом случае вам уже ничего не поможет.
Я же с этого начал, «Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.»
> А после налаживания взаимодействия между командами и людьми вы можете выделить-таки время на рефакторинг
Не могу, ибо «все эти действия точно никакой экономии не несут и, соответственно, бессмысленны» пока не доказано обратное.
> Вот потому я и предлагаю ваш «универсальный класс» писать после появления третей реализации.
Ну не то, что бы плохое предложение. Спорить я не буду. Я повторю, что кейса «после третьей» в мысленном эксперименте нет. Совсем. Я не спрашивал «когда надо писать».
> вместо копирования можно уже на втором разе выделить общий класс, описать его интерфейс и т.д. и т.п.
> возможно, даже переписать заново пару компонент.
Нельзя, ПМ рефакторинг не одобрял. Обоснуйте экономию?
khim
Вот как раз перевод существующего кода на новый интерфейс — тут сложнее, может оказаться, что «овчинка выделки не стоит».
А если обоснование «не срастается» (то есть никак не вытанцовываетя экономия даже при самых оптимистичных допущениях), то вы не поверите, нужно-таки оставить эти сортировки в покое и не париться.
areht
1) Если игнорировать грустный взгляд ПМ и его слова о YAGNI, то вы обосновали «сделать функцию», но не «рефакторинг старого».
2) Любая новая копипаста не имеет истории и к ней такой подход не применим.
3) Я могу сделать достаточно оптимистичные допущения, что бы срослось.
khim
Ну это вы уже начинаете рассказывать сказки. Да, отличия бывают, но если бы мир был устроен так, как вы его хотите представить, то никто вообще ничего бы не смог спланировать. В первом приближении любая новая копипаста устроена так же, как и все предыдущие, для грубой оценки большего и не нужно.
Но сможете ли вы убедить в них PM'а? Учтите, что ведь по окончании работ он будет иметь возможность сравнить то, что вы обещали с тем, что реально получилось…
areht
> и более глубокая, чем вам кажется.
Серьёзно, перечитайте условия мысленного эксперимента, прежде чем мне истину открывать.
> В первом приближении любая новая копипаста устроена так же, как и все предыдущие, для грубой оценки большего и не нужно.
Вы опять не туда. Без разницы как она устроена, её никто не поддерживал, нет статистики.
> Но сможете ли вы убедить в них PM'а?
То есть вы тоже не можете, понял. Мысленный эксперимент на этом и закончим.
> И если он даже в таких, «тепличных» условиях не может «заглянуть в будущее» настолько далеко, чтобы показать, что от его действий будет какая-то экономия, то, стало быть, все эти действия точно никакой экономии не несут и, соответственно, бессмысленны.
Это чушь, вы никогда скептически настроенного ПМ не убедите в эффекте и это путь в никуда.
Не скептически настроенный ПМ всё равно проверять не полезет.
Да и невозможно проверить эффект на достаточно длительном промежутке (или ишак, или падишах)
Krypt
А ещё в каждой из реализации Баги. Причём в каждой разные.
vedenin1980
Вообще, у нас для таких целей был технический менеджер, то есть самый крутой бывший программист, делящий с ПМ ответственность за проект.
Почему в точности? ПМ должен хотя примерно представлять что ждет проект и прикидывать вероятность пользы и успеха. Из разряда:
— Давайте мы построим кран?
— А нафига? Мы же строим пятиэтажку.
— Ну, если а вдруг заказчик захочет построить небоскреб, это сильно нам потом время сэкономит.
— Не, ребят, небоскреб он точно не захочет, у него боязнь высоты.
svscorp
У меня 12 лет программерского стажа. И я с вами не соглашусь в корне :)
ПМ не должен знать технических деталей. Вы (команда) — ответственная и автономная единица (до первых косяков). Если команда решает подзабить на план и порефакторить — то менеджер автономность будет убирать и будет микроменеджить девелоперов, «как пастух своих овец», извиняюсь за аналогию. Вам это надо?
Интересно, как обрадуется команда, если ПМ решить невыдать всей команде бонус, т.к. потратит его, например, на покупку растений в офис, где работают девелоперы. И когда люди начнут приходить с вопросами, он скажет (например): «Ребят, у вас теперь среда какая комфортная. Это важно для вашей будущей работы, что бы дышалось хорошо и это окупиться в будущем вашим здоровьем и настроением».
Вот интересно было бы послушать реакцию девелоперов :) И если эта реакция будет отличная от: «конечно, все верно, молодец ПМ!», то следует ли из этого делать вывод, что команда — необразованная и непонимает важности комфортной и разряженной рабочей среды для коллектива? :)
Суровая правда жизни, что программеры забивают на ПМа, считая, что уменьшение technical debt важнее, чем delivery. Поэтому и плодятся у нас говноотношения между менеджерами и девелоперами.
Последние несколько лет я работаю в командах с налаженной коммуникацией. Если нужно заложить время на улучшение кода или его изменение в пользу стабильности, масштабируемости и прочего, это обсуждается девелоперами еще до планирования этапа (внезапно возникла необходимость переписать полпроекта? харош...). На планировании это выносится на повестку с аргументированием, почему это важно (надеюсь, не будет вопроса «чтоооо? еще и аргументировать ему надо? да он необразованный, раз не понимает»… может быть, вы сами не образованы, если не можете аргументировать необходимость чего-то бизнесу?).
Я еще ниразу не встречал ситуации, когда менеджеру сообщалось бы: «нам нужно провести оптимизацию/рефакторинг, и это очень важно для проекта, т.к. нагрузка на продакшн сервере уже превысила 70%, и если мы не возьмем это в этап, на следующей неделе наш продукт ляжет и мы потеряем клиентов и деньги», и менеджер в ответ говорил бы: «нет, в этап берем только новые фичи» :)
Я еще ниразу не встречал ситуации (по крайней мере, с компетентными девелоперами), которые встретив препятствие вчера не сообщили бы о нем команде сегодня и если препятствие не устранено — менеджеру к концу дня, что бы он понимал риски по реализации той или иной задачи. И что бы менеджер после этого спросил с команды — «мне пофиг, почему задачи не выполнены»…
DrPass
Квалифицированный ПМ совершенно не должен понимать, зачем нужен каждый конкретный класс в программе. Его задача — обеспечивать общий ход работ и коммуникации. Есть в команде архитектор системы, есть тимлиды/сеньоры, они и решают, где там быть дополнительным вспомогательным классам. Задача ПМ'а (если он сам не выходец из их кругов) — консультироваться с экспертом в соответствующей области, и принимать решения по советам эксперта. Но если тимлид необходимость этой вспомогательной задачи не обозначил, а программист «проявил инициативу», и вместо данного ему тасклиста занялся украшением архитектуры, то ПМ вполне резонно даёт ему по шапке. В самой инициативе нет ничего плохого, наоборот, это замечательно… но она должна выглядеть как-то так: программист подходит и говорит: «Вот есть такая потребность/идея, с ней будет вот так-то хорошо, без нее будет вот так-то плохо, но она потребует дополнительно столько-то времени». А ПМ говорит: «Ок, это правильно, делаем». Или говорит: «Да, это было бы неплохо, но если мы выкатим продукт без этой штуки, то продажи стартуют на неделю раньше».
Mox
Договороспособность и взаимопонимание менеджера и команды стремиться к 0. Как они вообще проекты выпускают? Почему им насрать друг на друга? Откуда такая сценка — фантазии или быль?
И что хотел узнать менеджер своим вопросом, если получения ответа все равно его задает?
Уровень коммуникации как у каких-то барыг из фильмов. «Где мой товар?»
svscorp
И действительно. Почему задачи не закрыты?
— Работа по вспомогательным классам для x, y и z была включена в этап? Если нет, то почему вы этим занимались в ущерб этапа?
— О том, что вместо работы над задачами, вам необходимо было делать что-то другое было ли сообщено кому-то (ПМ-у)? Если нет, то на что жалуемся, где закрытые задачи?
— Когда пришло понимание того, что задачи этапа не будут выполнены? Только в последний день этапа протяженностью в месяц? Да что за бред.
Действительно, описанный диалог довольно типичен у нас. Он бы не состоялся (точнее, состоялся бы подругому), если бы в команде была бы хорошая коммуникация.
Lovesuper
Если вам не нравится это — смело уходите. Зачем терпеть это?