Чем проще и очевиднее исходный код, тем автор более продвинут. Казалось бы, об этом твердят уже на протяжении полувека светлейшие головы индустрии, но складывается такое ощущение, что далеко не все согласны с этим утверждением. Появились разнообразные инструменты и методики программирования, которые буквально силком заставляют очередного джуна следовать заветам аксакалов, но джун как будто сопротивляется изо всех сил, пытаясь как можно дальше уйти от предлагаемых идей.
Я могу тут судить только по себе, возвращаясь к собственному становлению и личным ощущениям. В те далекие времена, когда джуном бы я, мало кто слышал про паттерны и рефакторинг, но красивый и понятный код был всегда. Были книжки с листингами программ, были исходные коды открытых библиотек и фреймворков. Я тогда недоумевал, почему реальный код, даже написанный, в серьезных, по тогдашним меркам, отечественных организаций, настолько сильно отличается от образцового. Наверное, предполагал я, что напоказ люди пишут один код, а в свободное от написания умных книжек время садятся за компьютер и делают что-то очень непонятное, но как-то значительно лучше работающее.
Когда же код, написанный личной мной, начал попадать в бой и к коллегам, то стало понятно, что код то в основном пишут как раз не те люди, которые публикуют книги и статьи, а вот такие же джуны. Средний кодер любого, сколь угодного крупного и серьезного проекта по определению джун. Их просто больше. Да, где-то мельком встречаются кусочки написанные более опытными товарищами, но их откровенно мало и они то чаще всего и представляют из себя скорее какие-нибудь библиотечки и фреймворки - не бизнес логика, не конкретные реализации и не все эти кошмарные базы данных.
То есть, мне кажется, новички становятся заложниками некой психологической ловушки. Джун, глядя на чужой код, воспринимает его как правильный по определению, просто потому что он кем-то когда-то допущен к эксплуатации и работает. При этом не осознавая, что тот дядька - автор кода - в кожаном кресле с проседью, который сейчас неизмеримо круче, делал это ровно в его возрасте и с таким же количеством извилин в голове.
Да, сейчас это мудрый мужчина, который указывает всем на ошибки, раздает советы, но, как правило уже активно не принимает участие в разработке. И только сейчас он понимает, что джуны глядя на его код думают, что вот он - идеал, но переписывать свое говно десятилетней давности уже нет ни времени ни желания. Да и пояснять, молодежи, что основательно именно он нагадил в свое время в продукт тоже не торопится.
Как выйти из такого порочного круга не очень очевидно. Можно сделать над собой усилие и привести всё в порядок лично, потратив столько же, а может больше времени. Однако, непонятно кто за это будет платить, и не окажется ли так, что сам сеньор слишком много о себе думает, и еще через десять лет окажется, что и эту работу придется переделывать. Я даже уверен, что так оно часто и оказывается.
Второй путь - непрерывная передача текущих знаний через поколение. Такой путь более предпочтителен и, в общем-то, является единственным действенным последние сотни две тысячи лет. Другими словами, дабы повысить качество кода радикально, самый-самый сеньор должен воспитывать с молочных зубов самых-самых джунов. Не мидлы джунов, не сеньоры мидлов, а вот именно самый опытный - самого несмышленого. Как бабушки внуков, как академики первокурсников.
Только таким образом, у джуна сложится в голове правильный образ мышления, лаконичного и логичного письма. Цель - ликвидировать тот момент, когда джун сперва привыкает делать как попало, потом на собственном опыте пытается переформатировать собственную модель мира.
С другой стороны, есть и с этим определенная проблема. Ну, во-первых, встает вопрос повышения порога вхождения. Всё-таки очень сложные концепции лучше вносить постепенно. Нельзя сразу объяснить первокурснику, что школьная алгебра это только одна из многих придуманных позднее, что геометрий тоже несколько. А значит, нужно подходить к этому как-то системно и методично, а не путем составления ревью с замечанием к каждой строке кода. При неверном подходе можно наоборот сделать только хуже, отправляя джуна каждый раз в нокаут. Так можно и Паркинсона заработать.
Это порождает вторую проблему. Сеньору придется заниматься просветительской деятельностью практически профессионально. Иначе говоря, нужна специальная методика, знакомство с основами педагогики и психологии, практика выступлений и проведения семинаров. Классическая такая профессура. И это всё дополнительно к прямым обязанностям. Кто за это заплатит тоже не совсем очевидно. Должны ли входить такие вещи в должностные инструкции или это отдельно оплачиваемая деятельность.
Какие-то организации наверняка интуитивно пришли к похожим выводам. Но, нужна массовость, проработанность. А самим джунам надо повсеместно внедрить мысль о том, что в нормальной организации обязательно должна быть программа по дополнительной квалификации - эдакая внутренняя магистратура, где новички ходят на лекции, выполняют домашние задания и получают за них оценки.
А главное, джуну должно быть очевидно, как в ясный день, что легаси код который он видит и в котором не может разобраться сразу, отнюдь не совершенство и даже ничего отдаленно похожее на норму. Код должен быть понятен и ему тоже, логика должна быть однозначна. А чем сложнее и запутаннее код, тем моложе и неопытнее был его предшественник. Должно быть очевидно и то, что настоящим достижением на рабочем месте является не умение повторять за предшественниками, а делать лучше. Тем более, что при нынешнем состоянии существующего софта, это сделать не так уж и сложно.
*/
End.
Комментарии (33)
zloddey
10.09.2023 03:48+2В принципе, возможен и такой вариант: регулярно исправлять и приводить к общему стилю всю кодовую базу продукта, чтобы он выглядел более-менее порядочно en masse. Тогда новичок будет ориентироваться уже не на мутное месиво, а на что-то типа командных best practices.
Документация, опять же ж, автоматические утилиты (метрики/линтинги/форматирование/etc) - здорово помогают, если применяются не для галочки, а осознанно.
Rembo123 Автор
10.09.2023 03:48+1Единственная проблема, как такую идею внедрить акционеру?
zloddey
10.09.2023 03:48+3Разве это зона ответственности акционера? Или зона ответственности команды?
По моему опыту, лучше всего такие чистки идут, когда они находятся "ниже радара" для бизнеса. Т.е., с одной стороны, команда проводит эту деятельность и улучшает жизнь себе, а с другой стороны, эта активность не идёт во вред бизнес-задачам. Проблемы возникают при перекосах в ту или иную сторону. Либо когда команда увлекается полировкой в ущерб задачам бизнеса, либо когда на неё забивают полностью.
Rembo123 Автор
10.09.2023 03:48Да, на каком-то практическом уровне, безусловно это ответственность ближайшего командира, но, конечно же, акционер должен понимать, что выхлоп от того сотрудники занимаются "кроме работы" еще и уборкой в собственной казарме, в долгосрочной перспективе это прямой доход от экономии на сопровождении. Иначе все-равно руководитель, даже понимая все вышесказанное, подспудно будет расставлять приоритеты "по срочности".
zloddey
10.09.2023 03:48+1Согласен, такое случается. Универсального совета у меня для такого случая нет. Сам дважды с подобным сталкивался. Сначала пытался договариваться, но потом в итоге уходил. "Е%%тесь сами, удачи!".
На текущем месте работы сформулировал для себя ряд правил, позволяющие контролировать и ограничивать стремления к чисткам. Работает неплохо, кажется. Может, статью на эту тему оформлю.
Hasthur
10.09.2023 03:48+3Мне удалось объяснить владельцу проекта необходимость рефакторига оставленного мне спагетти. Если акцентировать не на аргументах, важных для разработчика (SOLID, читаемость/чистота и т.п.), а на следствиях, важных ему (увеличение стабильности, скорости доставки нового и багфиксов, уменьшение выгорания и т.п.) - всё это будет услышано. Разумеется, при этом owner должен быть адекватным (хотя бы на уровне подсчёта собственной прибыли). Добиться выделенного времени не удалось, но согласовали, что решение текущих задач будет занимать чуть больше времени. В итоге, решая ту или иную задачу, получается привести в порядок тот кусок кода, к которому она имеет отношение. Так постепенно преобразуется весь проект (к слову, довольно большой)
Было бы очень интересно и полезно услышать ваши правила в том или ином виде. Иногда всётаки сложно себя остановить )
ihouser
10.09.2023 03:48Чтобы что то объяснить бизнесу, нужны измеримые метрики. А такие "я думаю", "я уверен" в формулу для подсчета прибыли не подставишь.
Hasthur
10.09.2023 03:48А почему вы решили, что разговор был на уровне "я думаю"/"я уверен"? Были озвучены сценарии развития событий с вероятными последствиями. А "с другой стороны" - хватило ума пересчитать это в свои "метрики". Вероятности и их последствия могут считать не только программисты-математики.
ihouser
10.09.2023 03:48Потому, что я не видел разработчика, способного последствия рефакторинга рассчитать на уровне выше "я думаю". Есть интуитивное понимание пользы, не более.
Возможно, прожженные сеньоры могут, но большинство нет.
Что делать бизнесу? Набираться опыту? Пока наберешься, сформируется прослойка эффективных манагеров, которая будет всех гнать "быстрее".
Hasthur
10.09.2023 03:48+1Если вы таких не видели - не значит, что их нет. Чтобы так представлять процессы/последствия, тут как минимум нужен опыт, конечно. От условного джуна ожидать такого - опрометчиво
VladimirFarshatov
10.09.2023 03:48+2Да, тоже напомнили: коллеге-тезке: "Вова, ты чего там закомиттил 356 файлов?"
-"Директор в тай укатил, можно 2 недели спокойно отрефакториться. Я бы тебе посоветовал сделать тоже самое. Раньше чем через неделю, он про нас все равно не вспомнит".. :)
AnimeSlave
10.09.2023 03:48+1Либо когда команда увлекается полировкой в ущерб задачам бизнеса, либо когда на неё забивают полностью.
Тут есть момент, что иногда из-за возможного ущерба для бизнеса нет возможности заниматься полировкой кода. И за кода код превращается в месиво. И тут уже не обойтись без участия высшего менеджмента, который примет риски от увеличения сроков поставки продуктов на рынок из-за необходимости полировать код
JuryPol
10.09.2023 03:48+4Увы, эта проблема не единственная. Между, так сказать, "производителями кода" и акционером есть, как правило, толстый слой ушлых ребяток, активно размножающихся чуть-ли не почкованием.
И ваша инициатива для этих деятелей, это прямая угроза их личным кипиаям, метрикам и прочей требухе, с которой кормятся стада "понаехавших в Айти" бездельников. Им на красоту кода вообще наплевать.
nikolz
10.09.2023 03:48-2"Были книжки с листингами программ, были исходные коды открытых библиотек и фреймворков. "
------------------------------
А еще раньше,была и есть технология структурного программирования.
Как известно, "технология" — это совокупность методов и инструментов для достижения желаемого результата в заданное время и с заданным качеством.
--------------------------
Полагаю, что многие из современных программистов даже не слышали об этой технологии.
---------------------
Попробуйте применить ее и удивитесь достигнутым результатам.
Код будет не только красивым , но и понятным любому джуну.
А главное, разработку софта легко распараллеливать и отлаживать.
Проблема лишь в том, что как всякую технологию, структурное программирование сложно освоить тем, кто уже пишет от всей души, но без технологий.
VladimirFarshatov
10.09.2023 03:48Проблема лишь в том, что как всякую технологию, структурное
программирование сложно освоить тем, кто уже пишет от всей души, но без
технологий.И снова оспорю, ибо то же знаю и далеко не один случай из своей практики, когда чел, накатавший тонны легаси, прочитав Дейкстру, структурное, модульное программирование начинал писать вполне вменяемый, расширяемый и поддерживаемый код. Парочка случаев, так и "сразу" после прочтения. По-разному..
VladimirFarshatov
10.09.2023 03:48+3Не могу согласиться с пассажем о старшем, которому трудно признаться что именно он тут "наворотил", требуя от джунов "правильного энтерпрайз".. 3+ года взад, в свои 60 стал джунгом в ГО, прочитав синтаксис языка, полистав стандартную библиотеку и поглядев и написав пару-тройку примеров для не особо понятых мест.. и на 5-й день освоения - Алга в бэк по полной!
О .. сколько и кто только в команде меня не поправлял по первости, но больше проблем было с ГО-окружением, со всеми этими go mod tidy, vendor, когда нужен dep и когда нет .. документация языка просто отвратительная в этой части, ну да ладно, прошло и это.
.. Прошло время. И тут, попадает мне в руки задача "поправить старый сервис .. глючит, есть какая-то гонка периодически, не стабильно .. портит чеки оплат, но изредка .. третий год уже как .. у нас руки не доходят.." Полез глянуть, а там ... мама мия! Какой нафиг "энтерпрайз", "дядяБоб", "паттерны" .. одна и та же (по сути и содержанию) структура объявлена в трех разных "классах Го" (которых в го нет), периодически преобразуется явно друг в друга .. мьютексы, каналы .. не, не слышали! Впрочем, каналы есть, но совершенно там где не требуется от слова "совсем" ;)
.. полез в гит глянуть "чье Го-внище?" трехлетней давности .. и опаньки - так это же наш тимлид писал. Тот самый, который в прошлом году прочел дядю Боба и теперь ездит всем по ушам за "правильную архитектуру"!
Подошел, спросил .. и внезапно в ответ получил честное признание: "Да, это мой первый сервис на Го, я там наворотил хуже джуна, но переделать было совершенно некогда, а теперь уже и вовсе, не до этого.. Не, переделывать не надо, надо найти косяк и заткнуть .. Ну .. тогда оставь как есть".
Да, это единственный случай в моей практике "60+", но как известно одно опровержение опровергает гипотезу в целом. Не все, и не всегда.
P.S. Косяк, кстати, оказался гонкой, но уже на межсервисном уровне .. "микросервисы" (О, сколько нам открытий чудных, готовит вольный Дух джунов-тимлидов" (перефразируя) ;)
rukhi7
10.09.2023 03:48Это порождает вторую проблему. Сеньору придется заниматься просветительской деятельностью практически профессионально. Иначе говоря, нужна специальная методика, знакомство с основами педагогики и психологии, практика выступлений и проведения семинаров. Классическая такая профессура. И это всё дополнительно к прямым обязанностям. Кто за это заплатит тоже не совсем очевидно.
Интересно, а почему у строителей или, например у атомщиков нет такой проблемы? Почему для них существуют университеты-институты, (а значит профессура, доценты, кандидаты наук) после которых они становятся дипломированными специалистами по своей специализации? То есть для строителей, атомщиков работает стандартный, выработанный столетиями подход с высшим образованием, почему же для программистов это не работает?
Может быть, потому что с программированием не связана какая-либо наука? А может, потому что академическое сообщество не может или не хочет признавать-замечать отображения программирования в разные научные области и обратного отображения?
Может существующим (старорежимным) академикам, профессорам не хочется разбираться с программированием и поэтому они предпочитают его игнорировать как явление в мире науки?
Можно по другому сформулировать проблему:
зачем сеньору профессионально заниматься просветительской деятельностью если не существует статуса хотя бы кандидата наук в области этой просветительской деятельности, то есть нет перспектив войти в академическое сообщество ни у синьора ни у его потенциальных студентов?
Rembo123 Автор
10.09.2023 03:48Далековато, от темы поста, но вкратце выражу мнение (не свое, но часто звучащее), что виновна просто новизна и "скорость" развития отрасли. Когда-то, рано или поздно и тут всё устаканится. Хотя есть и не согласные на этот счет. Та же атомная энергетика не прямо уж таки и старше, а в каком-то смысле и младше. Может она фундаментально оформлена уже и не так динамична. Ученые то есть, но традиция в СССР, а затем и в РФ сложилась такая, что это подраздел математики. Это кстати тоже фактор влияния. Может стоило отнести информатику в инженерные, технические науки. Но, это уже совсем другая история.
ihouser
10.09.2023 03:48У этих косяки смертью кончаются, по этому. У программистов NASA тоже, наверняка все отлично.
atshaman
10.09.2023 03:48У "программистов NASA" объем кодовой базы по коммерческим меркам - смешной. Предполагаю, что между версиями android больше кода нафигачено, чем за все время с лунной программы набралось.
atshaman
10.09.2023 03:48Ну, как бы это сказать...
"Программирование" не "наука" (как бы кому не хотелось думать обратное), а "технология".
В отличие от "атомной промышленности" - "программирование" как технология слишком уж "висит в воздухе". Т.е. атомпром - это процентов на 80% теплогидравлика, которая развивается лет эдак 250 и обросла разновсяческими стандартами по самое немогу + куча физических ограничений в плане сопромата, конструкционных материалов и т.д. - и работают с этими ограничениями уже существенно больше лет. Там, где что-то подобное есть в ИТ - оно работает (Скажем, никто не пытается продвигать системы счисления, отличные от двоичной, с размерами байта\слова, основными типами данных тоже больмень договорились уже).
Если с чем-то сравнивать ИТ - то с какой-нибудь авиацией 20х годов прошлого века. А какой винт лучше - тянущий или толкающий? А мотор один ставить или несколько? А как лучше - сверху крыла, или снизу? А сколько крыльев делать - достаточно ли трех или надо делать тетраплан? А цилиндры в двигателе рядно или звездой? А охлаждать воздухом, или? И каждый ээээ... удовлетворяет научное любопытство как он хочет. И несмотря на гораздо большую "приземленность" - разброд и шатание как бы не до 50х тянулись ("Аэродинамику придумали те, кто моторы делать не умеет"(Ц))
rukhi7
10.09.2023 03:48"Программирование" не "наука" (как бы кому не хотелось думать обратное), а "технология".
То есть вы считаете что технология не имеет и не должна иметь отношения к науке? Технология это то чем занимаются необразованные неучи, так что ли? Как можно отделять технологию от науки??? Насколько я понимаю технологичность это один из результатов которые обеспечивает наука, и научный подход.
Ваш пример:
Если с чем-то сравнивать ИТ - то с какой-нибудь авиацией 20х годов прошлого века.
мне кажется доказывает как раз обратное тому что вы утверждаете. Пока некоторое техническое направление или их совокупность разрабатываются на уровне ремесла и любительства эти направления не достигают уровня эффективной технологичности. Когда же в разработку этих направлений приходит научный подход, анализ критериев эффективности, решаются вопросы симбиоза и использования исторических научных направлений, связей с ними новых направлений, только тогда невнятные технические направления оформляются как технологии годные для широкого эффективного применения.
zaiats_2k
10.09.2023 03:48Насчет атомщиков - яркий пример - Фукусима, где проект не удосужились адаптировать под размещение у цунамиопасного побережья. Насчет строителей - недавняя серия землетрясений в Турции,когда выплыло кто где экономил при строительстве.
MountainGoat
10.09.2023 03:48+5Любой код стартует как хороший и правильный. Потом возникает задача "Срочно сделай, чтобы вон та фигня вон ту фигню того". И далее возможны два варианта: либо разработчик убеждает начальство, что эта тривиально звучащая задача действительно требует хорошего рефакторинга всей программы и пары недель времени, потому что совршенно противоречит существующей архитектуре программы; либо код перестаёт быть хорошим и правильным.
JSmitty
10.09.2023 03:48+1Не последнюю роль играет и старая недобрая традиция "сейчас мы сделаем чертеж на небольшую конуру и построим ее", а в середине стройки приходит ПМ с горящим з.... и заявляет, что "нам нужно срочно небоскреб под сотку этажей, но времени проектировать нет, давай надстроим конуру, это же тоже строение".
AnimeSlave
То, что вы описываете в статье на самом деле хорошие мысли для рассуждения, потому что в России есть проблема высшего образования. Но некоторые тезисы скорее вредны. К примеру:
Такая «мысль» будет всем джунам давать надежду, что они могут не усердствовать, их всё равно потом научат, «возьмут за ручку, и приведут в подготовительную группу детсада». И потому уровень знаний джунов может серьезно снизиться.
То, о чём вы пишите по поводу сеньоров фактически менторство, и оно уже применяется в некоторых компаниях, так как это хорошая практика, которая показала свою эффективность. Но здесь есть тоже проблемы, так как ментор - это не нянька, ментор подсказывает, направляет на поиск правильного решения, а не пытается за условного джуна сделать работу. И здесь же бывают проблемы, когда иногда проще и быстрее сделать задачу за джуна, особенно если задача «горит» по срокам, чем пытаться «направлять» джуна на ответ.
Ну и «балалайка» от меня про проблемы написания «хорошего» кода. На текущем месте работы есть коллеги, которые стоят выше меня по уровню (грейду), и они на хорошем счету у руководителей, тимлиды их котируют и к ним прислушиваются, когда происходит обсуждение каких-то вопросов. Но когда я лично смотрю на код ими написанный, я нередко внутренне возмущаюсь тому, что именно этот человек написал такой код. С точки зрения синтаксиса и идиоматики языка программирования код может быть хорошим, но с точки зрения архитектуры всей кодовой базы, написанный код бывает, как выброшенный мусор в окно во время поездки. То есть появляются вопросы «зачем он именно в той части кодовой базы», «почему не отдельным классом, или не отдельным файлом». И эти же люди потом на совещаниях говорят о проблеме чтения кодовой базы, при том, что для решения свой задачи не задавались этим же вопросом. И понятно почему, так как здесь и сейчас они знают свой код, как он был написан и для чего. А что будет потом их уже не волнует. Так как это будет потом. Решать проблему они будут по мере их поступления
Rembo123 Автор
Вот примерно в таком ключе действуют и все конторы, с которыми приходилось сталкиваться мне. Когда джуну намеренно дается "подтянуть" навыки самостоятельно на основании существующей кодовой базы. И шансы того, что он заподозрит в этом коде неладное, и начнет его сразу "улучшать" стремятся к нулю. Он скорее крепко уверует, что так и надо, пока не сам не столкнется с последствиями. По-моему слишком часто можно услышать "ментора" фразы типа: "А ты там посмотри как сделано и сделай примерно так же".
А по поводу "менторства" мое замечание такое, что не всегда (далеко), оно представляет из себя то, что имели ввиду кто этот институт придумывал и внедрял. В идеале, мне кажется, оно как раз должно вырождаться в 6 и 7-й курс университета. Это как с интернами в медицине.
AnimeSlave
Вы не совсем поняли мой посыл. Условный джун перестанет учиться сам, если его будут учить на каждом новом рабочем месте. Как раз джун должен учиться самостоятельно, но для того, чтобы он учился правильно у него должен быть ментор, который его направит. Проверит его «домашку». Проверка «домашки» должно как раз показать правильно ли джун понимает суть задачи или нет. Правильно ли он принял решение и т.д. И после разбора дать ему совет что почитать, куда заглянуть за примером правильного решения. А «учить» разрушительная практика
Rembo123 Автор
Нет, я понял ваш посыл. Боязнь подавать всё на блюдечке в каком-то смысле оправдана - до каких-то вещей лучше именно дойти. С другой стороны, в таком случае, может стоит подготовить ментора элементам педагогики, чем заведомо подозревать обучаемого в лени. В общем, да, это дилемма.
Hardcoin
Если бы ментор на регуляторной основе мог бы посоветовать что-то лучше, то код изначально был бы написан лучше
TrykinSchultz
/но с точки зрения архитектуры всей кодовой базы, написанный код бывает, как выброшенный мусор в окно во время поездки.
По тому, что это классно когда тебе дали время на подумать и архитектуру, и дали это воплотить.
Но бывает и так: «а давайте попробуем!», а потом этот «попробуем» по желанию начальства улетает в прод и на твои возражения, что задача изначально была другой, внимания не обращают, что ПМ приходить со сроком и описанием того, что надо сделать "на пальцах", начинать писать надо сейчас, а требования уточняется уже потом, или под конец выясняется, что надо туда вкрутить что-то, что ломает все твою стройную архитектуру, или подвели соседи/подрядчики и тебя надо сделать то, что изначально планировалось на другой стороне...
Да мало ли...
AnimeSlave
В моём случае ничего не стоило добавить «брошенный» код в отдельный файл хотя бы. Это не систему сборки с нуля перенастроить. Достаточно было один файл создать, одну строчку в скрипт сборки добавить. А то как бывало по моей работе - это выглядело просто как наплевательское отношение, как к своей работе, так и к коллегам, которые после автора кода будут с этим кодом работать.
Очень легко перекладывать ответственность на других. И вы в вашем примере перекладываете на ПМов или начальство. Хорошей практикой является сразу делать «хорошо» даже если это просто набросок идеи. Не отрицаю, что иногда это занимает больше времени, чем просто наговнокодить. Но это снижает риски попадание говнокода в прод по разным причинам, даже самым идиотским
TrykinSchultz
Или не было. Осуждать кого-то можно только зная все обстоятельства принятия такого решения.
Немного видоизменю ваше утверждение: мы живем не в идеальном мире, и хорошей практикой является писать настолько хороший код, насколько это возможно в данных обстоятельствах. Код и был хорош для той задачи которую он решал. Но код не является конечной точкой, по крайне мере моей работы. Для "хорошо" нужна как можно более полная информация, время и ресурсы. ПМ и начальство то же не из прихоти такие решения принимает. Если фича нужна к 28 числу, а если к 29 то можно и не делать, в рефакторинг не успеваем, значит делаем как успеваем. Хорошей практикой является писать тесты - аксиома, но не успеваем - практика, значит не пишем, запишем в долг. Если на долг не дали время, так в долгу и останется.
bisnes online