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

Внести собственные улучшения в проекта заказчика? — Нет

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Привет! Ищу совет знающих и опытных людей:)

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

В результате получил предупреждение, что вносить изменения в scope не планируется. Улучшу продукт и это как бы с одной стороны — правильно, но как бы это и не то что нужно заказчику. Мне сказали, что делать фичу и потом внезапно приходить говорить — давайте добавим ее ведь я сделал, не лучшая идея.

Я не до конца понимаю почему. Тут же win-win, что не так?

Спасибо!

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

Найкращі коментарі пропустити

Меня это то же удивляло по-молодости. На первом проекте опытный синьор учил меня как правильно делать новые фичи: берем файлы исходников, КОПИРУЕМ ЦЕЛИКОМ, переименовываем классы методы и тогда меняем. Т.е. если у нас был класс PriceCalculator1 то копируем и делаем класс PriceCalculator2 и потом в нужном месте ставим ветвление какой класс вызывать.
Я тут же начал возражать что дублирование кода — это плохо, надо рефакторить, наследовать, декомпозировать и т.д.
На это он привел железные аргументы:
1) Ты уверен что точно знаешь как работает класс PriceCalculator на 10 000 строк? Нет? Так никто из команды уже не знает!
2) Класс PriceCalculator покрыт юнит тестами или любыми другими тестами, которые проверят что после изменений ничего не сломалось? Нет!
3) У тебя есть документация, которая описывает текущий алгоритм расчета цен, новый алгоритм и правила когда что применять? Нет!
4) Если ты поменяешь хотя бы одну строку в существующем классе PriceCalculator1 — как ты убедишься, что из 100500 клиентов, которые используют разные комбинации скидок и т.д. ни у одного не поменяется цена товаров? А какой скандал будет если все-таки поменяется ты понимаешь?
Ты хочешь сделать что-то новое? Делай так что бы оно 100% не повлияло на старое. Потому что в большом проекте невозможно проверить где и что отвалиться.
Любой рефакторинг, улучшение производительности, переход на новые версии, даже исправление явной ошибки в коде или прочие идеи, которые могут предложить девелоперы, для клиента означает потенциальные проблемы с валом звонков от недовольных юзеров у которых что-то начало работать не так, как раньше!
Предположим девелопер очень хорошо разобрался в бизнесе клиента и предлагает какую-то не чисто техническую фичу. Которая, к тому же, не повлияет на существующий функционал. Ну, например, прикрутить на сайт чат-бота. Даже если девелопер сделает это абсолютно бесплатно — это все равно новый функционал, который нужно: релизить, тестировать, мониторить, чинить, интегрироваться и т.д. Т.е расходы все равно будут. А вот будет ли от этого какая-то прибыл — неизвестно. Если юзеры не просили эту фичу, если бизнес аналитики ее не предлагали — то какая вероятность что это вообще кому-то нужно?
Посмотрите сколько возможностей в больших продуктах (например MS Word) и про сколько из них не знает и никогда не использует 99% пользователей! От «мертвых» фич такой же вред, как от мертвого кода.
Поэтому девелоперам и не дают ничего улучшать в проекте по своей воле. Если есть желание покреативить — то лучше сделать отдельный прототип и показать его клиенту. Возможно ему понравиться и тогда уже он, оценив все плюсы и минусы, выделит оплачиваемое время на разработку, тестирование, интеграцию, поддержку и обучение юзеров этой новой фиче. И если прототип девелоперы напишут за пару выходных, то внедрение этой фичи в продукт — это уже вопрос немалых денег!
P.S. Это извечная проблема: работаешь на дядю — делаешь что прикажут. Хочешь творчества — пили бесплатно опенсорс или стартап (скорее всего получится то же бесплатно).

Привносить свои улучшения в проект клиента/заказчика можно и нужно! Но есть большое НО. Это нужно делать корректно и в этом процессе есть огромное количество нюансов.
1) Если ты часть аутсорс команды, то в первую очередь такое улучшение нужно согласовать со своим ПМ/ДМ. Возможно твоя идея очень крутая и ее можно продать как upsell клиенту. Клиент будет рад, что команда проявляет инциативу, клиенту будет польза о внедрении нужной фичи, менеджмент аутсорс компании получит профит от дополнительной прибыли от upsell, менеджмент аутсорс компании будет рад повышению репутации в глазах клиента.
Но этот путь тернист, не прост и длителен по времени.
После того, как ты предложишь, а затем продашь свою идею ПМ/ДМ, эта идея будет взвешена и оценена менджментом с вовлечением дополнительных ресурсов (аналитиков, архитекторов, продактов и тд). После этого идея будет в корректном виде озвучена клиенту. После этого, если клиент даст добро — будет определена команда, которая займется дополнительным анализом реализации этой фичи, оценкой ее имплементации и внедрения. И только после последующих согласований — эта фича будет передана в разработку. При этом она может быть передана в разработку не тебе, а другой команде, которая будет на взгляд клиента или менеджмента наиболее целесообразной для реализации данной фичи.
2) Если ты часть продуктовой компании — задача немного упрощается, но все равно есть целый ряд упражнений, через которые нужно пройти прежде, чем что-то оптимизировать.
Для начала нужно обсудить свое предложение со своим Product owner или если такого нет — со своим лидом или ПМ.
После того, как ты предложишь, а затем продашь свою идею, ее анализом займется либо PO, либо ответственный аналитик, после оценки этой фичи, если она будет актуальна — ее оценят с точки зрения business value и соответствия целям компании. После этого фича будет приоритезирована и запланирована в работу наиболее подходящей команде для имплеметации и опять это ее непосредственной имплементацией вероятно будешь заниматься не ты.

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

— Вы уверены что это реально улучшиния ?
— Если да, то какие риски они переркывают ? Актуальны ли риски для заказчика ? Не создадут ли ваши улучшиения еще бОльшие риски ?

про Эффект Даннинга — Крюгера уже писали в комментариях?

upd: по CTRL+F не нашел, ну буду первым тогда :)

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

Если хочца драйву — то надо валить в продукты.

Стартапи

Стартап — это как раз то, место, где можно непостредственно принимать участие в создании легаси!

Как известно хороший код отличаеться от плохого только фактом написания собой недавно.

А легаси от нелегаси — наличием тестов 🙂

Согласен, маленького пука достаточно :)

Хороший код какает в лоток, плохой — по углам

