Продовжувати роботу чи написати код з нуля: що робити з проєктом, у якому повний безлад?

Java Bee 18.05.2024 17:33

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch.

Відповісти

Підтримати

Beaver Green 18.05.2024 18:11

Але є одна проблема: якщо ти не зробиш нову версію свого популярного продукту «з нуля» — то це обов’язково зробить хтось інший!

Відповісти

Підтримати

Java Bee

Андрей Волков 17.05.2024 23:32

Не имеет значения. Переписанный заново или залатанный — все равно через 4-5 лет он будет бесполезной могилкой еденичек и ноликов.

Відповісти

Підтримати

Vic Programmer 17.05.2024 23:54

Та ну ХЗ. Если архитектура правильная и есть спрос на такой софт, можно десятками лет развивать, эволюционно. Первый релиз Linux 1991. Windows NT 1993. Exel 1985 и т.д. и т.п.

Відповісти

Підтримати

Андрей Волков

Андрей Волков 18.05.2024 00:43

Я думаю что сейчас там ни одного байта от тех версий и не осталось.

Відповісти

Підтримати

Vic

Vic Programmer 18.05.2024 02:21

В Linux можно посмотреть, по идее код Торвальдса ще есть кое где. В целом же это не имеет принципиального значения, концептуально это все ещё тот же самый продукт который развивался эволюционно. Ексель как был табличным процессором 38 лет назад, так им и остаётся. Действительно скажем в гейм индустрии французкий подход, когда каждая новая версия создаётся с нуля существует. Только адепты французского подхода, вроде Ромеро и Карлмарка — работают в других местах, а их компания была поглащена Bethesda softworks. Тогда как скажем Valve, которая пошла по пути эволюционного развития технологии по прежнему принадлежит Гейбу Ньюелу.

Відповісти

Підтримати

Андрей Волков

Dmytro Kopaev Dev в ClassOwl 18.05.2024 19:57

так щоб прямо з тих — може й ні.
але здається ще в 10 вінді був діалог встановлення шрифтів з 95 вінди.
я ще приблизно з XP переходячи на нову вінду через кожні пару років перевіряв, чи вони проапгрейдили той діалог.

fontview.exe досі виглядає трохи старувато,
Вірустотал каже, що аппка таки старенька — www.virustotal.com/...0e70d85be962a104c/details
Creation Time 2007-10-29 14:24:31 UTC

Відповісти

Підтримати

Андрей Волков

Beaver Green 18.05.2024 18:09

Може бути. Питання тільки у тому — скільки коштів буде коштувати новий і скільки коштів ти витратиш за 4-5 років на залатування.
Це як вічна дилема: купити нове авто, обслуговуватись по гарантії і не відкривати капота — чи перед кожною поїздкою лежати під старим авто.

Відповісти

Підтримати

Андрей Волков

Vic Programmer 17.05.2024 21:20

Як там у Де Марко «Не можливо завершити проект який і без того відстає від графіку швидше , якщо додавати в нього усе більше і більше роботи».
В цілому в ІТ управлінні давно вироблені методи, ще в минулому сторіччі.
У випадках коли проект відстає від графіку — робиться виставлення усім завершеним задачам пріоритетів. Наприклад за моделями Moskow чи Kano. Таким чином робиться в ті строки які є тільки ті фітчі які є принципово необхідними для програмного продукту, усі хотілки-свістілки чи невідомо навіщо потрібний функціонал за борт.
Тим не меньше більшість менеджерів зробить наступне — прибере найдорожчих членів команди типу техлідів, сініорів і т.п. і візьме за гроші які з цього залишились, вдвічі більше новачків.
Судячи з усього хтось направлено вчить, що не існує закона Брукса і Bus Factor-а. Але таким чином можна непогано заробляти аутстафінгом. Так джуніора фіг продаси, а так можна великий натовп народу :)

Відповісти

Підтримати

Ігор Ковальчук 14.05.2024 13:14

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

Відповісти

Підтримати

Ігор Ковальчук 14.05.2024 14:09

і як тут пишуть:

головне спочатку зрозуміти де хочеш опинитись

... на це потрібен час (іноді, не обов’язково робочий, бо непогані рішення приходять з часом, якщо не тиснути).

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

Відповісти

Підтримати

Ігор Ковальчук

Mykyta Loginov Unity developer 14.05.2024 13:11

рев’ю архітектури -> повільний рефактор + тести. головне спочатку зрозуміти де хочеш опинитись, що не працює як задумано, куди і нашо напхали костилів і як робити без костилів. переписування з нуля не розібравшись в тому що є це стрибання по тих самих граблях по яких стрибала попередня команда(и) але енергічніше

