Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Ещё один безнадежный проект

Эта статья связана общей мыслью с предыдущей заметкой о документировании.

Если вы читали книгу Эдварда Йордана «Путь камикадзе», то вы наверняка помните его шикарную классификацию «безнадежных проектов». Я, конечно же, не буду пересказывать содержание книги, но в свою очередь хочу дополнить его список новым типом — это «старый безнадёжный проект».

Приходя в новую фирму, вы пытаетесь понять, с чем и c кем вам придётся иметь дело. Если вы попали именно на такой проект, то уже на первой встрече точно удастся распознать следующие симптомы:
1. Это «серьёзная международная компания».
2. Возраст проекта составляет 4+ года.
3. На проекте присутствуют бессменные «серьёзные специалисты», находящиеся на проекте в одной и той же должности в течение четырёх и более лет.
4. Компания не считает нужным обучать своих сотрудников в рабочее время («это личное дело каждого»).
5. Состояние и актуальность документации оставляет желать лучшего, если она вообще есть.

И при всём этом вам предлагают «развивать проект».

Что на самом деле это означает?

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

Солидный возраст проекта может говорить о двух вещах: во-первых, он должен быть достаточно прибыльным, чтобы просуществовать такое длительное время, а во-вторых, в проекте типа «старый безнадёжный» вас ждут тонны сильно связанного макаронного кода — я гарантирую.

Почему так происходит? Потому что команда, начавшая проект, не потрудилась должным образом организовать процессы девелопмента и придерживаться их (в частности, не проводили своевременный рефакторинг), а менеджеры и руководство — не особо интересовались процессом разработки: «Сделай всё что угодно, но чтобы к понедельнику эта фиговина была готова!» — «Но как же рефакторинг? Мы не сможем так просто впилить эту фичу, нам придётся делать костыль!» — «Меня не интересуют эти твои программистские штучки, мне нужен результат!» — «Ну ок, будет сделано». — И эта ситуация продолжается бесконечное количество раз.

Собственно, подобные проекты безнадёжны с точки зрения развития. Да, они могут приносить деньги, но они не эволюционируют. А разработчики, надолго ввязавшиеся в эту авантюру, — закисают, медленно деградируют, уверенно скатываясь в состояние технологических ретроградов. Зато стабильность.

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

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

В результате мы получаем не просто программиста, который сидит на одном месте годами — со временем, вследствие отсутствия обучения новому, он просто теряет свою квалификацию.

Так как на документирование времени сначала тоже нет, а потом руководству всё равно «это не интересно», то наш неквалифицированный старожил-ретроград превращается в «незаменимого» сотрудника, ведь только он знает, что происходит внутри проекта и как оно работает. А документации нет.

Все эти нездоровые процессы являются симптомами одной и той же болезни, которая называется «и так сойдёт». Да, да, этот проект тяжело и хронически болен. И вот в таких условиях вам предлагают «развивать»:
«Эй, Джо, пришей пациенту ногу.» — «Но зачем? Пациент ведь мёртв. И что это за дурацкое имя в карточке — Франкенштейн?» — «Мы слишком долго работали над ним, чтобы так просто бросить. И вообще, что за претензии — сказали пришить — значит пришей, и не задавай дурацких вопросов!»

Какое будущее ждёт вас?

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

Чтобы оценить масштабы распространения такой «корпоративной культуры», достаточно вспомнить, как часто в описании вакансий мы читаем: «терпеливое отношение к чужому коду». Эта кодовая фраза означает, что вам предлагают поработать, простите, с быдлокодом.

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

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

Какое будущее ждёт сам проект?

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

Возможно, медленно, коряво, но всё же свои функции он выполняет. Пока. Основная сложность заключается в скорости сопровождения такого проекта. Его очень сложно развивать.

Если у продукта на рынке практически нет конкурентов, например, потому что он обслуживает какую-то крупную монополию (международные корпорации или госструктуры) — такой проект можно считать «условно вечным». Он никогда не будет модернизирован до тех пор, пока код не превратится в совершенное макаронное месиво, от которого будут воротить нос даже самые матёрые гуру рефакторинга.