Культура труда в Тойота в 2000х была байка что: если за два года работы на одном месте работник не вносит на рассмотрение специального отдела новшество оптимизируещее его непостедственный труд. Его увольняют с *волчьим билетом* — как не лояльного, или не обладающего должной квалификацией.
Это не та песня конечно, но мотив явно похожий.

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

Теорию эволюции пока никто не опроверг.
Проблема в том что влияет.
Просто *мальчики берущие под козырек* © хабр, пока оттягивают час ч.

Проблема в том что влияет

это решает заказчик а не гребец со стороны.

Теорию эволюции пока никто не опроверг.

What’s the largest amount of bad code you have ever seen work?
news.ycombinator.com/item?id=18442637
answer: Oracle Database 12.2.

рус itpravda.com/...​/oracle-25-million-lines

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

Всё просто — «Инициатива наказуема» и не будет никем оценена.

Поддержу других комментаторов: стоимость фичи для бизнеса — это не только ее разработка. Поэтому если витдите, что можно улучшить, то лучше предложить и обосновать чем же она хороша (вот тут бывает что нужно какое-то MVP набросать, но MVP, а не то что можно будет в master залить). А там уже как решит продукт овнер. Может даже оказаться что с точки зрения бизнеса это не улучшение, а наоборот — размывает фокус продукта и им сложнее пользоваться.
А вот в рамках фичи обычно (если это не махровый аутсорс) предложения приветствуются. Не технические чуваки часто не понимают всех импактов и трудозатрат. Поэтому докопаться для чего они хотят эту фичу и предложить свой вариант может быть хорошим решением. Которое встретит поддержку. Вот тут win — win.
Но рассуждения выше — это если исходить из того, что нужно продукту. К сожалению по моему опыту делать то что лучше для продукта часто приводит к стратегии win — fail для себя. Подтянуть можные подходы и технологии намного легче на пет проекте. А на зарплату инициативность и боление за продукт влияет отрицательно — ты и так мотивирован, зачем тебе платить больше. Но это по моему опыту. Очень надеюсь, что это мне не везло.
И наверное стоит подчеркнуть — выше это про инициативность и фичи. Качество работы и техническую часть я считаю что в любом случае стоит делать хорошо. Это и честно и полезно для себя, как программиста. Что именно считать хорошим в каждом отдельном случае — это отдельный вопрос, на который не всегда можно дать правильный ответ, но с опытом приходит понимание где можно забить костыль, а где надо потратить время и продумать архитектуру.

От уявіть собі. Ви приганяєте своє авто на СТО. Кажете майстеру, що тре робити. На другий день приходите забирати, а він каже: «Я те, що ти хтів, зробив. А потім в мене ще був вільний час, тому я твого двигуна 2.2 викинув та поміняв на п’ять літрів V12 (в мене зайвий був, ніде його використати), то тобі безоплатно та від щирого серця, бо так же ж воно краще поїде...»
А вам, наприклад, п’ять літрів нафіг не потрібно, бо вам важливіше за все була економність...

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

Привносить свои улучшения в проект клиента/заказчика можно и нужно! Но есть большое НО. Это нужно делать корректно и в этом процессе есть огромное количество нюансов.
1) Если ты часть аутсорс команды, то в первую очередь такое улучшение нужно согласовать со своим ПМ/ДМ. Возможно твоя идея очень крутая и ее можно продать как upsell клиенту. Клиент будет рад, что команда проявляет инциативу, клиенту будет польза о внедрении нужной фичи, менеджмент аутсорс компании получит профит от дополнительной прибыли от upsell, менеджмент аутсорс компании будет рад повышению репутации в глазах клиента.
Но этот путь тернист, не прост и длителен по времени.
После того, как ты предложишь, а затем продашь свою идею ПМ/ДМ, эта идея будет взвешена и оценена менджментом с вовлечением дополнительных ресурсов (аналитиков, архитекторов, продактов и тд). После этого идея будет в корректном виде озвучена клиенту. После этого, если клиент даст добро — будет определена команда, которая займется дополнительным анализом реализации этой фичи, оценкой ее имплементации и внедрения. И только после последующих согласований — эта фича будет передана в разработку. При этом она может быть передана в разработку не тебе, а другой команде, которая будет на взгляд клиента или менеджмента наиболее целесообразной для реализации данной фичи.
2) Если ты часть продуктовой компании — задача немного упрощается, но все равно есть целый ряд упражнений, через которые нужно пройти прежде, чем что-то оптимизировать.
Для начала нужно обсудить свое предложение со своим Product owner или если такого нет — со своим лидом или ПМ.
После того, как ты предложишь, а затем продашь свою идею, ее анализом займется либо PO, либо ответственный аналитик, после оценки этой фичи, если она будет актуальна — ее оценят с точки зрения business value и соответствия целям компании. После этого фича будет приоритезирована и запланирована в работу наиболее подходящей команде для имплеметации и опять это ее непосредственной имплементацией вероятно будешь заниматься не ты.

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

Ви написали, в цілому, може й вірно. Але я б не хотів працювати в компанії з таким підходом. Занадто багато бюрократії. До того ж ви описуєте самий довгий шлях, а подаєте його як найкоротший.

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

Якщо ж в сфері компетенції іншої команди — знайти їх ліда і «продати» ідею туди.

Якщо ж фіча десь на межі ( щось там з апі, наприклад ), то можна обговорити на мітингу і якщо ок, то одразу йти чи самому чи з лідом до іншої команди чи до «найменшого спільного кратного», де приймається рішення.

Взагалі, якщо рішення приймаєш не ти, то є сенс одразу йти до того, хто його приймає ... і чим менше «посереднків» тим краще. А там вже вирішиться чи треба там аналітик/дизайнер чи ні.

Ну і якщо це зовнішній клієнт, треба дивитись на те як організована робота в цілому. Можливо є сенс продати фічу клієнту одразу і на рівні «виконавець-виконавець» і потім вже підняти її на рівень sales. Але знову ж ... по обставинам.

Будь-яку зміну треба розглядати не в єдиній точці, де вона власне відбудеться, а в усьому виробничому циклі. Грубо кажучи, рацуха по перенесенню дирочки в корпусі двигуна на 5 см вліво може давати покращення в одній операції, але вимагатиме перерозрахунків міцності, переробляння форм для литва, заміни оснастки, перенавчання працівників конвеєру, заміни технологічних карт та інструкцій, і бозна ще чого. І у більшості випадків виграш від «покращення» не покриває витрат у всьому циклі. І тому так, всі згідні, що так було б краще, але ніхто не стане того робити, і не затвердить такі зміни.

