Комментарии 37
То, что вы описываете в статье на самом деле хорошие мысли для рассуждения, потому что в России есть проблема высшего образования. Но некоторые тезисы скорее вредны. К примеру:
А самим джунам надо повсеместно внедрить мысль о том, что в нормальной организации обязательно должна быть программа по дополнительной квалификации - эдакая внутренняя магистратура, где новички ходят на лекции, выполняют домашние задания и получают за них оценки.
Такая «мысль» будет всем джунам давать надежду, что они могут не усердствовать, их всё равно потом научат, «возьмут за ручку, и приведут в подготовительную группу детсада». И потому уровень знаний джунов может серьезно снизиться.
То, о чём вы пишите по поводу сеньоров фактически менторство, и оно уже применяется в некоторых компаниях, так как это хорошая практика, которая показала свою эффективность. Но здесь есть тоже проблемы, так как ментор - это не нянька, ментор подсказывает, направляет на поиск правильного решения, а не пытается за условного джуна сделать работу. И здесь же бывают проблемы, когда иногда проще и быстрее сделать задачу за джуна, особенно если задача «горит» по срокам, чем пытаться «направлять» джуна на ответ.
Ну и «балалайка» от меня про проблемы написания «хорошего» кода. На текущем месте работы есть коллеги, которые стоят выше меня по уровню (грейду), и они на хорошем счету у руководителей, тимлиды их котируют и к ним прислушиваются, когда происходит обсуждение каких-то вопросов. Но когда я лично смотрю на код ими написанный, я нередко внутренне возмущаюсь тому, что именно этот человек написал такой код. С точки зрения синтаксиса и идиоматики языка программирования код может быть хорошим, но с точки зрения архитектуры всей кодовой базы, написанный код бывает, как выброшенный мусор в окно во время поездки. То есть появляются вопросы «зачем он именно в той части кодовой базы», «почему не отдельным классом, или не отдельным файлом». И эти же люди потом на совещаниях говорят о проблеме чтения кодовой базы, при том, что для решения свой задачи не задавались этим же вопросом. И понятно почему, так как здесь и сейчас они знают свой код, как он был написан и для чего. А что будет потом их уже не волнует. Так как это будет потом. Решать проблему они будут по мере их поступления
Такая «мысль» будет всем джунам давать надежду, что они могут не усердствовать, их всё равно потом научат, «возьмут за ручку, и приведут в подготовительную группу детсада». И потому уровень знаний джунов может серьезно снизиться.
Вот примерно в таком ключе действуют и все конторы, с которыми приходилось сталкиваться мне. Когда джуну намеренно дается "подтянуть" навыки самостоятельно на основании существующей кодовой базы. И шансы того, что он заподозрит в этом коде неладное, и начнет его сразу "улучшать" стремятся к нулю. Он скорее крепко уверует, что так и надо, пока не сам не столкнется с последствиями. По-моему слишком часто можно услышать "ментора" фразы типа: "А ты там посмотри как сделано и сделай примерно так же".
То, о чём вы пишите по поводу сеньоров фактически менторство, и оно уже применяется в некоторых компаниях, так как это хорошая практика, которая показала свою эффективность.
А по поводу "менторства" мое замечание такое, что не всегда (далеко), оно представляет из себя то, что имели ввиду кто этот институт придумывал и внедрял. В идеале, мне кажется, оно как раз должно вырождаться в 6 и 7-й курс университета. Это как с интернами в медицине.
Вы не совсем поняли мой посыл. Условный джун перестанет учиться сам, если его будут учить на каждом новом рабочем месте. Как раз джун должен учиться самостоятельно, но для того, чтобы он учился правильно у него должен быть ментор, который его направит. Проверит его «домашку». Проверка «домашки» должно как раз показать правильно ли джун понимает суть задачи или нет. Правильно ли он принял решение и т.д. И после разбора дать ему совет что почитать, куда заглянуть за примером правильного решения. А «учить» разрушительная практика
А ты там посмотри как сделано и сделай примерно так же
Если бы ментор на регуляторной основе мог бы посоветовать что-то лучше, то код изначально был бы написан лучше
/но с точки зрения архитектуры всей кодовой базы, написанный код бывает, как выброшенный мусор в окно во время поездки.
По тому, что это классно когда тебе дали время на подумать и архитектуру, и дали это воплотить.
Но бывает и так: «а давайте попробуем!», а потом этот «попробуем» по желанию начальства улетает в прод и на твои возражения, что задача изначально была другой, внимания не обращают, что ПМ приходить со сроком и описанием того, что надо сделать "на пальцах", начинать писать надо сейчас, а требования уточняется уже потом, или под конец выясняется, что надо туда вкрутить что-то, что ломает все твою стройную архитектуру, или подвели соседи/подрядчики и тебя надо сделать то, что изначально планировалось на другой стороне...
Да мало ли...
В моём случае ничего не стоило добавить «брошенный» код в отдельный файл хотя бы. Это не систему сборки с нуля перенастроить. Достаточно было один файл создать, одну строчку в скрипт сборки добавить. А то как бывало по моей работе - это выглядело просто как наплевательское отношение, как к своей работе, так и к коллегам, которые после автора кода будут с этим кодом работать.
Очень легко перекладывать ответственность на других. И вы в вашем примере перекладываете на ПМов или начальство. Хорошей практикой является сразу делать «хорошо» даже если это просто набросок идеи. Не отрицаю, что иногда это занимает больше времени, чем просто наговнокодить. Но это снижает риски попадание говнокода в прод по разным причинам, даже самым идиотским
Достаточно было...
Или не было. Осуждать кого-то можно только зная все обстоятельства принятия такого решения.
Хорошей практикой
Немного видоизменю ваше утверждение: мы живем не в идеальном мире, и хорошей практикой является писать настолько хороший код, насколько это возможно в данных обстоятельствах. Код и был хорош для той задачи которую он решал. Но код не является конечной точкой, по крайне мере моей работы. Для "хорошо" нужна как можно более полная информация, время и ресурсы. ПМ и начальство то же не из прихоти такие решения принимает. Если фича нужна к 28 числу, а если к 29 то можно и не делать, в рефакторинг не успеваем, значит делаем как успеваем. Хорошей практикой является писать тесты - аксиома, но не успеваем - практика, значит не пишем, запишем в долг. Если на долг не дали время, так в долгу и останется.
bisnes online
В принципе, возможен и такой вариант: регулярно исправлять и приводить к общему стилю всю кодовую базу продукта, чтобы он выглядел более-менее порядочно en masse. Тогда новичок будет ориентироваться уже не на мутное месиво, а на что-то типа командных best practices.
Документация, опять же ж, автоматические утилиты (метрики/линтинги/форматирование/etc) - здорово помогают, если применяются не для галочки, а осознанно.
Единственная проблема, как такую идею внедрить акционеру?
Разве это зона ответственности акционера? Или зона ответственности команды?
По моему опыту, лучше всего такие чистки идут, когда они находятся "ниже радара" для бизнеса. Т.е., с одной стороны, команда проводит эту деятельность и улучшает жизнь себе, а с другой стороны, эта активность не идёт во вред бизнес-задачам. Проблемы возникают при перекосах в ту или иную сторону. Либо когда команда увлекается полировкой в ущерб задачам бизнеса, либо когда на неё забивают полностью.
Да, на каком-то практическом уровне, безусловно это ответственность ближайшего командира, но, конечно же, акционер должен понимать, что выхлоп от того сотрудники занимаются "кроме работы" еще и уборкой в собственной казарме, в долгосрочной перспективе это прямой доход от экономии на сопровождении. Иначе все-равно руководитель, даже понимая все вышесказанное, подспудно будет расставлять приоритеты "по срочности".
Согласен, такое случается. Универсального совета у меня для такого случая нет. Сам дважды с подобным сталкивался. Сначала пытался договариваться, но потом в итоге уходил. "Е%%тесь сами, удачи!".
На текущем месте работы сформулировал для себя ряд правил, позволяющие контролировать и ограничивать стремления к чисткам. Работает неплохо, кажется. Может, статью на эту тему оформлю.
Мне удалось объяснить владельцу проекта необходимость рефакторига оставленного мне спагетти. Если акцентировать не на аргументах, важных для разработчика (SOLID, читаемость/чистота и т.п.), а на следствиях, важных ему (увеличение стабильности, скорости доставки нового и багфиксов, уменьшение выгорания и т.п.) - всё это будет услышано. Разумеется, при этом owner должен быть адекватным (хотя бы на уровне подсчёта собственной прибыли). Добиться выделенного времени не удалось, но согласовали, что решение текущих задач будет занимать чуть больше времени. В итоге, решая ту или иную задачу, получается привести в порядок тот кусок кода, к которому она имеет отношение. Так постепенно преобразуется весь проект (к слову, довольно большой)
Было бы очень интересно и полезно услышать ваши правила в том или ином виде. Иногда всётаки сложно себя остановить )
Чтобы что то объяснить бизнесу, нужны измеримые метрики. А такие "я думаю", "я уверен" в формулу для подсчета прибыли не подставишь.
А почему вы решили, что разговор был на уровне "я думаю"/"я уверен"? Были озвучены сценарии развития событий с вероятными последствиями. А "с другой стороны" - хватило ума пересчитать это в свои "метрики". Вероятности и их последствия могут считать не только программисты-математики.
Потому, что я не видел разработчика, способного последствия рефакторинга рассчитать на уровне выше "я думаю". Есть интуитивное понимание пользы, не более.
Возможно, прожженные сеньоры могут, но большинство нет.
Что делать бизнесу? Набираться опыту? Пока наберешься, сформируется прослойка эффективных манагеров, которая будет всех гнать "быстрее".
Да, тоже напомнили: коллеге-тезке: "Вова, ты чего там закомиттил 356 файлов?"
-"Директор в тай укатил, можно 2 недели спокойно отрефакториться. Я бы тебе посоветовал сделать тоже самое. Раньше чем через неделю, он про нас все равно не вспомнит".. :)
Либо когда команда увлекается полировкой в ущерб задачам бизнеса, либо когда на неё забивают полностью.
Тут есть момент, что иногда из-за возможного ущерба для бизнеса нет возможности заниматься полировкой кода. И за кода код превращается в месиво. И тут уже не обойтись без участия высшего менеджмента, который примет риски от увеличения сроков поставки продуктов на рынок из-за необходимости полировать код
Увы, эта проблема не единственная. Между, так сказать, "производителями кода" и акционером есть, как правило, толстый слой ушлых ребяток, активно размножающихся чуть-ли не почкованием.
И ваша инициатива для этих деятелей, это прямая угроза их личным кипиаям, метрикам и прочей требухе, с которой кормятся стада "понаехавших в Айти" бездельников. Им на красоту кода вообще наплевать.
"Были книжки с листингами программ, были исходные коды открытых библиотек и фреймворков. "
------------------------------
А еще раньше,была и есть технология структурного программирования.
Как известно, "технология" — это совокупность методов и инструментов для достижения желаемого результата в заданное время и с заданным качеством.
--------------------------
Полагаю, что многие из современных программистов даже не слышали об этой технологии.
---------------------
Попробуйте применить ее и удивитесь достигнутым результатам.
Код будет не только красивым , но и понятным любому джуну.
А главное, разработку софта легко распараллеливать и отлаживать.
Проблема лишь в том, что как всякую технологию, структурное программирование сложно освоить тем, кто уже пишет от всей души, но без технологий.
Проблема лишь в том, что как всякую технологию, структурное
программирование сложно освоить тем, кто уже пишет от всей души, но без
технологий.
И снова оспорю, ибо то же знаю и далеко не один случай из своей практики, когда чел, накатавший тонны легаси, прочитав Дейкстру, структурное, модульное программирование начинал писать вполне вменяемый, расширяемый и поддерживаемый код. Парочка случаев, так и "сразу" после прочтения. По-разному..
Не могу согласиться с пассажем о старшем, которому трудно признаться что именно он тут "наворотил", требуя от джунов "правильного энтерпрайз".. 3+ года взад, в свои 60 стал джунгом в ГО, прочитав синтаксис языка, полистав стандартную библиотеку и поглядев и написав пару-тройку примеров для не особо понятых мест.. и на 5-й день освоения - Алга в бэк по полной!
О .. сколько и кто только в команде меня не поправлял по первости, но больше проблем было с ГО-окружением, со всеми этими go mod tidy, vendor, когда нужен dep и когда нет .. документация языка просто отвратительная в этой части, ну да ладно, прошло и это.
.. Прошло время. И тут, попадает мне в руки задача "поправить старый сервис .. глючит, есть какая-то гонка периодически, не стабильно .. портит чеки оплат, но изредка .. третий год уже как .. у нас руки не доходят.." Полез глянуть, а там ... мама мия! Какой нафиг "энтерпрайз", "дядяБоб", "паттерны" .. одна и та же (по сути и содержанию) структура объявлена в трех разных "классах Го" (которых в го нет), периодически преобразуется явно друг в друга .. мьютексы, каналы .. не, не слышали! Впрочем, каналы есть, но совершенно там где не требуется от слова "совсем" ;)
.. полез в гит глянуть "чье Го-внище?" трехлетней давности .. и опаньки - так это же наш тимлид писал. Тот самый, который в прошлом году прочел дядю Боба и теперь ездит всем по ушам за "правильную архитектуру"!
Подошел, спросил .. и внезапно в ответ получил честное признание: "Да, это мой первый сервис на Го, я там наворотил хуже джуна, но переделать было совершенно некогда, а теперь уже и вовсе, не до этого.. Не, переделывать не надо, надо найти косяк и заткнуть .. Ну .. тогда оставь как есть".
Да, это единственный случай в моей практике "60+", но как известно одно опровержение опровергает гипотезу в целом. Не все, и не всегда.
P.S. Косяк, кстати, оказался гонкой, но уже на межсервисном уровне .. "микросервисы" (О, сколько нам открытий чудных, готовит вольный Дух джунов-тимлидов" (перефразируя) ;)
Это порождает вторую проблему. Сеньору придется заниматься просветительской деятельностью практически профессионально. Иначе говоря, нужна специальная методика, знакомство с основами педагогики и психологии, практика выступлений и проведения семинаров. Классическая такая профессура. И это всё дополнительно к прямым обязанностям. Кто за это заплатит тоже не совсем очевидно.
Интересно, а почему у строителей или, например у атомщиков нет такой проблемы? Почему для них существуют университеты-институты, (а значит профессура, доценты, кандидаты наук) после которых они становятся дипломированными специалистами по своей специализации? То есть для строителей, атомщиков работает стандартный, выработанный столетиями подход с высшим образованием, почему же для программистов это не работает?
Может быть, потому что с программированием не связана какая-либо наука? А может, потому что академическое сообщество не может или не хочет признавать-замечать отображения программирования в разные научные области и обратного отображения?
Может существующим (старорежимным) академикам, профессорам не хочется разбираться с программированием и поэтому они предпочитают его игнорировать как явление в мире науки?
Можно по другому сформулировать проблему:
зачем сеньору профессионально заниматься просветительской деятельностью если не существует статуса хотя бы кандидата наук в области этой просветительской деятельности, то есть нет перспектив войти в академическое сообщество ни у синьора ни у его потенциальных студентов?
Далековато, от темы поста, но вкратце выражу мнение (не свое, но часто звучащее), что виновна просто новизна и "скорость" развития отрасли. Когда-то, рано или поздно и тут всё устаканится. Хотя есть и не согласные на этот счет. Та же атомная энергетика не прямо уж таки и старше, а в каком-то смысле и младше. Может она фундаментально оформлена уже и не так динамична. Ученые то есть, но традиция в СССР, а затем и в РФ сложилась такая, что это подраздел математики. Это кстати тоже фактор влияния. Может стоило отнести информатику в инженерные, технические науки. Но, это уже совсем другая история.
У этих косяки смертью кончаются, по этому. У программистов NASA тоже, наверняка все отлично.
Ну, как бы это сказать...
"Программирование" не "наука" (как бы кому не хотелось думать обратное), а "технология".
В отличие от "атомной промышленности" - "программирование" как технология слишком уж "висит в воздухе". Т.е. атомпром - это процентов на 80% теплогидравлика, которая развивается лет эдак 250 и обросла разновсяческими стандартами по самое немогу + куча физических ограничений в плане сопромата, конструкционных материалов и т.д. - и работают с этими ограничениями уже существенно больше лет. Там, где что-то подобное есть в ИТ - оно работает (Скажем, никто не пытается продвигать системы счисления, отличные от двоичной, с размерами байта\слова, основными типами данных тоже больмень договорились уже).
Если с чем-то сравнивать ИТ - то с какой-нибудь авиацией 20х годов прошлого века. А какой винт лучше - тянущий или толкающий? А мотор один ставить или несколько? А как лучше - сверху крыла, или снизу? А сколько крыльев делать - достаточно ли трех или надо делать тетраплан? А цилиндры в двигателе рядно или звездой? А охлаждать воздухом, или? И каждый ээээ... удовлетворяет научное любопытство как он хочет. И несмотря на гораздо большую "приземленность" - разброд и шатание как бы не до 50х тянулись ("Аэродинамику придумали те, кто моторы делать не умеет"(Ц))
"Программирование" не "наука" (как бы кому не хотелось думать обратное), а "технология".
То есть вы считаете что технология не имеет и не должна иметь отношения к науке? Технология это то чем занимаются необразованные неучи, так что ли? Как можно отделять технологию от науки??? Насколько я понимаю технологичность это один из результатов которые обеспечивает наука, и научный подход.
Ваш пример:
Если с чем-то сравнивать ИТ - то с какой-нибудь авиацией 20х годов прошлого века.
мне кажется доказывает как раз обратное тому что вы утверждаете. Пока некоторое техническое направление или их совокупность разрабатываются на уровне ремесла и любительства эти направления не достигают уровня эффективной технологичности. Когда же в разработку этих направлений приходит научный подход, анализ критериев эффективности, решаются вопросы симбиоза и использования исторических научных направлений, связей с ними новых направлений, только тогда невнятные технические направления оформляются как технологии годные для широкого эффективного применения.
Не-не, я тоже за все хорошее и против всего плохого, если что :)
Пример был про то, что даже авиация - уж на что "технологичная" и "привязанная к земле" штука - а и то разброд-и-шатание 30 лет жили - что уж "про IT" говорить. "Академики"(ТМ) к снаряду пару раз подходили - как вам результат? :)
Спасибо за позитив!
А тут, если развивать мысль:
и то разброд-и-шатание 30 лет жили - что уж "про IT" говорить
у кого-то IT началось с 50-х годов прошлого века, а где-то (у нас?) так и остается на уровне "А давайте сделаем лучше чем у них, ... Ой, они уже все опять переделали!Давайте снова делать лучше чем они! Делать лучше-чем-они теперь надо по другому!", то есть срок развития никак не превысит даже 20 лет в каком-то смысле.
Кто такие
"Академики"(ТМ)
я не знаю к сожалению, или к счастью? :)
Насчет атомщиков - яркий пример - Фукусима, где проект не удосужились адаптировать под размещение у цунамиопасного побережья. Насчет строителей - недавняя серия землетрясений в Турции,когда выплыло кто где экономил при строительстве.
Любой код стартует как хороший и правильный. Потом возникает задача "Срочно сделай, чтобы вон та фигня вон ту фигню того". И далее возможны два варианта: либо разработчик убеждает начальство, что эта тривиально звучащая задача действительно требует хорошего рефакторинга всей программы и пары недель времени, потому что совршенно противоречит существующей архитектуре программы; либо код перестаёт быть хорошим и правильным.
Любой код стартует как хороший и правильный.
Сегодня, когда все со старта галопом несутся поскорее выкатить MVP, это утверждение — из мира розовых поней. Сегодня почти любой код стартует не как “хороший и правильный”, а как “вроде бы работающий”. А дальше уже некогда рефакторить, надо фичи клепать. Вот и имеем то, что имеем.
Begin /* Очевидность