Жизненный цикл таких проектов:
1. В спешке программисты создают продукт. Всё хорошо, разработка идёт быстро.
2. По мере накопления строк кода проект делается всё неповоротливее и запутаннее. Но проектная команда всё равно торопится, код запутывается всё больше.
3. Происходит наращение штата разработчиков, потому что скорость сопровождения катастрофически падает, а решать эту проблему иначе руководство не способно. Новые программисты, попадая в этот бардак, ещё меньше понимают «архитектуру» системы, и в спешке вынуждены загромождать проект всё большим количеством костылей.
4. Разработка превращается в «костыль-менеджмент». Проект выходит из-под контроля. Всё, конец, epic fail: вносить хоть какие-то значимые изменения больше не представляется возможным, потому что проект рассыпается от малейшего прикосновения, как старая слоёная печенька. Это настоящий проект-франкенштейн, у него нет чего-либо похожего на архитектуру, — просто каша непонятным образом связанных фрагментов.

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

Что можно сделать с таким проектом? Первое: попытаться отрефакторить, если это ещё возможно. Второе: переписать заново. Но в этом решении есть свои «комплексные грабли», о которых я напишу в следующий раз.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



130 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Captain вещает — важна совместимость нового разработчика с коммандой, качеством кода, подходу к разработке, самой прикладной областю. То, как быстро новичёк сойдётся с этими факторами. Уметь оценить для себя эти вещи перед сменой проекта/работы — бесценно.

Индивидуально можно конечно вычислить для себя пару глобальных «правил», по ктороым проекты могут быть априори неинтересными. Для меня например — использование одной бесплатной субд. Показательно тем что есть более бесплатная и технически значительно лучшая альтернатива (IMO). И если архитекторы-разработчики настолько существенно ошиблись в таком серьёзном вопросе как хранилище данных, и хуже того — не имея хороших аргументов продолжают настаивать на верности своего решения, то можно представить что они понаделали со всеми остальными техническими моментами. На практике верность этого аргумента я проверил несколько раз => имею эмпирическое правило; наверняка оно не подойдёт подавляющему большинству комрадов.

Можно поинтересоваться какую из бесплатной субд вы считаете плохим выбором а какую хорошим?

Я сознательно скрываю это во избежание flamewars; цель того комментария — прояснить иной процесс, sorry :)

Можно поинтересоваться какую из бесплатной субд вы считаете плохим выбором а какую хорошим?
Плохая MySQL, хорошая PostgreSQL — частовстречаемый комплекс постгресников :)

Якщо такі проекти розвиваються (як мінімум підтримуються) — це означає що вони до тепер приносять прибуток, а це означає що вони корисні людям. А великі проекти приносять користь сотням і тисячам користувачів. Порівняйте це з стартапами, які ще не мають жодного користувача, і примарні перспективи. Це по-перше.

По-друге — старі проекти використовують старі технології. Це очевидно. Так само як і архітектура цих проектів була продиктована трендами цих років, коли проект активно розроблявся. На мою думку дуже корисно інженеру заглибитись в ці проекти щоб зрозуміти наслідки тих чи інших рішень, що були прийняті. Це дасть більше користі в майбутньому ніж зробити пару маленьких програмок з нуля. Взагалі робота в саппорті є дуже корисною для всіх, бо вона показує як «геніальні» дизайнерські і архітектурні рішення руйнуються при зустрічі з реальністю.

По-третє — стосовно переписування (не рефакторингу, а переписування) Джоел ще 14 років тому написав статтю www.joelonsoftware.com/...0000000069.html. Жаль що дуже часто програмісти не люблять читати не тільки код а й книги, статті та вчитись на помилках інших.

Я звісно не за те, щоб присв’ячувати життя саппорту, але вважаю цей досвід дуже корисним. Ті інженери що перейшли через це стають більш виваженими у рішеннях і спокійнішими до нових віянь в ІТ. Вони розуміють що таке хороший код, який сапортиться сотнями людей, хороша документація і хороша архітектура.