На жаль, будь-який проект в процесі реалізації костеніє та втрачає гнучкість. Рішення, прийняті на початку, жостко лімітують подальший розвиток, і, подеколи, струнка та естетично довершена ідея в процесі реалізації перетворюється на гидку потвору. В більшості випадків з тим нічого не вдієш.

Ви все вірно кажете... такі випадки бувають. І тут щоб щось змінити, потрібна тверда «політична воля».

Моя ж теза полягає в іншому: далеко не кожен рух здатен порушити крихку рівновагу проекту. І рішення є сенс приймати як можна простішим способом (що в більшості випадків є можливим ... тим більше в IT).

Для того, щоб проект розвивався, ініціативу потрібно заохочувати. Це дуже наївно вважати, що хтось розумний може «сісти і придумати» гарний продукт/рішення/архітектуру. В багатьох випадках проблеми вилазять при безпосередній реалізації. І хочете чи ні, а якість придуманої архітетури найкраще бачать ті самі прості розробники.

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

якість придуманої архітетури найкраще бачать ті самі прості розробники

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

І увесь «бюрократизм» викликаний не палкою любов’ю керівництва до субординації та обкладання папірцями, а намаганням дати раду складності сумі всіх умов та обмежень, яких необхідно дотримуватись.

Повертаючись до аналогії з двигуном, завжди є можливість десь, замість передбаченого проектом каленого болта М4, якого нема на складі, вкрутить саморіза, який на складі є. І воно таки буде працювати. Певний час. Поки різьбовий отвір під болт не розіб’ється у вульгарну дирку. Так, подібне «покращення» дозволить випустить в строк кілька тисяч двигунів і зекономить кілька копійок на болтах, але потім неминуче почнуться проблеми з підтримкою продукта, рекламаціями, репутаційними втратами, а подеколи все закінчується банкрутством та вильотом з ринку не тільки продукту, але й усього бізнесу.

бачить лише спек на модуль та інтерфейси

В нас з вами трохи різний досвід. Як на мене, розробник має знати свою частину детально, а решту хоча б поверхнево (включаючи деплой, вимоги і бізнес задачі).

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

намаганням дати раду складності сумі всіх умов та обмежень

Коли ви про це кажете, ви намагаєтесь уникнути вкручування саморіза замість болта.
Коли ж я про це кажу, я намагаюсь почути голос того інженера, що спостерігає як на одну вісь ставляться колеса різного розміру і він не може нікому про це сказати, так як весь бюрократичний процес займе в нього місяць подолання перешкод.

Просто нужно правильно ставить приоритеты. Безопасноть для продукта или продукт для безопасности?

В нас з вами трохи різний досвід. Як на мене, розробник має знати свою частину детально, а решту хоча б поверхнево (включаючи деплой, вимоги і бізнес задачі).

Це аджайл-досвід, так?

Це аджайл-досвід, так?

Думаю, можна так сказати.

Уявіть собі, що мені архітектор, ландшафтний та інтер’єрний дізайнери розробили проект за моїми вподобаннями. Якось так, наприклад:
www.buildingplanner.in/...​s/ready-plans/34N1001.jpg
І ось я наймаю декілька бригад — бетонувальників, мулярів, штукатурів, електриків, сантехніків і так далі. І починаю будувати будинок своєї мрії. І ось вже близиться фініш

І тут штукатур, від якого мені потрібно лише рівні поверхні стін, починає критикувати колорістичні рішення, пропонує замість італійської плитки кинуть лінолеум, і висловлює принципову незгоду з розстановкою меблів... Фінал дещо передбачуваний, чи не так?

В аджайлі клієнт сам до пуття не знає, чого хоче. Розробник робить і показує. Клієнт погоджується — робиться наступний крок. Не погоджується — попередній крок переробляється. В аджайлі розробник приймає рішення і робить вибір. Клієнт лише погоджує чи завертає ці рішення.

У вотерфолі розробник робить лише те, що йому кажуть. Від забору до обіду. Так, як сказано, там де сказано, з того, з чого сказано. Всі рішення прийняті ще до початку будівництва. Увесь вибір зроблено іншими людьми. Думка виконавця щодо вибору рішень нікого не цікавить. Йому платять виключно за рівні площини.

Нещодавно робив ремонт ... ви знаєте ... це ще той agile )))

Тут ми зараз знову ж можем кожен наводити свої історії ... Електрик, наприклад, може зауважити, що десь варто кинути іншого перерізу провід, бо проектний буде грітися... чи, наприклад, запропонувати на ванну поставити додатковий ПЗВ (і бажано поставити більший щиток). Сантехнік може сказати, що туалет занадто далеко від стояка і «з цим треба щось думати». Штукатур може сказати, що десь порушена геометрія кімнати ... тощо.

Не обов’язково з усіма погоджуватися ... але почути це варто і осмислити чи є сенс щось міняти, поки не пізно.

Waterfall має свої недоліки. Тому й придумали agile. Як на мене, навіть коли все продумано від початку до кінця, є сенс звертати увагу на обставини по ходу. В готовому будинку ще одну розетку доставити важко ... але в 99% випадків дуже хочеться.

Та й ось SpaceX показує, що agile застосовний навіть в галузях, де був waterfall десятиліттями... в них ж кожен запуск starlink-а — це як спринт ... щоразу новий білд і нова модель супутника. І, як виявляється, воно життєздатне.

Ну ... кругом є межа ...

Якщо «тут в тебе труба прорвала ... ми її підлатали щоб не текла ... що з нею далі?» — то це більш ніж ок.

Якщо «ми тут вікно на іншу стіну перенесли, бо в сусіда злий собака» — звісно що не ок і треба було обговорити.

Ми тут ходимо по колу )) І дискусія вже трохи поплила від оригінальної теми.

Моя теза полягає в тому, що потрібно притримуватись в цьому питанні якогось здорового глузду.

Тихо пиляти фічу тиждень і нікому не казати — НЕ ок.

Зробити за дві години якийсь експеримент/proof of concept/рефакторинг (без мержа в мастер) і потім винести на дискусію (бо натхнення прийшло) — цілком ОК.

Мої коментарі вище — це не так оцінка того, що ТС пише, як реакція на те, що коментатори пропонують сидіти і не висовуватися.

Ініціатива — це круто і вірно і це треба заохочувати, а не подавляти.
Звісно, що це має мати межі здорового глузду і робитися «при світлі дня», а не «під столом, поки ніхто не дивиться».

но как бы это и не то что нужно заказчику