Відповісти

Підтримати

Dmytro Kopaev Dev в ClassOwl 13.05.2024 23:04

З досвіду:
— почали проект на самописному фреймворку, майже рік писали в 1-2-3 девелопера,
— менеджмент з другим девелопером вирішили, що треба все переробити на мікросервіси, ларавел, ангуляр і т. п.
— другий девелопер почав займатись v2, а я продовжив пиляти v1
— ще через рік проїли всі інвестиції, v2 на той момент виглядав як прототип декількох базових функцій (але на мікросервісах!), а v1 вже був більш-менш придатним до використання.
— розробку v2 зупинили повністю.
— ще через деякий час знайшли першого клієнта на v1, по реквестам якого почало приходити розуміння, що дійсно потрібно робити, а що було зроблено марно.
— з паузами у девелопменті доробляли реквести від першого клієнта для v1
— рік тому знайшли другого клієнта на v1 — появилось краще розуміння по архітектурі.
— v1 я зміг адаптувати під нові вимоги за пару днів, а от з запроектованим колись v2 я не впевнений, що так би просто все вийшло.
— знайшли третього клієнта на v1

Відповісти

Підтримати

Vic Programmer 19.05.2024 10:32

Ми так якось в чотирьох поїхали в Ліверпуль, якраз сапортити минулу версію одного дуже відомого англійського сайту. Паралельно також одна дуже відома всесвітньо компанія, власне це були IBM, це якраз та де Фредерік Брукс та інші і з якої іде увесь науковий підхід до ІТ менеджменту, але загралась в політику і там тепер самі індуси на аутсорсінгу. От та компанія робила реплатформінг — тобто переписували усе в нуль. Так нас покликали робити супорт, бо у тому моменту відомий вендора профакапив дедлайн вже на 6 місяців. Через два роки нас на це замовлення вже працювало 22. Хоча скажу в політику IBM вміє чудово — знайшли як на нас надавити із середини :) Щоправда їх реплатформінг закрили і почали вже робити інший під архітектуру Amazon AWS, під що клієнт зібрав власну команду в Англії. А CTO призначили якраз нашого техліда, що нас курував з Ліверпуля.

Відповісти

Підтримати

Dmytro Kopaev

Кирил Стронько Senior Frontend Engineer в AgileEngine 13.05.2024 19:14

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

Відповісти

Підтримати

Volodya Yanush 13.05.2024 18:59

Іноді отримую якусь фічу, якій 15 рочків і тиждень в ній розбираюсь, а потім виясняється, що фіча, наприклад, запечена в темплейти і не підтримує динамічного розширення через конфіги чи ще щось. І приходиться вигадувати велосипеди, щоб не переписувати з нуля. В сумі виходить купа витраченого часу на рішення, яке не системне і не покриває всі вимоги. Що призводить до ще більшої кількості затичок/костилів.

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

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

Відповісти

Підтримати

Ювженко Денис System Architect в Intellias 13.05.2024 17:53

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

Може бути реліз нової версії, де один із модулів буде переписано, але це також рідкість. Рівень ентропії завжди росте.

Хоча може бути умовне «переписування», коли якусь існуючу не-клауд систему переміщують в клауд.
Але час такого майже минув бо все існуюче відразу роблять клауд-нейтів, а все старе, що працювало і що вартувало переносити, вже перенесли.

Хоча з іншого боку, можливо, скоро знадобитись знову все переписувати на AI-native підхід і тоді знову постане питання переробки старого легасі на нове легасі.

Відповісти

Підтримати

Сергій Цимбалюк 13.05.2024 19:43

Переписування з нуля існує лише для стартапів

Ні. Воно існує всюди.

Відповісти

Підтримати

Ювженко Денис

Сергій Цимбалюк 13.05.2024 19:44

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

Буває.

Відповісти

Підтримати

Ювженко Денис

Сергій Цимбалюк 13.05.2024 19:46

скоро знадобитись знову все переписувати на AI-native підхід

Ні, не скоро.

Відповісти

Підтримати

Ювженко Денис

Alex Fogol Software Developer, C/C++ Expert 14.05.2024 14:59

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

на виході на справді те саме тільки «в масштабі» )) я перевіряв і наразі випрацював навіть перевірку куди це саме мене зовуть «будєш нашим каральом» (к) (тм)

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