Не совсем согласен с изложением и выводами, вы взяли некоторые утрированные случаи загубленных legacy-проектов. Я убежден, что если поставить дела на самотек, иными словами — забить на проект и отдать все на откуп «команде», то будет загублен любой проект, даже с нуля на супер-крутых технологиях. Возможно есть смысл грамотно настраивать бизнес-процессы в некоторых организациях?

Я также не вижу самой проблемы, разумеется любой разработчик стремится участвовать в новом проекте «с нуля», но сейчас таких проектов все меньше и меньше, интегрировать кучу фреймворков в проект с нуля — тоже ведь legacy-код? Ну и чем опытнее становится разработчик, тем лучше понимает, что есть смысл отбросить максимализм и заниматься делом, сапорта все больше, разработки с нуля — все меньше.

Ваша аллегория про банку с огурцами как минимум странная и люди, сапортящие ERP/facebook потихоньку смеются.

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

Ну а ваше убеждение на счёт отпускания дел на самотек — чем не подтверждение моих слов
Это частные случаи, пусть плохие, запущенные, но частные. Отечественный аутсорс уже вырос из коротких штанишек и подобный подход для ТОП-25 DOU и просто уважающих себя компаний — редкость и постепенно искореняется совсем.

Олег, когда рейт таких франкинштейнов перевалит за 50/50 в сторону пацанов в нормальной длины штанишках, которые не поддерживают индийские поделки и сами могут настроить процесс, я вам поверю

Люди, саппортящие facebook/vk, не смеются, а создают новые технологии, чтобы как-то обойтись рефакторингом бизнес-кода, а не переписыванием с нуля на старых.

Сумбурное описания доброй половины разрабатываемых проектов в индустрии.
Чтобы вычислить такой на самом деле не нужно ходить со списочком и ставить галочки, а быть внимательным на собеседовании, обращать на уровень собеседующих и задавать вопросы(например: как у вас обстоят дела с обучением в рабочее время?).
Советы отрефакторить или переписать целый проект — для героев с голыми задами штурмующих амбразуры. Чтобы их не давать нужно поучаствовать в разработке с нуля чего-то масштабного. Заодно и посмотреть как ваше уси-пуси детятко превращается в уродливого франкеншейна, которого проще пристрелить. Смыть, учитывая прошлый опыт повторить. Так и появится важное знание: как НАДО, а не НЕ НАДО.

Я б послав такий проект на другий день, якби потрапив туди. Не пройшли випробувальний термін в мене.

Для мене єдино прийнятне рішення.

То спочатку треба зрозумiти, що це сама вiн. Бо воно з першого погляду може й ганим здаватися. Вони ж самi нi за що не зiзнаюся )

А в какую банку надо покласть соленый огурец, чтобы он стал свежим? :))

а что нужно сделать, чтобы опять стать ничего не знающим студентом?

для меня — поступить на химический факультет )

но опыт предыдущих лет — он ведь всё равно никуда не денется, правда.

мой опыт в химии ... безусловно он никуда не денется :)))
и даже с моей смертью он не уменьшится.

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

Всё верно. Однако фишка в том, что даже если на такой проект приходит профессионал — он не в состоянии один бороться с устоявшимися процессами. Даже если он что-то отрефакторит — никто не будет пользоваться этими плодами. Все и дальше будут так же, простите, гадить в проект, как и раньше.

я пробовала — не помогает. Только обижаются. А учиться всё равно не хотят.

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

Например, ты говоришь человеку: «Надо отрефакторить такой-то и такой-то кусок», — а он тебе: «Че? Отрефакторить?», — а ты продолжаешь: «Ну, понимаешь, мы получим вот такие и такие профиты.» — «И че? И так всё хорошо работает» — «Вот план рефакторинга. Это займет столько-то времени, я могу это сделать» — «Ничего не надо, это слишком долго, всё и так хорошо. Я тут два года работаю, а ты сколько — два месяца?» & so on. И в какой-то момент ты понимаешь, что человек, с которым ты обсуждаешь технические моменты — он просто не понимает, о чём ты говоришь. И вы с ним в одной команде. При чем тут Бог и тщеславие, если это банально нужно для того, чтобы на одном языке со своими сотрудниками общаться.