Это, в данной ситуации, ключевое (если, конечно, вы не ошиблись в формулировке и не имели в виду что-то совершенно иное).
Если что-то не нужно заказчику или просто имеет низкий приоритет, по сравнению с остальными задачами — то и делать это не нужно.

Также учтите, что для плодотворной работы, ментального здоровья и т.д. нужно соблюдать work-life balance, а значит — никаких активностей в свободное время, тем более бесплатно)

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

Работает не трогай = хз как оно работает => недостаток квалификации, имно, конечно же.

ЗАКАЗЧИК знает как оно работает раз он с этим работает. а не умник програмист не понимающий предметную область

То вы еще убийцу фейсбука не делали наверное. Или файловый 1с на 50 юзеров.

ЗАКАЗЧИК знает как оно работает

Разные ситуации есть..................................

Тут про один из аспектов последствий улучшений хорошая дискуссия
habr.com/ru/post/557678

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

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

С тестами тоже нужно быть осторожным. Некоторые могут сильно замедлять CI, другие — ломаться при малейшем рефакторинге, когда поведение системы не меняется. К тестам тоже нужно с умом подходить.

Рівень небезпеки від погано написаного тесту все-одно в рази нижчий. Кінцевий користувач продукту не прийде бити морду. А сповільнений CI — ну, то таке. Рефакторинг, що зламав тести? Так це ж взагалі пісня! Якщо тест мав якийсь сенс, а рефакторинг його зламав — то це помилка у рефакторингу і наявність тесту пішла на користь, оскільки не дала зробити дурницю. Той, хто робить такий рефакторинг, має бути вдячний тому, хто написав тест.

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

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

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

Да, с тестами нужно быть осторожными и правильно их писать, и естественно, криво написанный тест, может принести больше проблем, чем пользы.

Но большинство согласится, что в большинстве случаев лучше, чтобы тест был, чем его не оказалось.

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

Так а де хто казав писати неякісні тести? Звичайно, що потрібно писати якісні. Мова йшла про рівень небезпеки і відповідальності від коду умовного джуна, доданого з власної ініціативи в продакшн або в тести. Я б, напевне, в 99% відхилив таку ініціативу для продакшена, але в більшості випадків погодився б на розширення набору тестів.

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

Я сталкивался с проектами, где тесты гоняются круглые сутки параллельно на куче машин. Brittle tests в обязательном порядке шли на переделку.

Тесты гонялись круглосуточно, потому что было много merge request-ов? Или потому что прогнать тесты занимало сутки?

Много реквестов. Да и тестов под миллион

Всіх, хто радить не лізти з ініціативою взагалі — не слухай. Якщо нікуди не лізти — то нікуди і не вилізеш. Просто лізти треба обережно.

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

Расскажу пример из жизни.
На одном моем проекте поощрялось спорить, отстаивая какую-то позицию (по техническим вопросам). Если не отстаивал — то считалось отсутствием инициативы, безвольностью и токсичностью.
Потом я перешел на другой проект, и когда начал применять поведение с предыдущего проекта — то менеджер мне довольно скоро тактично намекнул, что со мной сложно работать.
Я откалибровал этот момент, и с тех пор стал делать только то что просили, 0 инициативы и 0 споров.
Все последующие годы менеджер давал мне performance review «exceeds expectations» и моя ЗП выросла x1.5. Украинский филиал спустя 5 лет попал под сокращение, но меня уволили в числе последних.

Автору его менеджер уже дал обратную связь.
Если будет продолжать гнуть свою линию — то его скорее всего уволят.

Ніхто не насварить за зайвий тест

Видел примеры обратного, когда заказчик предъявлял в весьма эмоциональной форме претензии за часы, потраченные на написание тестов по инициативе команды. Причём, «градус вопроса» там был десятки часов максимум.

Дивлячись на якому етапі то робити, звичайно. Якщо «десятки годин на тести» були витрачені в першому спринті командою з двох людей — замовника можна зрозуміти :) Я радив з огляду на ситуацію топікстартера — великий проєкт, давно йде, багато людей, хочеться розібратися і щось покращити. Шанси конфлікту з замовником — мінімальні.

В мене один із взагалі життєвих принципів — не робити добро, поки не попросять. Інакше — це саме ті благі наміри, які до пекла ведуть. Можна спитати, чи не треба допомога, і тоді попросять, якщо треба. Можна от запропонувати, як ви зробили і розпитати, чому ні. Можна таки зробити самому, але тоді усвідомлювати, що робиш це тільки для себе і нікому більше воно потрібно не буде (найімовірніше) і запросто будуть ще й пручатись. І тоді треба ще уважно дивитись, щоб не нашкодити, ну і розуміти, навіщо воно вам.

Я в такій ситуації зазвичай звільняюся. Працювати від паркана до обіду — ну його в дупу.

Так і запишемо, Микиту Бондаренка — на звільнення.

Если ты просто бодрый джун, которому хочется быстрей опыт набить, то:
1. Улучши.
2. Протестируй.
3. Удали
Воспринимай это как задачки с литкода.

Важное уточнение — «в свободное от работы время»

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

Если от каждого ждать апрува, то задолбаешься ждать.
Победителей не судят.

Ты просто зануда

Я так колись отримав свого першого закордоного замовника

Кстати, почитав комменты, я так и не уловил твою мотивацию. Для чего это тебе?

Такой подход может здорово помочь прокачаться. Если компания этого не ценит, можно двигать дальше со временем. Но нужно понимать свою ответственность за подобные решения и согласовывать это с бизнесом. Нужен баланс между подходами better safe than sorry и наборот, зделать что-то принципиально полезное и извиниться, что потратил на это время.

Может, просто не повезло с проектом/командой/компанией?

Интересно. Больше интересных задач — больше опыта, больше опыта — больше интересных задач:)

Да, все верно. Если в компании подобные инициативы не проходят, тогда можно смотреть в сторону open-source. С pet-project сложнее, потому что не все доходят до прода и целый пласт задач просто не всплывает. Или, как уже говорили, leetcode + system design :)

В проде появляются новые проблемы поддержки, изменение, масштабирования. Чаще в запущенных проектах они уже есть, а в pet-проектах с ними может вообще не придется столкнуться.

Так что посыл их не делать я не понимаю.

Надеюсь, тебе не показалось, что он исходил от меня.

Может ты любитель решать задачи аля "Починить то, что в продакшне будет плохо работать".

Я сторонник изначально делать так, что бы в продакшене работало хорошо.

Естественно я загорелся желанием в свое свободное время сесть и сделать их.

Тут есть пару топиков, где говорят, что в свобоное время надо литкод решать, а не бесплатно легаси рефакторить неизвестно кому и зачем.