на мою думку там більш звичайна ситуація з купівлею того самого стартапу з п.п. 1 тіко можливо навіть вже на стадії 2 (читай вже 2-й раз «переписано з нуля») і далі вже багато залежить від певно від тої частини де «в чистому вигляді» тож у цьому місці корпорація зазвичай має більшу ширину і для «умовного програміста» цілком є можливості знайти «досить вузьку частину проекту загалом» яка таки справді буде «переписано з нуля»

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

і тоді знову постане питання переробки старого легасі на нове легасі.

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

Переписування з нуля існує лише для стартапів, коли зліпили MVP, воно завелось, залучило інвестиції і є гроші на побудову чогось, що буде працювати

тож як на мене у корпорації тут якраз радше не рідкість

Може бути реліз нової версії, де один із модулів буде переписано, але це також рідкість.

а все старе, що працювало і що вартувало переносити, вже перенесли.

ги ги а ну ок ))

Відповісти

Підтримати

Ювженко Денис

Konstantin Strukov 17.05.2024 23:49

Переписування з нуля існує лише для стартапів, коли зліпили MVP, воно завелось, залучило інвестиції і є гроші на побудову чогось, що буде працювати і приносити подальші інвестиції

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

Відповісти

Підтримати

Ювженко Денис

Beaver Green 13.05.2024 17:30

Саме цю тему я піднімав у статті 2015 року — тут і про стратегії і про переписати з нуля:
«Старый ящик — новый ящик, белый ящик — черный ящик. Теорвер или эзотерика?»
dou.ua/forums/topic/15512

Вопросы к тем, кто сталкивался с подобным «старым ящиком»:
— Какую стратегию выбирали?
— Чье это было решение: команды, менеджера, клиента?
— Делали ли ставку на удачу: поковыряем — и вдруг сразу заведется?
— Или ныряли в пучины спагетти-кода?
— А может втихаря делали новую версию «с нуля» что бы потом удивить клиента?
— Какая текучка кадров при разной стратегии: сколько спивается от бесполезных попыток или сходит с ума от дебага кода?

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

P.S. Бобер зараз — ІТ пенсіонер. Отже готовий поділитись досвідом нахаляву. За 20+ років на галерах багато усього бачив — може щось корисне підкажу. Звертайтесь.

Відповісти

Підтримати

Alex Fogol Software Developer, C/C++ Expert 14.05.2024 15:01

може щось корисне підкажу. Звертайтесь.

давай одразу шоткат на

зараз — ІТ пенсіонер.

(для другов спрашиваю)

Відповісти

Підтримати

Beaver Green

Beaver Green 18.05.2024 18:17

Не зрозумів питання. Шоткат як бути ІТ пенсіонером? Ну якось так (хоча моя історія — не кращій зразок):
dou.ua/...rums/topic/48676/#2822478

Відповісти

Підтримати

Alex Fogol

Evgeny Sergeev 13.05.2024 17:29

В залежності за чий рахунок ’банкет’. Якщо все дуже сумно — біжить

Відповісти

Підтримати

Artem Konukhov PHP Developer 13.05.2024 17:00

Чи варто лікувати пацієнта з великою купою хвороб, чи узяти наступного в черзі?)

Відповісти

Підтримати

Sergey Lysak T/T Lead 13.05.2024 16:53

На переписування з нуля чужого проєкту зазвичай не буде ані часу(=грошей) ані експертизи.
А у традиції «аджайл» ще й не буде аналізу і проєктування.

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

Відповісти

Підтримати

Tim Cock 13.05.2024 16:45

За досвідом — друга (переписана) ітерація буде ще гірша за першу. А особливо якщо змінились люди в команді — то точно так і буде

Відповісти

Підтримати

Александр Енотов 13.05.2024 16:35

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

Відповісти

Підтримати

Alexandr Depeshko 13.05.2024 16:26

Вітаю, ти пізнав дзен нашої професії)

Відповісти

Підтримати

Anton Shkurenko Хєр з гори 13.05.2024 16:09

Майже завжди повільний рефактор працює. Переписувати все з нуля це ніколи не закінчується добре

Відповісти

Підтримати

Дмитро Дем'яненко BA/UX 14.05.2024 12:54

будь яка справа починається з нуля ))
навіть пишуть про «спочатку було ні***я, а потім...»

Відповісти

Підтримати

Anton Shkurenko

Alex Fogol Software Developer, C/C++ Expert 14.05.2024 15:02

Майже завжди повільний рефактор працює.

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

Відповісти

Підтримати

Anton Shkurenko

Продовжувати роботу чи написати код з нуля: що робити з проєктом, у якому повний безлад?

34 коментарі

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