У меня было хуже. Это был мой руководитель.

он должен выполнять твои поручения в рамках служебных обязанностей
Он никому ничего не должен, к сожалению. На данный момент ситуация на рынке такая что увольнение пугает только совсем джуно-студней (и то не всегда), а увольняют только самых упоротых.
Один кадр не хотел слушаться, пришлось уволить.
А тут уточнение: Сколько времени прошло от того момента когда он «перестал понимать» и до того как его уволили? Как быстро нашли замену?
И куда более важный момент: Его уволили за говнокод? Или за то что «посмел дерзить»? (Подозреваю что за второе. Тут нет ничего предосудительного, если че.)
.
P.S. И это все очень печально.
Замену нашли за 2 недели.
По-доброму завидую, мы не можем найти адекватного джависта уже год.

У меня есть подозрения, что Вы по разному трактуете слово «адекватны»..

да че там просить — вешает на такого Mчудилу тикет с топ-приорити и блокером, задача: «отрефакторить», ставишь естимейт, и «вперёд, к звёздам!»
остальные задачи можно поставить на паузу, если естимейт не большой и более приоритетных задач нет
таск не закрывается, пока пулл реквест не проавпрувлен, вот и всё

Однако фишка в том, что даже если на такой проект приходит профессионал — он не в состоянии один бороться с устоявшимися процессами.
С процессами бороться можно, проблема будет если команда не хочет развиваться, тогда надо менять __команду__.

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

Да ладно Вам. Если на проект приходит профессионал и видит вокруг всеобщее распиздяйство, то он сразу шурует «наверх», рассказывает в каком говне все вокруг плавают, но действует по принципу «критикуешь? предлагай!» и предлагает отрефакторить бизнес процессы, дев процессы и прочая прочая, в конце — код. И если ему дают «вожжи», а то есть он не просто уже плывёт по течению, а реально меняет «положение вещей» на проекте, начиная «сверху вниз» — то все постепенно устаканивается.
Но для этого должно быть несколько вещей:
— он должен быть профессионал до мозга костей, то есть иметь твердость, умение говорить «найух!», т.е. «no!», иметь систематический и структурный подход к текущей ситуации
— этот профессионал уже делал «это» на более мелких проектах
— «вожжи» не метафизические, а вполне себе ощутимые, стеганые, оставляют «рубцы» на телах взбрыкивающих «лошадков»
— желание, т.е. мотивация бить «лошадков» и действительно привести ситуацию в порядок — чаще всего это не просто БОЛЬШАЯ ЗП, а ещё и опцион в компании/проекта или бонусы и премии в течении процесса «оздаравливания» на разных его этапах
— и главное — план оздоровления, расписанный и поэтапный, который рождается не за 5 минут, а после тщательного «аудита» текущего плачевного состояния и осознания всех рисков и прочего — на что чаще всего «бизнес пойтить не могёт»
потому и приход профессионала на проект чаще всего в заканчивается ничем из-за последнего пункта

а насчёт «отрефакторит — никто не будет пользоваться», для всего этого есть программные решения, начиная от автоматического кодинг стайла после комита, заканчивая запретами мержа в мастер всякого *овна всеми «непосвященными» — а только после аппрува «пулреквестов», и выпиливанием из стека технологий остатков дерьма древних мамонтов в виде давно умерших технологий

Не вижу какой-то проблемы. Разве что только если менеджмент невменяемый и не дает что-то делать, засыпая мелкими задачами.
Работать с чужим говнокодом не так уже и плохо, хотя может и раздражать. У программиста значительно растет уровень, когда он учится читать чужой код. Хороший код читать легче, а говнокод — плюс к карме.
А если не дают работать и улучшать проект, то можно и уволиться