Тут говорят что в свободное время надо спамеров в шоколадный глаз. К монахам иди со своим спамом жидкодом.

Кроме тех аргументов что уже приводили — делая что-то бесплатно, вы не даете своей компании возможность сделать upsale (продать дополнительные услуги или +1 человека в команду). Поэтому это и не приветствуют (се ля ви). Сделать немножко лучше — приветствуется, это называется going the extra mile. Но делать прям много всего заказчику бесплатно (там где компания могла бы продать еще услуг или людей) это вы у компании отбираете хлеб вообще-то.

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

Естественно я загорелся желанием в свое свободное время сесть и сделать их.

Хрень какая-то.
Если ты молодой и есть много энергии — то придумай себе тему и пили ее в свободное от работы время.
Так рождались великие компании.
Поверь, спустя десяток лет этой энергии сильно поубавиться и ты это уже будешь не в состоянии сделать.

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

Когда вы поймете *что не так* станете токсичным. Или как раньше говорили циником.
По сути, проблема в *софтскилах* — т.е. донести ценность улучшения не в ваших силах.
Конечно же, еще проблема часто в компании, и её миссии — если это банальный способ заработать себе на новую ламборгини, попутно кинув всех по привычке. То нужно тихо гребсти пока ЗП не задерживают и все(о чем ниже не раз, и не два, написали).
Часто клиент и так похож на быка которого с коровой перепутали 8). По этому за фичу никто не заплатит.
Если абстрагироваться, то тенденция брать (почти)синьеров на мидловые/джуновские позиции(по экспертизе) и заливать их баблом именно к этому и ведет. (Человеку скучно работать, и он придумывает как развлечься, лучший все равно думает о том как улучшить свою работу).

в проектах стартапного типа со временем тебя могут услышать и оценить

ты не архитектор проекта и подрываешь авторитет авторитетам
знай свое место
если идея хорошая ее могут присвоить а тебя сократить

Ты веришь что у всех проектов есть архитектор? Или хотя бы у 10%?

Коментар порушує правила спільноти і видалений модераторами.

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

Делать это в свободное время — плохая идея.

Можно предложить улучшение, поговорить с продакт овнером и менеджментом, если им нравится и они согласны — они могут создать таску/задачу для этого.

И уже в контексте этой таски/задачи можно делать улучшения.
В рабочее время.

В рабочее время.

В час який трекається та оплачуться

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

Точно не дивиденды, а ещё один проектик в нагрузочку за те же деньги, хорошо ведь справляешься

тогда запоминаешь этот факт и начинаешь копать в интересном тебе направлении (много или мало)

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

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

А так людей которые овертаймят бесплатно по собственному желанию и на галерах хватает.

в свое свободное время сесть и сделать их.

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

чаще замечаю вещи, которые мог бы улучшить

Бывает да.
Кто еще согласен с этими пунктами:
1 вы можете
2 улучшить
?

Естественно я загорелся желанием в свое свободное время сесть и сделать их.

Сделайте.
Начните с нечто вроде статьи-плана-тех задания
1. Сейчас вот так
2. Это плохо, потому что а) б) в)
3. Если сделать так и так — будет хорошо
4. Потому что а) б) в)

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

да, — внезапно — это точно не то что нужно.
Кто-то должен прочесть или послушать ваше мнение.

Если вы его написали, — то даже когда откажут — вы сможете сделать с этого статью. для своего блога, доу, медиума/dev.to

будет — польза вам даже больше чем если вы сделаете фичу.

Тут же win-win, что не так?

Пока никакого win-win не видно.

Ничего личного, но из моего опыта — самые самоуверенные архитекторы — среди джунов.
И уверены что за выходные все перепишут — тоже джуны.

В вашей истории не хватаете главного — рациональных подробностей :)

Желание улучшить конечно похвально. Проактивность, вовлеченность — это отлично!
А вот самодеятельность когда вы в команде — уже не очень хорошо.

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

молодость она такая, потом как прилетит тебе за твое улутщение, — сразу перестанеш дурней страдать.

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

Я бы поприветствовал такую инициативу на месте заказчика (если это реально делает продукт лучше и не создаёт дополнительного головняка), но нужно было сначала обсудить. Коммуникация в команде — важный момент.
Как сделать, когда сделать и т.д?

когда сделать
в свое свободное время

Ну там же не только ресурсы разработчика могут понадобиться

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

Инициатива е*ет инициатора:) Это классика, пару раз тебя прокидают с твоими предожениями, ты задемотивируешься и будешь сидеть хладнокровно делать унылые таски в 3 раза дольше чем обычно — посматривая ютубчик:)
Велкам ту зе клаб!

Вспоминается классика от Лебедева.

Класика у тьоми татьянича — це вкрасти і видавати за своє

Меня это то же удивляло по-молодости. На первом проекте опытный синьор учил меня как правильно делать новые фичи: берем файлы исходников, КОПИРУЕМ ЦЕЛИКОМ, переименовываем классы методы и тогда меняем. Т.е. если у нас был класс PriceCalculator1 то копируем и делаем класс PriceCalculator2 и потом в нужном месте ставим ветвление какой класс вызывать.
Я тут же начал возражать что дублирование кода — это плохо, надо рефакторить, наследовать, декомпозировать и т.д.
На это он привел железные аргументы:
1) Ты уверен что точно знаешь как работает класс PriceCalculator на 10 000 строк? Нет? Так никто из команды уже не знает!
2) Класс PriceCalculator покрыт юнит тестами или любыми другими тестами, которые проверят что после изменений ничего не сломалось? Нет!
3) У тебя есть документация, которая описывает текущий алгоритм расчета цен, новый алгоритм и правила когда что применять? Нет!
4) Если ты поменяешь хотя бы одну строку в существующем классе PriceCalculator1 — как ты убедишься, что из 100500 клиентов, которые используют разные комбинации скидок и т.д. ни у одного не поменяется цена товаров? А какой скандал будет если все-таки поменяется ты понимаешь?
Ты хочешь сделать что-то новое? Делай так что бы оно 100% не повлияло на старое. Потому что в большом проекте невозможно проверить где и что отвалиться.
Любой рефакторинг, улучшение производительности, переход на новые версии, даже исправление явной ошибки в коде или прочие идеи, которые могут предложить девелоперы, для клиента означает потенциальные проблемы с валом звонков от недовольных юзеров у которых что-то начало работать не так, как раньше!
Предположим девелопер очень хорошо разобрался в бизнесе клиента и предлагает какую-то не чисто техническую фичу. Которая, к тому же, не повлияет на существующий функционал. Ну, например, прикрутить на сайт чат-бота. Даже если девелопер сделает это абсолютно бесплатно — это все равно новый функционал, который нужно: релизить, тестировать, мониторить, чинить, интегрироваться и т.д. Т.е расходы все равно будут. А вот будет ли от этого какая-то прибыл — неизвестно. Если юзеры не просили эту фичу, если бизнес аналитики ее не предлагали — то какая вероятность что это вообще кому-то нужно?
Посмотрите сколько возможностей в больших продуктах (например MS Word) и про сколько из них не знает и никогда не использует 99% пользователей! От «мертвых» фич такой же вред, как от мертвого кода.
Поэтому девелоперам и не дают ничего улучшать в проекте по своей воле. Если есть желание покреативить — то лучше сделать отдельный прототип и показать его клиенту. Возможно ему понравиться и тогда уже он, оценив все плюсы и минусы, выделит оплачиваемое время на разработку, тестирование, интеграцию, поддержку и обучение юзеров этой новой фиче. И если прототип девелоперы напишут за пару выходных, то внедрение этой фичи в продукт — это уже вопрос немалых денег!
P.S. Это извечная проблема: работаешь на дядю — делаешь что прикажут. Хочешь творчества — пили бесплатно опенсорс или стартап (скорее всего получится то же бесплатно).

