Да в смысле? В моём опыте "реальной разработки" бывают задачи близкие к рутинным, не требующих исследований, где все дорожки уже протоптаны, а рядом лежат примеры кода, который делает что-то очень похожее. Причём эти примеры писал тоже я. Только работа всё равно занимает N часов, иногда даже дней.
Возвращаясь к стиралкам - нормальная установка стиралки это реально копипаст, у меня супруга сама установила нашу последнюю - тут крандик подключила, туда канализацию бросила, вилку в розетку - готово! Она у меня дизайнер.
А в статье показано, как аутсорсеры, работая по ТЗ, таки допустили серьёзные архитектурные просчёты, и вот уже опытный разраб на зарплате вместо добавления рядовой фичи буквально допиливает ядро проекта - сверлит стены, пилит мебель, покупает детали какие-то...
Да ладно? В реальной разработке такое сплошь и рядом - сегодня надо добавить ещё один эндпоинт в API, завтра ещё одну формочку (или ещё лучше - поле на формочку), или что-то подобное. Сплошь и рядом такое в "реальной разработке". Только не надо говорить, что это "не разработка, а поддержка". Замена/установка стиралки - это тоже не постройка дома с нуля а поддержка/добавление фичи.
...о нет, я уже лет 10 так делаю. FOREVERDJUN! Ну и если что-то ломается от попутных правок, то тут большой вопрос к качеству изначального кода и к QA. Конечно, если твои попутные правки что-то ломают, это не отменяет твоей персональной ответственности, поэтому всегда надо за собой проверять, и джунов этому надо учить. Ну и проводить/просить ревью обязательно.
Если давать коду зарастать паутиной (а так же копипастой, сомнительной невнятной логикой и артефактами времён стартапа) - дальше будет лишь сложнее это понять, читать и поддерживать, что только увеличит количество багов на проде. Лучше 1 баг в ровном коде сегодня, чем 10 багов (+выгорание), которые обязательно появятся, в запутанном коде через год, по причине его запутанности.
Да в смысле? В моём опыте "реальной разработки" бывают задачи близкие к рутинным, не требующих исследований, где все дорожки уже протоптаны, а рядом лежат примеры кода, который делает что-то очень похожее. Причём эти примеры писал тоже я. Только работа всё равно занимает N часов, иногда даже дней.
Возвращаясь к стиралкам - нормальная установка стиралки это реально копипаст, у меня супруга сама установила нашу последнюю - тут крандик подключила, туда канализацию бросила, вилку в розетку - готово! Она у меня дизайнер.
А в статье показано, как аутсорсеры, работая по ТЗ, таки допустили серьёзные архитектурные просчёты, и вот уже опытный разраб на зарплате вместо добавления рядовой фичи буквально допиливает ядро проекта - сверлит стены, пилит мебель, покупает детали какие-то...
Да ладно? В реальной разработке такое сплошь и рядом - сегодня надо добавить ещё один эндпоинт в API, завтра ещё одну формочку (или ещё лучше - поле на формочку), или что-то подобное. Сплошь и рядом такое в "реальной разработке".
Только не надо говорить, что это "не разработка, а поддержка". Замена/установка стиралки - это тоже не постройка дома с нуля а поддержка/добавление фичи.
Вероятно, чтобы использовать их по прямому назначению - гаматься в WoW.
...о нет, я уже лет 10 так делаю. FOREVERDJUN!
Ну и если что-то ломается от попутных правок, то тут большой вопрос к качеству изначального кода и к QA. Конечно, если твои попутные правки что-то ломают, это не отменяет твоей персональной ответственности, поэтому всегда надо за собой проверять, и джунов этому надо учить. Ну и проводить/просить ревью обязательно.
Если давать коду зарастать паутиной (а так же копипастой, сомнительной невнятной логикой и артефактами времён стартапа) - дальше будет лишь сложнее это понять, читать и поддерживать, что только увеличит количество багов на проде.
Лучше 1 баг в ровном коде сегодня, чем 10 багов (+выгорание), которые обязательно появятся, в запутанном коде через год, по причине его запутанности.
Картинкой для привлечения внимания и подсветкой синтаксиса в первых четырёх блоках :)
Вот этот шедевр 10-летней выдержки не хуже трейлера.
https://www.youtube.com/watch?v=iKQSv8p9BXU