Каждый слышит то, что понимает. В этой статье я пишу не о том, почему переписывать говнокод — это плюс к карме, а о том, как такие проекты получаются. Если вы понимаете эти механизмы — то стремление писать говнокод у вас резко падает и появляется желание вырваться из этого порочного круга. Стремление к профессионализму — это то, что должно быть в каждом разработчике. Иначе у нас получится «ещё один безнадёжный проект».

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

Как бы по моему есть два интересных случая для роста программиста:
1) попадает на начало проекта и начинает с нуля
2) попадает на проект, который надо улучшить, который написан плохо.

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

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

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

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

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

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

При этом, есть еще тема, что даже с большим опытом программисты считают, что им должны платить за опыт. Т.е. они себя должны уважать и так себя ставить, приходить на работу и торговать лицом. А им должны платить, потому что они не какие-то джуниоры, а знают много. (т.е. между «знаю» и «делаю» они разницы не видят) ))

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

А я уже както перестал верить в «опыт» в контексте знания херновы кучи технологий и языков, по мне так — профи это тот кто умеет реально оценить задачу и сделать ее в приемлемом качестве в приемлемые для заказчика сроки и чтобы архитектура была расширяемой и легко поддерживаемой относительно недорогими прфессионалами в будущем.

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

На смену ему в компании пришло громоздкое неповоротливое тормозное криворукое уе... под названием эклипс.... вот и думай после этого

А вообще — это конечно проблема — что программисты весьма далеко от получателей выгоды от конечного продукта, если бы это было не так, то процесс был бы немного другим ... я так думаю

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

Был у меня один проект, где я был непосредственным получателем 50% прибыли (не считая оклада). Разошлись с партнером, поскольку я считал вполне достаточной прибыль в 4-5к долларов на двоих в месяц для free-play и старался сделать игру интересней для большинства, которое не платит, расширять аудиторию, чтобы, в идеале, выйти на аудиторию в 100к человек, где один из ста не пожалеет 10 баксов на чистый донат. У него же были планы выйти на аудиторию в 10к человек, где один из десяти тратит минимум 100 в месяц на «пэй-ту-вин».

но опыт то, согласись, стоит того :)

пысы я в 90е работал далеко от программирования так что частенько видал как
подельники просто пропадали ;)

В какой-то мере стоит, да. Стоит держаться подальше от управления бизнесом :) Можно выступать инвестором и техническим работником, абстрагируясь от того, что это твои деньги во время технических совещаний, и абстрагируясь от того, что тебе это реализовывать, во время «собрания акционеров». Можно, но сложно. Потому деньги лучше вложить в один бизнес, а работать в другом.

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

В какой-то мере да, появился такой опыт, но он из разряда «спасибо, Кэп»: нет такого преступления изменения ТЗ, на которое не пойдёт капитал ради 300% прибыли, известно давно :)

с таким пессимистичным настроем слона лучше не продавать ;)

С некоторых пор ( с 90-х :) меня волнует этичность бизнес-процессов и способов монетизации продуктов, над которыми я работаю.

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

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

Метрики, понятно, тяжело какие-то вводить. Я больше говорил о психологической составляющей. Когда программист совершенно не только не заботится о своей производительности, а иногда и саботирует работу. Или работает ОООЧЕЕЕЕНЬ медленно. Думая, что так его работа выглядит основательнее.

Думаю, от опыта это мало зависит :)

Почему вы видите себя на его месте? ))

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

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

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

Т.е. если в мире существует некоторая доля неопределенности, то из этого следует, что в нем не существует закономерностей?

Другими словами, если я не знаю точно, что думают другие программисты, то они — абсолютный черный ящик?

Выше я высказал свое личное мнение: каждый программист должен оценивать свою эффективность. Но если бы так все делали, этой беседы не возникло бы.
Весь мой спич в том, что программист должен себя оценивать, пусть даже субъективно. А не других с точными метриками. И как раз о том и говорю, что некоторые программисты осознанно не хотят и противятся такой оценке. Т.е. ни капли не хотят себя представлять на месте работодателя и не задают вопрос, а за что он им будет платить.

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