Ты уверен что точно знаешь как работает класс PriceCalculator на 10 000 строк? Нет? Так никто из команды уже не знает!

и как итог, вместо одного — ДВА таких класса

И просто адовое количество ошибок, когда вместо одного прописали другой — и всё ж работает! И тесты проходятся на ура.

А потом три и и т.д. Как бы глупо это не выглядело — но это снижает риск возможных последствий. Если внести изменения в старый класс, который используют тысячи пользователей — наверняка хоть у кого-то поломается. Если делать новый фичи в новом классе — то это повлияет только на тех нескольких пользователей, которые попросили эту новую фичу.
Если кто не знает IE умер именно потому, что в каждой новой версии IE были режимы для всех предыдущих версий!
Итог таких гнилых энтерпрайзов известен: приходит конкурент с новым блестящим продуктом, который не тормозит из-за старого кода и юзеры постепенно сбегают к нему.
Чисто психологический эффект: скажи юзерам что мы в новой версии передвинем кнопку — они будут вопеть «вы сломали мне жизнь!», «верните как было!». Покажите юзеру новое приложение с совсем другими кнопками — и он будет говорить что оно лучше и как ему было неудобно на старом (хотя он сам требовал ничего не менять!). И его даже не будет смущать что новое приложение не умеет половины того, что умело старое — оказывается что без этого тоже норм.
Думаю это одна из причин почему постоянно появляются новые приложения. Намного дешевле написать новую версию «с нуля», чем годами поддерживать старое, гнилое приложение. К сожалению многие клиенты не понимают этого — и тратят деньги на «мертвую лошадь», в то время как рядом их конкуренты пилят «убийцу».

Вот собственно это и приводит к тому, что дешевле написать новую версию.
Безоглядно лезть и менять класс в таком жестком легаси, конечно, нельзя. Но добавить еще кучу копипасты ОЧЕНЬ бысто убъект проект. Когда пришли и попросили поменять 1 мелочь во всех флоу, а это не в 1 месте, а 5 в каждом классе. А классов уже 3. И каждый живет своей жизнью и никто не скажет все ли флоу ты нашел.
Поэтому такой «опытный синьор» отлично может страховать себя от увольнения — кроме него в этом бреду никто не разберется. Но если даже уже есть такой монстр класс стоит попробовать донести бизнесу всю жесть положения и получить время на разгребание тех долга. Хотя те кто довели до такого состояния проект вряд ли будут готовы признавать ошибки и уж тем более публично перед бизнесом

В нас були десятки копіпаст, зроблених різними індусами в різний час.

Бобер часом не індус? Чи ми вже деградували викреслено просвітлилися до їхнього рівня двадцятирчної давності?

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

Ті хто хочуть тільки зарплату в ІТ, походу ще й Commodore в дитинстві не бачили!
Як таких можна допускати до коду взагалі?

Жах!

К коду, убийцы розетки за 2 мес, нормальный инженер и так не полезет. Остальным нужны софт-скилы чтоб зепку с тонущего судна вытащить.

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

Очень точно замечено.

Бобёр, ты странный. Какие-то новые идеи бизнесу, за бесплатно!?! А болтецкий он не лососнёт?! Моя задача пилить код, с утра и до обеда. С минимальной производительностью, чтоб только не выгнали и оставалось время на свой бизнес.

Какие-то новые идеи бизнесу, за бесплатно!?! А болтецкий он не лососнёт?! Моя задача пилить код, с утра и до обеда.

Каждый день тупо пилить что прикажут и даже не пытаться делать свои идеи? Я думал это как раз самый надежный путь к выгоранию и депрессии.

А зачем ты на работу тратишь больше трёх часов в день?

Так легче поменяться самому, чем поменять мир под себя. Нет?

Если на каждую фичу создавать 10 тыс строк копипасты, то и за деньги мне кажется долго не проработать. Наверное до первого вменяемого code review.

Там где классы по 10К строк там апприори нет

вменяемого code review

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

Это основная проблема всех больших проектов, которую я видел неоднократно.
Когда первый раз пишут класс вроде PriceCalculator — в нем несколько сотен строк. Это новый проект, у нас аджайл, поэтому времени что бы выносить интерфейсы, все покрывать тестами, писать комментарии и документацию нет. В аджайле рулит KISS и «само-документирующийся» код...
Потом добавляется новое правило пересчета. Ну не будут же вместо одного if в коде делать рефакторинг и применять какие-нибудь паттерны? Воткнут if и в лучшем случае напишут 1 строку комента зачем. Потом юзеров становится больше — каждый хочет свои скидки, свои правила — ветвлений становится все больше. Через полгода в классе PriceCalculator уже несколько тысяч строк.
И вот тут уже пора его рефаторить, разбивать на подклассы, выносить стратегии или вообще делать workflow с заделом на будущее расширение... НО шанс уже упущен! Даже если сам рефакторинг не слишком сложный — то риски колоссальные. И что бы убедиться что ни у кого ничего не сломается потребуется масса тестирования (каждое ветвление в коде удваивает число вариантов)! При этом для клиента все это не несет никакого business value — только риски.
Ни один ПМ не сможет уговорить клиента за такое заплатить!
Ну и все — с этого момента код начинает «гнить»: вставляют костыли, делают дублирование что бы ничего не сломать, изначальные авторы покидают команду и еще через год-два в классе PriceCalculator 10 000 строк и никто не знает всего, что они делают.
Я вижу единственный путь как с этим бороться: овер-инжениринг. Если делаем PriceCalculator и знаем что правил может стать больше — то сразу наворачиваем максимально гибкое решение. Например workflow с пайплайнами и жесткими интерфейсами для правил. После этого следим что бы этот дизайн никто не «расширил», сделав все паблик и напихав правил по тысяче строк.
Но это противоречит идее аджайла и желанию клиента и ПМа быстро получить MVP и потом его расширять. Такой подход сейчас любят клиенты.
По-мне это выглядит так: давайте сначала построим киоск, а если бизнес пойдет — то потом надстроим сверху еще 100 этажей! Хотя и дураку понятно что если хочешь когда-нибудь получить небоскреб то для начала нужно заложить фундамент, который его выдержит.

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

