Вы молодец, я вам искреннее завидую, если 3 ваших работы приносят больше чем средняя сеньорская зп по России.
Но, понимаете, у старшего разработчика или тимлида обязанности немного другие. Он не работает в формате закрыл задачу, а дальше гори оно всё конём. Он ответственнен за проект, любые вопросы по нему решает он, будь то изменение архитектуры в связи с расширением сервиса или поиск какого-то плавающего критичного бага на проде. И вот в этих случаях разбираться с вашим нейрослопом ну очень сложно. И эйяй тут тоже не помогает, увы. Конфликт, собственно, в этом, нафига ему нанимать на работу человека, который принесет дополнительную работу для него.
На хабре(да и вообще в IT) есть(или был) тренд на алгособесы. И только попробуй напиши, что они не нужны, то тут же тебе в комментариях напихают, что если ты не умеешь реверсить списки когда тебе дышит в затылок интервьвер, то ты вообще не понимаешь как работают индексы базы данных, не знаешь базу, да и вообще лучше на завод, программирование не твое.
И щас я в комментах данной статьи, да и судя по другим статьям, вижу новый тренд с разворотом на 180 градусов, ничего понимать не надо, главное, чтобы эйяй тесты зелёные сгенерил. Я понимаю, что этих трендов придерживаются разные люди(я надеюсь:)), но всё равно забавно.
Так может сначала поднять зарплату выше рынка, а потом если всё равно уходят, то и решать проблему? :) Как минимум сократите уход тех, кто уходит из-за зарплаты.
У вас есть ложное убеждение, что покрытие 100% дает 100% надежность кода. Максимум, что оно может гарантировать, что код не в 100% случаев взрывается(runtime error), всё. Еще раз, не в 100% случаев - означает, что есть как минимум один кейс, когда он не взорвётся, об остальных кейсах ничего неизвестно. Вам бы по хорошему как-то осознать опыт:
Пописать код без тестов
Задолбаться делать фиксы на код без тестов, после того как задачу вам возвращают тестировщики или вылезают баги на проде
Вы начинаете сами вручную тестировать код
Понимаете, что задолбались тестировать каждый раз этот набор кейсов, плюс постоянно что-то забываете, опять приходится делать фиксы
Думаете как бы это автоматизировать - начинаете писать e2e тесты
Утонули во всех этих тестах, логика написания не прослеживается, рефакторинг вызывает миллион правок в тестах.
Изучаете что такое пирамида тестирования, начинаете писать unit-тесты, а также приходит понимание как писать гибкий и масштабируемый код, который легко протестировать.
P.S. Как будто бы по-моему посту можно понять, почему между вайбкодингом и качественным программированием пропасть.
Ну вы не зря написали, что не просто работали, а именно прилагали усилия, старались, чтобы вас заметили, хотели чтобы вас похвалили. А вас не похвалили, может потому что не просили чтобы вы это делали, а может то, что вы сделали им было вообще не нужно. И виноваты скорей всего эти они, да?) Легко же вывод напрашивается: чтобы не выгорать, не нужно прилагать усилия, которые потом не оценят. Ну или прилагать осознанно для себя, а не для кого-то, ожидая благодарности. Поэтому другие люди и не выгорают, а "повезло" универсальный ответ на всё, да еще и обесценивающий.
В системе, которая покрывает работу с ЗП, данная схема, как в задаче, будет играть роль ядра системы, которое связывает ее компоненты. Да, возможно, будет еще API, еще какой-то вывод, не обязательно отчет PDF, но это легко изменить, добавив новые фабрики.
Также вероятность изменений конкретно этого модуля высока за счет добавления новых сотрудников, изменения их мотивации и т.д.
Если бизнес-требований больше не будет — система умрет сама. Так как система оплаты труда часто изменяется, дополняется и расширяется.
Сколько же вы навыдумывали, будет API, высока вероятность изменения мотивации. Система оплаты часто изменяется и расширяется. И кандидат должен угадать, что у вас в голове. И вот хуже всего то, что весь свой выдуманный мир вы берете за истину и пишите под него код. Я кстати на ревью встречал такое ни раз и ни два. И примерно такие же аргументы. Как итог человек пишет этот "фундамент" 3 дня вместо 3х строк, сам в нём тонет, потом еще помощи просит.
Поэтому я считаю, что это не оверинжениринг, а закладка фундамента, который не надо будет переписывать.
Тратите значительно больше времени чем могли, а хуже всего то, что вы очень сильно увеличиваете когнитивную нагрузку своими абстракциями как для себя так и для других. Как итог доработки потом идут значительно дольше. Оверинжениринг в чистом виде. А потом еще и бизнес приходит с real world требованием, которому ваш фундамент по барабану и его приходится переделывать.
Всё-таки вам уже 3 комментария написали про преждевременную оптимизацию и овернижениринг, я напишу четвертым. Советую порефлексировать.
Скорее это скелет, который в будущем будет адаптироваться под бизнес требования
А если бизнес требований больше не будет? А вы вместо 3х строчек кода навертели фабрики, интерфейсы и прочее? Архитектура создается исходя из задачи, более того, она эволюционирует с течением времени в зависимости от требований. Невозможно создать универсальную гибкую и масштабируемую архитектуру, иначе бы она была одна и все бы ей пользовались.
Резюмирую: код всегда пишется под текущие требования самым простым и читабельным способом, если будущие требования неизвестны. Без всяких фабрик и интерфейсов на случай "а вдруг прилетят инопланетяне". В процессе появляниях новых требований архитектура пересматривается, что-то рефакторится, фабрики и интерефейсы добавляются тогда, когда они нужны и приносят пользу, а не на будущее.
Дети как раз справятся, а вот у некоторых взрослых с возрастом мозг действительно "стеклянеет" и начинает нести пассажи из серии "раньше была трава зеленее, да молодежь не та пошла". А молодежь 25-30 летней давности меж тем покупала ГДЗ(готовые домашние задания) и точно также не думала, а тупо списывала. Видимо надо было книги запретить?
Кто хочет учиться - будет ипользовать LLM для развития, кто не хочет - вы ему хоть всё запретите, он тупо домашку не будет делать и в школу не будет ходить.
У меня прямо противоположное мнение: в кино чудовищная монополия актеров, сутяжничество и сходящие с ума по звездам фанаты, готовые отрубить себе руку ради популярного взрослого дядьки, который мажет лицо гримом и кривляется на камеру. Да, Леонардо Ди Каприо крутой профессионал, но платят ему столько денег не за профессионализм, а за узнаваемость, потому что на фильм с Ди Каприо пойдут люди. А за его спиной куча актеров, которым не дали шанса, не хуже по профессионализму, да и фильм не сильно пострадает, если вместо Ди Каприо сыграет крепкий середнячок.
Приход ИИ в кино - это что-то вроде опенсурс в программировании, который удешевит съемки, представьте, что каждой команде не надо снимать взрыв грузовика за миллионы долларов, а можно скопипастить у чужого фильма, чуть модернизировав. Конечно при таком раскладе бенефициары/монополисты будут говорить, что ИИ не нужон, т.к. не будут получать свои миллионы благодаря Royalty.
начать писать сервис на тормознутом go, через пол года разработки, а потом + еще пару месяцев танцев с бубнами вокруг различного рода оптимизаций, в итоге поняв, что таки не можем выжать обещанный SLA, принять волевое решение переписать все на Assembler.
Возможно, тут я доверился автору, но в этой же книге, следующим абзацем он пишет, что был такой же холивар про языки высокого уровня(например, Delphi, Python) и языки низкого уровня. Вот эти споры я застал, так что суть особо не поменялась :)
Нет никакой базовой инженерной гигиены, спросите 10 разработчиков про неё, получите 10 различных определений.
API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн.
Вы следуете каким-то универсальным паттернам, а я говорю, что их нет. Каждый раз код пишется исходя из задачи и если у вас нет обоснования, почему нужно убрать лишних 50 полей, то значит вы зря потратили время на оптимизацию. "Нормальный дизайн" - это не обоснование, это маркер, что вы это делаете по привычке, а объяснить не можете.
Senior-а от Middle-а как раз таки отличает то, что Senior не делит подходы на черное и белое, а знает какой когда применять. В моем практике были кейсы и когда 50 полей хорошо и когда 50 полей зло. Когда нужны были uuid-ы, а когда делал внутренние id-и, чтобы не тратить время и их гораздо проще запомнить. Когда-то удобно было распилить монолит на микросервисы, а когда-то наоборот смержить в монолит.
Время идет, а старики всё также брюзжат на тему раньше было лучше.
И вот был разработан первый компилятор. Эту программу назвали Assembler, что переводится как "сборщик". Писать на нем практически так же сложно, как и в машинных кодах, однако теперь уже использовались не числа, а понятные, как показано на рис. 1.5, человеку слова.Теперь все та же команда копирования регистров выглядела так: mov eax, ebx. Да, код на ассемблере не совсем нагляден, но зато намного удобнее, чем то же самое, но в машинных кодах. Вроде все прекрасно и удобно, но почему-то среди программистов возникли споры и разногласия. Кто-то воспринял новый метод с удовольствием. А кто-то говорил, что машинные коды лучше, что программа, написанная в кодах, работает быстрее. Говорят, что эти споры доходили до драк и иногда лучшие друзья становились врагами.
Категорически не согласен, то, что вы называете путем добра - это преждевременная оптимизация и это путь зла. Сколько я таких мердж реквестов видел... Разработчик напишет, навертит и в итоге вместо 3х строчек кода я вижу 5 классов с кучей методов, я спрашиваю:
- Зачем?
- А вот когда у нас будет нагрузка, да 5 микросервисов, да шардинг бд...
- Ну щас же у нас такого нет, когда будет нагрузка, тогда и перепишем на твой варинт, а щас у тебя 5 классов по 3 метода в каждом вместо 3х строчек кода
- Ну нет, ну всё равно же, ну у меня же выдуманный мною мир рушится...
Оптимизация должна преследовать какую-то цель. Например, приходит бизнес и говорит: мы сделали исследование дизайна и обнаружили, что у нас страница грузится 500мс, часть пользователей не дожидается всей загрузки и уходит со страницы, если сократить загрузку до 5мс, то мы значительно повысим посещаемость. Разработчики: ок, переписываем на rust-е. У вас же цель, чтобы вам было прикольно, потому что вас триггерят слои абстракции и размер приложения - цель, которая нужна только вам и больше никому.
Аналогичная история, сначала годик был на ubuntu, но там как раз сменился gnome на unity, повылезали глюки и я решели попробовать Минт. А там сразу из коробки и java и проприетарные пакеты установились, короче всё работало без дополнительных настроек. Из минусов - постоянно спрашивали: "А чё за Минт, почему не Убунту?"
Можно плыть по течению, можно плыть против течения, а можно плыть туда куда надо. Хотите плыть, туда куда ведет вас Whoop - ваш выбор, для меня это пустой звук. А вот 13% жира - очень круто, я бы такое хотел.
Ну мне в зависимости от количества жира десятку скидывало. Причем разница была в 3кг(20% -> 17%). Приятно когда пишет, но это всё кликбейт. Да и вообще непонятно что это за метрика такая - биологический возраст
Так мотивация была понятна заранее - человек пришел, нелюбопытный, не задает вопросы. Вы сами же говорите - это неправильно, вот тебе инструкция, надо позадавать вопросы, такие задавай, такие не задавай. Сами его призываете "активно применять лабуду".
Вы молодец, я вам искреннее завидую, если 3 ваших работы приносят больше чем средняя сеньорская зп по России.
Но, понимаете, у старшего разработчика или тимлида обязанности немного другие. Он не работает в формате закрыл задачу, а дальше гори оно всё конём. Он ответственнен за проект, любые вопросы по нему решает он, будь то изменение архитектуры в связи с расширением сервиса или поиск какого-то плавающего критичного бага на проде. И вот в этих случаях разбираться с вашим нейрослопом ну очень сложно. И эйяй тут тоже не помогает, увы. Конфликт, собственно, в этом, нафига ему нанимать на работу человека, который принесет дополнительную работу для него.
На хабре(да и вообще в IT) есть(или был) тренд на алгособесы. И только попробуй напиши, что они не нужны, то тут же тебе в комментариях напихают, что если ты не умеешь реверсить списки когда тебе дышит в затылок интервьвер, то ты вообще не понимаешь как работают индексы базы данных, не знаешь базу, да и вообще лучше на завод, программирование не твое.
И щас я в комментах данной статьи, да и судя по другим статьям, вижу новый тренд с разворотом на 180 градусов, ничего понимать не надо, главное, чтобы эйяй тесты зелёные сгенерил. Я понимаю, что этих трендов придерживаются разные люди(я надеюсь:)), но всё равно забавно.
Так может сначала поднять зарплату выше рынка, а потом если всё равно уходят, то и решать проблему? :) Как минимум сократите уход тех, кто уходит из-за зарплаты.
У вас есть ложное убеждение, что покрытие 100% дает 100% надежность кода. Максимум, что оно может гарантировать, что код не в 100% случаев взрывается(runtime error), всё. Еще раз, не в 100% случаев - означает, что есть как минимум один кейс, когда он не взорвётся, об остальных кейсах ничего неизвестно. Вам бы по хорошему как-то осознать опыт:
Пописать код без тестов
Задолбаться делать фиксы на код без тестов, после того как задачу вам возвращают тестировщики или вылезают баги на проде
Вы начинаете сами вручную тестировать код
Понимаете, что задолбались тестировать каждый раз этот набор кейсов, плюс постоянно что-то забываете, опять приходится делать фиксы
Думаете как бы это автоматизировать - начинаете писать e2e тесты
Утонули во всех этих тестах, логика написания не прослеживается, рефакторинг вызывает миллион правок в тестах.
Изучаете что такое пирамида тестирования, начинаете писать unit-тесты, а также приходит понимание как писать гибкий и масштабируемый код, который легко протестировать.
P.S. Как будто бы по-моему посту можно понять, почему между вайбкодингом и качественным программированием пропасть.
Ну вы не зря написали, что не просто работали, а именно прилагали усилия, старались, чтобы вас заметили, хотели чтобы вас похвалили. А вас не похвалили, может потому что не просили чтобы вы это делали, а может то, что вы сделали им было вообще не нужно. И виноваты скорей всего эти они, да?) Легко же вывод напрашивается: чтобы не выгорать, не нужно прилагать усилия, которые потом не оценят. Ну или прилагать осознанно для себя, а не для кого-то, ожидая благодарности. Поэтому другие люди и не выгорают, а "повезло" универсальный ответ на всё, да еще и обесценивающий.
Сколько же вы навыдумывали, будет API, высока вероятность изменения мотивации. Система оплаты часто изменяется и расширяется. И кандидат должен угадать, что у вас в голове. И вот хуже всего то, что весь свой выдуманный мир вы берете за истину и пишите под него код. Я кстати на ревью встречал такое ни раз и ни два. И примерно такие же аргументы. Как итог человек пишет этот "фундамент" 3 дня вместо 3х строк, сам в нём тонет, потом еще помощи просит.
Тратите значительно больше времени чем могли, а хуже всего то, что вы очень сильно увеличиваете когнитивную нагрузку своими абстракциями как для себя так и для других. Как итог доработки потом идут значительно дольше. Оверинжениринг в чистом виде. А потом еще и бизнес приходит с real world требованием, которому ваш фундамент по барабану и его приходится переделывать.
Всё-таки вам уже 3 комментария написали про преждевременную оптимизацию и овернижениринг, я напишу четвертым. Советую порефлексировать.
А если бизнес требований больше не будет? А вы вместо 3х строчек кода навертели фабрики, интерфейсы и прочее? Архитектура создается исходя из задачи, более того, она эволюционирует с течением времени в зависимости от требований. Невозможно создать универсальную гибкую и масштабируемую архитектуру, иначе бы она была одна и все бы ей пользовались.
Резюмирую: код всегда пишется под текущие требования самым простым и читабельным способом, если будущие требования неизвестны. Без всяких фабрик и интерфейсов на случай "а вдруг прилетят инопланетяне". В процессе появляниях новых требований архитектура пересматривается, что-то рефакторится, фабрики и интерефейсы добавляются тогда, когда они нужны и приносят пользу, а не на будущее.
Дети как раз справятся, а вот у некоторых взрослых с возрастом мозг действительно "стеклянеет" и начинает нести пассажи из серии "раньше была трава зеленее, да молодежь не та пошла". А молодежь 25-30 летней давности меж тем покупала ГДЗ(готовые домашние задания) и точно также не думала, а тупо списывала. Видимо надо было книги запретить?
Кто хочет учиться - будет ипользовать LLM для развития, кто не хочет - вы ему хоть всё запретите, он тупо домашку не будет делать и в школу не будет ходить.
Железка стоит миллион рублей, взрыв грузовика миллион долларов...
У меня прямо противоположное мнение: в кино чудовищная монополия актеров, сутяжничество и сходящие с ума по звездам фанаты, готовые отрубить себе руку ради популярного взрослого дядьки, который мажет лицо гримом и кривляется на камеру. Да, Леонардо Ди Каприо крутой профессионал, но платят ему столько денег не за профессионализм, а за узнаваемость, потому что на фильм с Ди Каприо пойдут люди. А за его спиной куча актеров, которым не дали шанса, не хуже по профессионализму, да и фильм не сильно пострадает, если вместо Ди Каприо сыграет крепкий середнячок.
Приход ИИ в кино - это что-то вроде опенсурс в программировании, который удешевит съемки, представьте, что каждой команде не надо снимать взрыв грузовика за миллионы долларов, а можно скопипастить у чужого фильма, чуть модернизировав. Конечно при таком раскладе бенефициары/монополисты будут говорить, что ИИ не нужон, т.к. не будут получать свои миллионы благодаря Royalty.
Я тоже так умею:
Возможно, тут я доверился автору, но в этой же книге, следующим абзацем он пишет, что был такой же холивар про языки высокого уровня(например, Delphi, Python) и языки низкого уровня. Вот эти споры я застал, так что суть особо не поменялась :)
Нет никакой базовой инженерной гигиены, спросите 10 разработчиков про неё, получите 10 различных определений.
Вы следуете каким-то универсальным паттернам, а я говорю, что их нет. Каждый раз код пишется исходя из задачи и если у вас нет обоснования, почему нужно убрать лишних 50 полей, то значит вы зря потратили время на оптимизацию. "Нормальный дизайн" - это не обоснование, это маркер, что вы это делаете по привычке, а объяснить не можете.
Senior-а от Middle-а как раз таки отличает то, что Senior не делит подходы на черное и белое, а знает какой когда применять. В моем практике были кейсы и когда 50 полей хорошо и когда 50 полей зло. Когда нужны были uuid-ы, а когда делал внутренние id-и, чтобы не тратить время и их гораздо проще запомнить. Когда-то удобно было распилить монолит на микросервисы, а когда-то наоборот смержить в монолит.
Время идет, а старики всё также брюзжат на тему раньше было лучше.
Библия Delphi, 2007й год.
Категорически не согласен, то, что вы называете путем добра - это преждевременная оптимизация и это путь зла. Сколько я таких мердж реквестов видел... Разработчик напишет, навертит и в итоге вместо 3х строчек кода я вижу 5 классов с кучей методов, я спрашиваю:
- Зачем?
- А вот когда у нас будет нагрузка, да 5 микросервисов, да шардинг бд...
- Ну щас же у нас такого нет, когда будет нагрузка, тогда и перепишем на твой варинт, а щас у тебя 5 классов по 3 метода в каждом вместо 3х строчек кода
- Ну нет, ну всё равно же, ну у меня же выдуманный мною мир рушится...
Оптимизация должна преследовать какую-то цель. Например, приходит бизнес и говорит: мы сделали исследование дизайна и обнаружили, что у нас страница грузится 500мс, часть пользователей не дожидается всей загрузки и уходит со страницы, если сократить загрузку до 5мс, то мы значительно повысим посещаемость. Разработчики: ок, переписываем на rust-е. У вас же цель, чтобы вам было прикольно, потому что вас триггерят слои абстракции и размер приложения - цель, которая нужна только вам и больше никому.
Жду когда будет статья с заголовком "Бессовестные волки заучивают решения лайвкодинг задач и ломают нам найм"
Аналогичная история, сначала годик был на ubuntu, но там как раз сменился gnome на unity, повылезали глюки и я решели попробовать Минт. А там сразу из коробки и java и проприетарные пакеты установились, короче всё работало без дополнительных настроек. Из минусов - постоянно спрашивали: "А чё за Минт, почему не Убунту?"
Можно плыть по течению, можно плыть против течения, а можно плыть туда куда надо. Хотите плыть, туда куда ведет вас Whoop - ваш выбор, для меня это пустой звук. А вот 13% жира - очень круто, я бы такое хотел.
Ну мне в зависимости от количества жира десятку скидывало. Причем разница была в 3кг(20% -> 17%). Приятно когда пишет, но это всё кликбейт. Да и вообще непонятно что это за метрика такая - биологический возраст
Так мотивация была понятна заранее - человек пришел, нелюбопытный, не задает вопросы. Вы сами же говорите - это неправильно, вот тебе инструкция, надо позадавать вопросы, такие задавай, такие не задавай. Сами его призываете "активно применять лабуду".