Видимо аутсорс портит людей

Оценивать программист себя может исключительно по рынку труда. Сколько прибыли (или убытков) он приносит фирме на рынке продукта не его дело. Абсолютно одна и та же работа (с точностью до байта и в ТЗ, и в коде) одну фирму может вывести в лидеры рынка, а другую ввергнуть в банкротство — от программиста тут ничего не зависит. Его дело реализовать ТЗ в срок, максимум составить его по бизнес-требованиям и дать бизнесу как можно более точные оценки сроков. Если бизнес такое ТЗ и такие сроки устраивают, то все риски (включая риски «саботажа» и срыва сроков) они берут на себя.

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

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

И в который раз скажу, я говорю не со стороны работодателя, а со стороны программиста: он сам себя по идее должен как-то оценивать по производительности. Иначе это просто ничем не обоснованная работа ЧСВ и эго.

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

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

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

И чтобы избегать прокрастинации, дам совет. Работать надо «в потоке». Включиться и работать, не отвлекаться. Отвлекся, включиться в поток снова очень сложно. Вообще, это знают все программисты наверное, просто не все озвучивают. На 10 минут отвлекся в нет, почитал новости, полчаса входишь в рабочий режим потом. (да, кстати, чтобы меня не упрекали, что я сижу на этом сайте прямо сейчас, скажу по секрету, что я уволился ))

И я не говорю о том, что надо кодить сломя голову, забыв о качестве, главное количество. Но производительность в работе даже при одинаковом качестве отличаться может в десятки раз. Читайте Роберт Гласс. Факты и заблуждения профессионального программирования
Там рассказано об исследованиях и что разница может достигать 28 раз.

И не стоит уже пороть явную чушь, что говнокод не отличается от нормального кода, что производительность нельзя точно измерить, значит ее нет. Есть конечно. Хотя бы посадите разработчиков и дайте сделать одну и ту же задачу. Один будет делать день, второй неделю, третий может и месяц. Один 200 строк напишет и решит задачу, второй 2000. Разница очевидно в работе есть. И усугубляется это тем, что каждый на первый взгляд одинаково сидит на жопе и смотрит в монитор. А делать могут совершенно с разной скоростью, вплоть до нулевой.

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

Про неизмеримость скорости я не говорил — вы меня перепутали. Я говорил про то, что важна средняя скорость на довольно длительном отрезке времени. Другое дело, что если скорость конкретного программиста сильно колеблется («муза» пришла или не пришла), то рассчитывать на то, что ему будут оплачивать пиковую, а не среднюю, с его стороны несколько неразумно.

Ты уже оцениваешь другого программиста.
Точно. Оцениваю. А бывают оценки без соотношения с другими?

Смотри. Я говорю о субъективном отношении к себе и своему труду. Если ты становишься в позу и думаешь:
— Я такой весь классный и пошли все в зад, если думают, что я должен работать эффективно
То ты автоматом будешь работать ОЧЕНЬ медленно. Потому что у тебя такое отношение к труду.

Такая аналогия. Два человека ходят на рыбалку, сидят на противоположных берегах. Один ловит рыбу, а второй бухает и даже удочку не закидывает. В конце месяца немного закинул. В конце месяца сравнивают улов, у первого больше. А второй:
— Как вы можете сравнивать??? Может у меня рыба была сложнее, или она не доплывала до этого берега. И вообще я хотел ловить щук, их ловить сложнее.

!!! Внезапно появился во вселенной человек умнее меня )))

Ладно, договорились, не будем обсуждать мои фантазии

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

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

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

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

Ага, стандарты по именованию, как же-как же. Тоже, наверное, помните, стандарты типа «переменные программы именуются по порядку появления в тексте программы согласно латинского алфавита»