До першого фічереквесту, який складніший, ніж підправити кілька констант.

Але теоретикам тут видніше...

Сіньйор був індусом?

Бо ми щось таке потім колись переписували, після того, як до цього стало неможливо дописувати фічі.

Интересный «senior» подход. Я думаю, что так долго не продержаться. Как минимум есть метод — red-green refactoring, если верно было написано, что данная функциональность покрыта unit тестами. Отрефакторил, прогнал и вперед. Вот так, собственно, код и бронзовеет — таким образом превращаясь в отвратительный легаси. Все потому что — по простому и побыстрее. Чтобы потом было время на что-то другое.

функциональность покрыта unit тестами. Отрефакторил, прогнал и вперед

Такое работает только в теории. На практике даже если 100% строк кода покрыто юнит тестами — это абсолютно не гарантирует что его можно безопасно менять!
Потому что для 100% гарантии нужно покрыть не только 100% строк, но и перебрать все возможные варианты входных данных. Вот, на вскидку для банального метода с одним числовым параметром:
— положительное число, отрицательное, ноль
— целое или дробное
— варианты 9.999999 или 0.00001
— числа на 0.5 или 0.555555 (округление математическое или лас-вегас)
— числа, которые дают результат «в периоде» 1.3(3)
То есть на 1 функцию с 1 параметром нужно написать несколько десятков тестов! А если параметра 2 то это уже сотня тестов (все комбинации).
Понятно, что абсолютно никто так не делает. Пишут 1-2 теста. В итоге любое элементарное изменение в коде может привести к тому, что какая-то из не-проверенных комбинаций начнет возвращать немного другой результат.
Например, в теории a/c + b/c == (а+b)/c. А на практике округление может дать отличие где-то в 4 знаке после запятой. И это будет заметно, например, только на заказах от 10 000. Найдет клиент это случайно через пол-года и скажет «а верните-как мне с каждого заказа те 50 центов, которые из-за вашей ошибки недосчитывало». Понятно что воранти и все такое — но формально-то он прав: из-за вас он потерял деньги!
Поэтому и существует пресловутое правило «работает — не трогай»! Ну или если оно же в виде SOLID принципа:
Open for extension, Closed for modification(!).
В идеале один раз написанный и проверенный код должен никогда потом не меняться! Но что бы так работало — нужен очень правильный дизайн, с мелкими «кирпичиками» с слабой связностью. И его нужно проектировать сразу, а не резать монолит потом.

Тут вот и пригодится test driven development, когда входные данные получают и утверждают c product owner (ну или как оно там называется) :)

таких подробностей реализации продакт овнер часто и не знает, и не должен знать.
если кто и должен, помимо программиста, так QA

Зачем подробности реализации? Надо знать при каких входных данных какие результаты должны быть на выходе. Это как раз область знаний продакт специалиста (в моём понимании).

Надо знать при каких входных данных

продакт овнеру?
а что еще должен знать такой Господь Бог — вместо программиста?

Это как раз область знаний продакт специалиста (в моём понимании).

это понятно что вы о своем понимании.

а в моем понимании программист обязан быть способным проанализировать «арифметику»
и т.д.
в моем понимании запросы у «программистов» идут к тому что другие обязаны в сторону:
вы мне пришлите такие ТЗ и спеку, такой детализации, чтобы я смартом сфоткал, и в IDE вставил
А IDE пусть распознает, и «гугл транслейтом переведет».

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

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

А если нет «арифметики» и надо тупо иметь специфический опыт в предметной области

так в книгах и пишут что, программист увеличивает свою ценность в компании, в проекте, когда у него появляются знания домена :)

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

абстрактному программисту:
тупо спецификацию, где почти код написан, да лид три раза пояснит, и т.д.

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

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

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

ну и похоливарить на темы кодер vs программист, кто такой мидл, а кто такой синьор, вовлеченность, продукт ориентированное мышление, тупо нехватку времени, потому что еще три критикал таски и т.п.

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

Вон на той неделе

у нас баг всплыл, на проде

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

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

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

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

А поди ж ты...
В итоге — списание дважды (нарыл у одного пользователя — 7 раз списало!)

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

И вот, давайте юнитестами выловим.
Покроем ими на 99,9% код.

а, и продакт овнера отпинаем!
чего он в тз/спеке не написал, как надо писать код??
и лида, как он так ревьювал, а?

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

из чего неверно делать вывод что они не нужны, юнит тесты.

Но польза от их наличия вот в этом:

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

да, вот если б такой дизайн, то может быть и ловили бы они существенное.

Поэтому и существует пресловутое правило «работает — не трогай»!

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

а то вот три маленьких латочки
1 от программиста А,
2 потом на его латочку программист Б добавил,
3 потом бажик мелкий фиксал программист В, и тоже, аккуратненькую латочку поверх этих двух.
Тесты зеленые — все ок!

а под этими латочками тааааакой дефектище припрятан!
Дефект как следствие из:
«Ни одну проблему нельзя решить на том уровне сознания, на котором она была создана»

Конечно, по всякому бывает, есть сроки, есть опыт их срыва, есть объемы кода(и только овертаймить? а оно тебе надо?), есть управляемость-прогнозируемость разработки, ..., ...
it depends...

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

Если это решение техдолга, изменение имплементации, которая не влияет на поведение и ускоряет команду или улучшает процесс, то норм, конечно. При условии, что есть peer review. Если это фичи, которые влияют на бизнес, то обязательно нужно согласовывать с Product Owner-ом перед началом подобных изменений, как уже объясняли.