Вообще говоря, многие низкоуровневые паттерны призваны лишь компенсировать недостатки возможностей конкретного языка, по сути являясь лишь компенсацией недостатка «сахара» в синтаксисе. И на личном опыте, и по признаниям многих других программистов, при чтении книг типа GoF очень часто возникает мысль: «я это само придумал и уже годами пользуюсь, а оказывается это имеет название». Причём многие эти паттерны применимы разумно лишь к языкам типа «Си с классами», а функциональные и/или языки с динамической типизацией в них не нуждаются. По сути низкоуровневые паттерны являются стандартным названием общепринятых приёмов обхода недостатка синтаксиса конкретного языка. Архитектурные же, типа MVC, являются стандартным названием некоторых архитектурных приёмов. По большому счёту ни первые, ни вторые к качеству кода особого отношения не имеют. Их преимущество лишь в том, что программистом «в теме» они распознаются либо по названию («Угу, раз говорят что используется MVC, то значит нужно искать модели, вьюхи и контроллеры»), либо по самому коду («Блин, не могли вместо ApplicationOneInstanceClass класс назвать ApllicationSingleton как все белые люди»")

Переформулирую своё мнение: соответствие ТЗ является необходимым, но не достаточным условием качественного кода. Но остальные условия слабо формализуемы (если не брать проверки типа табы или пробелы или стиль {}) и, чаще всего, субъективны.

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

А может им давались просто гораздо более сложные задачи. как в примере с Васей и Федей.
Вот ты например опытный или нет? А если я тебе подкину задачку из области в которой я опытен, а ты нет?
А я и не претендую на то, что знаю как измерить работу точно. Но бывает, что люди и целый день в нете шарятся. И просто явно бывает разница в производительности в 10 раз. Ладно в 2-3 если бы было.
Программирование — это такая хрень, где люди вроде сидят за компьютерами одинаково. А выход от их работы может быть кардинально разным. Некоторые вообще не видят цели и не идут к ней, даже если кодят.

Да ну конечно, приблизительно можно давать оценки. Или уже говнокод никак не отличить от нормального кода?
Оценить непросто, если пытаться дать точную оценку, мол Вася производительнее Феди на 14 процетнов. А вот если на 1000%, тут надо задуматься, что не так с Федей.

А бывает, что три дня шарится, а потом за полдня делат то, что другой не шарясь месяц делает.
Это не оправдание того, что он три дня шарился. Умеет быстро, молодец. Тогда просит выше зарплату. Но на рабочем месте шариться, по моему, не очень приемлемо.

ясно, понятно.

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

Нельзя точно == никак.

А если он просил себе зарплату изначально учитывая такие свои предпочтения или особенности? На самом деле не важно шарится или нет, а важно делает ли работу в сроки, устраивающие бизнес. Если я «шаринье» изначально закладываю в сроки, бизнес с этими сроками согласился до начала разработки и я их не сорвал, то я сделал всё приемлемо. Премии особо не полагается, но оклад вынь да положь. При этом бизнес оставляет за собой право искать того, кто будет делать те же задачи быстрее (за те же деньги, большие или меньшие — как договорятся, если смогут).

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

Как бы если ничего не брать во внимание, то в общем, работодателю должно быть всё равно, что делает программист, лишь бы делал свою работу в срок. Но практически это подобно договору: все равно, чищу ли я зубы, лишь бы они были здоровыми. «Все равно, делаю ли я работу или нет, главное, чтобы она была сделана». Ну чушь же.

Я когда-то знал одну девушку, которая всегда, когда узнавала, что я в чем-то лучше, например, в программировании, начинала считать, что она лучше во всем остальном: универсум минус программирование.

Это с чего вдруг человек, который умеет кодить всегда, не дожидаясь музы, хуже, чем тот кто ее постоянно ждет? Или к первому она не приходит из-за ревности?

Я так скажу. Весь опыт показывает, что есть муза — бери клавиатуру и набирай код. Нет музы — бери клавиатуру и набирай код, она подтянется. А если будешь читать анекдоты в ожидании музы, то она заглянет и подумает:
— Да этому чуваку пока не до меня, пойду дальше

)))

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