Питання не розкрито.
Якшо твій код потрапив на production, то виникає питання — а шо це за компанія, де кожен джун має доступ до prod-а? Якшо ж не потрапив, то історія мала б обірватися ще на етапі code review.

Пройде кілька років і ти взагалі ніколи нічого не будеш робити без відповідної задачі в jira.
Все нормально, це приходить з досвідом.

а шо це за компанія, де кожен джун має доступ до prod-а?

Netflix?

Якшо девелопери +/- одного рівня, то без проблем. Але якшо іде явна градація на junior/senior, то не думаю, шо це хороша ідея.

Ну, і як там в Netflix?

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

Ну, шо я можу сказати? У мене досвід абсолютно протилежний.
Хоча сама ідея, коли в кожного є доступ до прода — мені імпонує.
Процеси рішають все, тут без варіантів.

Конечно, я говорил не о внесении внезапных изменений в production код, это уже совсем ниндзя техники :D

це приходить з досвідом.

Да, этим и занимаемся.

Возможно твоя фича кажется только тебе полезной, остальным она и нахрен не нужна, особенно пользователям и/или бизнесу которому нужны решения проблем, а не очередные фичи.

Это с какой радости?

Це коли в автора кода его дуже спітніле і розпухше
Тіки тронь і гній поллється

xD

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

Якщо в скотобазі: взагалі не бачу сенсу щось педалить їм на шару (хоча теж грішив так), плюс своєю активністю на фоні того сміття, що працює поруч, ти всіх будеш підставляти і станеш токсичним.

Якщо в продукті: зроби 1×1 з вишами, покажи їм працююче демо свого покращення, покажи, що якщо для них ОК: то зроблю ще це і це, але уже в робочий час (ключовий пункт). Якщо дають добро — то їм це дійсно треба і цікаво. Якщо кажуть, що тільки у вільний час — миттєво забий. Бо тебе почнуть доїти.

Я от зробив іноваційний продукт всередині продукту, уже другий рік його розробляю :-)

Совершенно неправильно так делать. Насколько глубоко вы погрузились в проект?
Вы уверены, что это будет улучшение? Вы точно знаете, что оно вам надо?

Два примера из опыта:
— В аутсорсе: приходилось усмирять архитекта на стороне исполнителя, который верещал что «такой подход не потянет миллион запросов, давайте все переделаем». Задача подразумевалась на максимум 20 000 запросов (в той области не было и не предусматривалось больше пользователей). И проект и бюджет были спланированы соответственно задаче. В итоге — все работает до сих пор, хоть и прошло лет десять.

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

Оказывается, единственного пользователя продукта всё устраивало. Они потом руками допиливали данные, и разумеется, мы им поломали привычный процесс. Хотя делали «как лучше».

Заведи себе гитхаб и строгай в свободное время отвлеченные от проекта поделки там. Или контрибьють в опен-сорц если так в свободное время кодить неймется

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

Почему так: если ты предложишь за цену, заказчик будет считать что это вероятно что-то нужное и полезное.

Ну и ещё момент: лучшее — враг хорошего. Может заказчик просто не хочет рисковать тем, что уже работает, и совсем не уверен что твоё покращення взлетит без багов.

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

В остальном же — просто забей. Ты не собственник продукта и НИЧЕГО не получаешь от его хорошей работы. Найдётся другой заказчик, который оценит. Ты будешь умнее и чуть более деликатно предложишь. А этому — напомнишь, если ещё раз обратится. Может у него просто сейчас денег нет (ну бывает, человек должен кому-то), и потому он так ревностно относится к любой незапланированной трате, даже если реально понты стоит.

В аутсорс надо сперва договорится с клиентом и только потом пилить

В аутсорс надо сперва договорится с клиентом и только потом пилить

В продукті так само, треба спочатку говорити з продукт овнерами, а потім пиляти :)

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

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

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

Из 5 продуктовых контор где работал делал так в 4 и все было ок. Ещё так делал на фрилансе на 3 проектах, но по факту это был парт тайм на удаленьки (даже, клиент это сам дополнительно оплачивал).

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

Я не до конца понимаю почему. Тут же win-win, что не так?

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

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

Я не до конца понимаю почему. Тут же win-win, что не так?

У чому «він» замовника?
Ви додали фічу, яку треба підтримувати, витрачати на це гроші — це як би перша проблема. Ваша фіча може не співпадати зі стратегією замовника, як результат це може негативно вплинути на базу та паттерни використання системи кінцевими користувачами.
Ще проблема, фіча в продакшені — це не лише код, це і еффорти на тестування і саппорт користувачів в продакшені.

Якби ви запропонували фічу, і відповідальна за продукт людина перевірила, що вона потрібна в продукті — це вже інша історія, це проактивність і «продукт-орієнтованість».

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

Я больше имел ввиду оптимизацию старого функционала, а не добавление нового.

Хто заплатить за тестування? Чому ви вирішили, що ви його оптимізували?

Суть проблеми:
Є план, що має привести до деякого результату. Будь-які відхилення від плану — це ризики і їх треба оцінити і прийняти рішення чи не порушать вони план, а зробити це можна лише маючи певну картину проекту.
У вас на вашій позиції є достаня картина того куди і чому розвивається проект?

Да, тут возможен конфликт моих интересов и планов — против интересов и планов заказчика, но интересы могут и совпасть. Решение принимаю не я, но в целом общие векторы движения я же вижу, чтоб сделать предложение:)

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

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

Если ты на прямую участвуешь в развитии продукта, можешь предложить фичу на рассмотрение на этапе планирования.
Вносить «свое» на этапе реализации это не профессионально.

Если развить сравнение со строителями, то я условно — сделал колону и прелагаю заказчику взять ее если она его заинтересовала?

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

В серйозних проектах є чітка межа. Отут ми малюємо, плануємо, ескізимо, складаємо списки фіч, технологій та інших рішень, закладаємо певну базу під подальший розвиток і складаємо кошторис. В цей момент проект та його кошторис погоджуються та затверджуються. Вірішили так — і робимо отак. Всі нові ідеї — в список фіч для версії 2.0

І да, це різниця між аджайлом та ватерфолом. Бурдж Халіфа — це ватерфол. Аджайл — це бразильські фавели.

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

У меня встречный вопрос: а зачем? Ты хочешь потратить свое время, свой ресурс на то, что клиенту не нужно, и сделать это безвозмездно. Выучи новый скилл, прокачай фреймворк, добавь строчку в резюме и уйди с Ерата на +1000. ПРОФИТ.

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