Я бы не противопоставлял требование приходить в 9.00 и то, как работаешь. Вещи не взаимоисключающие.

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

Мы тут спорим так, как будто бы какое бы условие я не ставил, я всегда отбираю у вас главное — хорошо делать свою работу. Т.е. всё началось из утверждения, что программисты не всегда хотят оценивать свою производительность и стремиться быть производительными. По вашему, если они захотят быть производительными, это значит, что они станут плохо программировать. Если их заставить приходить в 9.00, то они станут хуже программировать.
Капризная такая каста.

>>"Все равно, делаю ли я работу или нет, главное, чтобы она была сделана". Ну чушь же.

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

Конечно. Мой опыт говорит, что напрягаться надо постоянно, но на процентов 80. Не забывая о качестве, работать постоянно, не отвлекаясь. И от звонка до звонка, без лишних задержек на работе, с нормальным отдыхом, сном и питанием. Тогда всё ОК. Средная производительность высокая. И не устаешь, не изматываешься.
А вот, постоянные отвлечения и безделие куда больше создают усталось, психологическую в первую очередь. Такой парадокс. Чем больше отдыхаете, тем больше устаете.

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

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

Не всё так плохо. Существуют методы улучшения проекта без особого ведома менеджмента. Самый простой: называть сроки с учетом покрытия тестами и рефакторинга. Ещё один: новые фичи выносить за пределы существующего приложения, связывая их только через точки входа и хранилища данных (БД чаще всего), причем разрабатывая новое ядро с учетом необходимости перехода на новую схему хранения, а то и полную замену системы хранения, максимально абстрагируясь от неё.

Во-первых, «сроки внезапно возросли» быть не может, потому что разработчик новый и по любому нужно время для вход в проект. А какой вход может быть лучше чем покрытие тестами? :)

Во-вторых, обычно все это просекли давно, и теперь сроки умножают на «пи».

Методы существуют, возможности ими воспользоваться зачастую нет. У манагеров есть свои методы на любые ваши методы. Тот самый случай, когда против топа нет еще большего топа.

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

Связывание через интерфейсы — да, согласна, годная вещь. Но это уже из серии «а можно отрефакторить». Связывать через хранилище — не всегда возможно, ибо если хранилище и приложение спроектировано криворукими бобрами, то толку особого не выходит. Однажды мне такая чудная база попалось, запомнилось поле email, в котором был всякий непотреб: «у клиента нет почты», «email1, email2 — клиент просил отсылать на второй», «email-собака-ком» и т.д. — и выкинуть нельзя, и парсить невозможно. И так оно было везде. Хотелось биться головой о стену. Но что самое печальное — старая команда искренне не понимала, что мне не нравится.

Вообще нужно. Нюансы в деталях, одно дело сказать: «я тут хочу всё переделать и пока не закончу непосредственно к заданию не приступлю», а совсем другое: «я приступаю к задаче и для начала зафиксирую текущую функциональность, чтобы ничего не сломать случайно, а потом, когда примите задачу, оптимизирую код, пока помню его, чтобы в следующий раз не тратить много времени».

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

Не, ну можно просто ничего не делать, да ) Такой вариант тоже существует. Как то индийский программист.

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

либо что-нибудь ещё. Например, компания серьёзная и руководство интересуется процессом разработки. Я всё написала в статье, не нужно перекручивать мои слова.

Не слон = всё что угодно кроме слона. Если я буду утверждать, что если слона кормить морковкой, то он будет хорошо расти, а вы примените «логическое отрицание»: если не слона не кормить не морковкой — в этой фразе будет конкретный смысл?

Просто в статье об одном, а во введении и выводах о другом.
Поясните.

Понятно. Спорщик ради спора.

Можно было бы опровергать каждый пункт
Но не опроверг.
Персонально поясняю: все эти пункты это симптомы одной и той же ситуации — по отдельности они могут встречаться в любых проектах. Но все вместе — только в таких.

Оставляю за собой право больше не комментировать ваши замечания.

Підписатись на коментарі