Вхід і реєстрація
Про роботу · 15 лютого 2024, 14:27 2813
DOU Community

Резервне копіювання даних, Legacy code і рефакторинг. А які таски дратують вас?

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

Що це за задачі та з чим вони пов’язані? Може, це робота з неефективним фрейворком, що вимагає багато складного коду або шаблонів? Необхідність підтримувати чийсь таємничий код без документації? А може це задовге тестування або ж... міти (так, ті самі, які можна замінити кількома повідомленнями).

Пишіть у коментарях, які рутинні таски дратують вас?

Теми: кар’єра, менеджмент, робота
👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Alexander M 22.02.2024 22:38

Ті задачі, які треба на позавчора, або які прилітають посеред поточних задач і їм ставлять вище пріоритет.

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

Відповісти
Підтримати
Евгений Мележик Software developer 22.02.2024 19:56

Дратують в основному таски з іпанутим естімейтом. Майже все інше — норм.

Відповісти
Підтримати
Oleksandr zd Frontend developer в Freelancer 21.02.2024 14:13

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

Відповісти
Підтримати
amigo 21.02.2024 14:28
І коли саме змушують робити рефакторинг

А хто змушує? Що це за ситуація

Відповісти
Підтримати
Oleksandr zd
Oleksandr zd Frontend developer в Freelancer 21.02.2024 14:45

було діло на одному з проектів. А потім після 2 місяців рефакторингу все зупинили і почали писати з нуля))

Відповісти
Підтримати
amigo
Olena Sharovar Senior Software Engineer (Billing) in a startup 21.02.2024 14:34

Я не розумію. Рефакторинг — це зміна коду (може бути навіть повна зміна) без зміни його поведінки. Повне переписування — це теж зміна коду без зміни його поведінки. В чому різниця?

Відповісти
Підтримати
Oleksandr zd
Oleksandr zd Frontend developer в Freelancer 21.02.2024 14:46

ну манагери люблять це магічне слово рефакторинг

Відповісти
Підтримати
Olena Sharovar
Taras Terletsky Python Backend Engineer в SoftServe 21.02.2024 17:42

При рефакторингу ви працюєте з наявним кодом. При переписуванні все викидається і пишеться з чистого листка.

Відповісти
Підтримати
Olena Sharovar
Melnyczenko Mel 21.02.2024 14:52
хоча по факту написати з нуля буде в 5 разів швидше

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

Якісний рефакторинг > переписування з нуля. Але я кажу про якісний, а не «вирівняти форматування, переназвати декілька класів, винести купку функцій в один helper-клас»

Відповісти
Підтримати
Oleksandr zd
Alexander M 22.02.2024 22:43

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

Відповісти
Підтримати
Melnyczenko Mel
Melnyczenko Mel 21.02.2024 11:50

Завжди казав і кажу, найгірші таски — це таски звʼязані з роботою з часом. Часові пояси, високосні роки, різниця в одну секунду, купа різних форматів mm/dd/yyyy чи dd/mm/yy ітд — це тааака задроч завжди. Десь та про*бешся.

Відповісти
Підтримати
Beaver Green 22.02.2024 20:00

Забув додати магічне слово Javascript. В усіх нормальних мовах програмування більшість проблем з часом вже вирішена.

Відповісти
Підтримати
Melnyczenko Mel
Dmytro Lapshyn Solution Architect 23.02.2024 12:45

Для JavaScript вже купа років як існують нормальні ліби, які всі ці задачі теж вирішують.

Відповісти
Підтримати
Beaver Green
Dmitry 20.02.2024 09:08

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

Відповісти
Підтримати
Степан Ткаченко 17.02.2024 22:21

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

Відповісти
Підтримати
Olena Sharovar Senior Software Engineer (Billing) in a startup 18.02.2024 16:44

А чому не взяти і не прояснити вимоги одразу, з тим хто вам їх дає? в таску разом пишете acceptance criteria та definition of done, щоб всим було ясно і всі однаково розуміли що очікується на виході

Відповісти
Підтримати
Степан Ткаченко
Александр Енотов 19.02.2024 16:59

Очевидно: те, кто ставит задачи, сами не знают, как оно должно работать

Відповісти
Підтримати
Olena Sharovar
Sergey Lysak T/T Lead 19.02.2024 19:37

Тому що «аджайл» забороняє — керування вимогами; та моделювання, проектування домену.

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

Ну і документацію — ніхто ж не любить писати, чи не так?

Хоча, як на мене, йде до моєї старої мрії, завдяки ШІ — документація, специфікації, будуть такою же невід’ємною частиною програмування як і код. Бо все більшу частину коду буде писати ШІ. По — документації, спекам, діаграмам. А без документування, проектування — і програміст не те пише.

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Senior Software Engineer (Billing) in a startup 20.02.2024 02:20

Ну от ми плануємо спринт — поки не вияснили, що треба видати в кінці, задача не попадає в спринт. Якщо неясно що конкретно треба — мучаєш замовника на мітингу, випитуєш у нього деталі до тих пір, поки не буде згода. Єдині винятки, це коли задача — research. Але і там можна домовитися про те, що вважати «досягненням результату». Як могла в роботу взятися задача, де неясні кінцеві результати та критерії «done»?

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 20.02.2024 17:39

Толкова у вас компанія. Поетапні проектуваня і здача робіт відомі як ітеративна розробка, наприклад у RUP

Як могла в роботу взятися задача, де неясні кінцеві результати та критерії «done»?

Та дуже просто — «Кнопка Х повинна княпатись» от і весь done

Відповісти
Підтримати
Olena Sharovar
Полуарлекин Полумонах 22.02.2024 16:42
acceptance criteria та definition of done, щоб всим було ясно і всі однаково розуміли що очікується на виході

реальный случай чуть менее чем годичной давности:
кастомер излагает таски предельно кратко, в одну-две фразы. на уточняющие вопросы отвечает уклончиво.
ну мы соответственно достаем из широких штанин неубиваемый как нам казалось аргумент: сформулируйте в таске аксептанс критерии, дефинишен оф дан и вот это вот всё. оукей говорит кастомер, сейчас изобразим, итак:
acceptance criteria: код соответствует реквайрементам
definition of done: код и документация проревьювлены и запушены в Геррит
...стук падающего тела, занавес

Відповісти
Підтримати
Olena Sharovar
Sergey Lysak T/T Lead 22.02.2024 16:57
кастомер излагает таски предельно кратко

В основном так и есть. Как я резюмирую эту типичную картину:
хотелка бизнеса
1 строка
бизнес анализ этой хотелки
10 строк
ТЗ, спека
100 строк
Код реализации
1000 строк

...стук падающего тела, занавес

Если на этапе формирования требований к продукту ошибку в требованиях можно предотвратить и доработать за пару часов, то исправление во время разработки уже будет стоить примерно 10 часов. Если проморгать проблему и код ушел на тестирование, то ее исправление может затянуть на 20-50 часов, а если ошибка уехала в релиз, то и вовсе до сотен часов!
(см слайд 2 slideplayer.com/slide/16557549 он от Barry Boehm из его Software Engineering Economics)

И становится реальною черный юмор проектного менеджмента:
90% работы занимает 90% времени. А оставишиеся 10% занимают — еще 90% времени.

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

Как писал один:
Сбор требований это совсем не как по лесу гулять, грибы собирать.
Это ловля кастомера, помещение его в подвал и допрос с пристрастием.

Відповісти
Підтримати
Полуарлекин Полумонах
Olena Sharovar Senior Software Engineer (Billing) in a startup 17.02.2024 19:27

Мене підбішує писати тонни документації. Я розумію що треба, пишу, але це підбішує. Два рази вже було, що 2 місяці підряд я 80% робочого часу пишу документацію. Ще 20% то стендап та мітинги. Перший раз я то робила в 2021 коли чатжпт не було, зараз хоча б йому можна делегувати частково, це спасіння.

Відповісти
Підтримати
Oleg Androshchuk Java developer в Amazon 17.02.2024 19:45

Взагалі то це нормально. 20% код, далі дока і тести. Для продукту, що має зовнішніх користувачів

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Senior Software Engineer (Billing) in a startup 17.02.2024 20:28

Мене просто не заводить така робота 😂 писати мануали. Там багато майже нікому не потрібної єрунди доводиться писати. Наприклад, короткий мануал «як зібрати дитину в садік» виглядає так — «розбуди, покорми, вмий, вдінь, веди в сад». Ясно-понятно, хто не дурний — розбереться.

Детальний мануал «як зібрати дитину зранку в сад» буде налічувати 10 сторінок тексту, якщо там описувати все покроково та з різними edge cases та форс-мажорами які можуть трапитись. Взагалі не весело то писати. Особливо 2 місяці підряд писати подібне.

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

Відповісти
Підтримати
Oleg Androshchuk
Beaver Green 19.02.2024 14:00
Детальний мануал «як зібрати дитину зранку в сад» буде налічувати 10 сторінок тексту, якщо там описувати все покроково та з різними edge cases та форс-мажорами які можуть трапитись. Взагалі не весело то писати.

Уявіть що це ваша менша дитина і вам треба написати цю інструкцію для 15-річного сина, який має усе робити поки вас не буде вдома. Якщо він до цього ніколи не робив хатні справи — наскільки детальну інструкцію ви йому залишите?
Нагадую, що такий улюблений зараз аджайл передбачає що кожен член команди може працювати з будь-якою частиною системи. Навіть якщо він у команді один тиждень, а цю частину бачить уперше. Також підтримка легасі ентерпрайза припускає що більшість девелоперів не витримають на такому проєкті багато років. Отже автора (а інколи і замовника) функціоналу у багатьох випадках годі і шукати.
Детальна документація — це єдине що рятує багаторічні ентерпрайз проєкти від перетворення на повний хаос.

Відповісти
Підтримати
Olena Sharovar
Kai Owas 17.02.2024 18:23

Єдине що дуже дратує — невгамовне намагання клієнтів «автоматизувати хаос».
Усе інше — дрібниці

Відповісти
Підтримати
Emma Orlova SDE 16.02.2024 12:09

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

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

Відповісти
Підтримати
Serge Loboda Senior Software Developer в Access Softek, Inc. 16.02.2024 12:00

Коли «зроби то, невідомо що». Бажано ще при цьому 100500 мітингів, погоджень і доповідей про естимейти вгору.
Он там колега нижче десь про те саме пише.

Відповісти
Підтримати
Ювженко Денис System Architect в Intellias 15.02.2024 19:45

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

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

Відповісти
Підтримати
Oleg Androshchuk Java developer в Amazon 17.02.2024 19:51

Для цього є правило 30 хвилин. Якщо за цей час Вам не зрозуміло як виконати таск, то ймовірність процентів 90+, що ви цей таск, в цій постановці завдання не виконаєте взагалі. Треба ескалювати питання і отримати уточнення, роз’яснення, консультації

Відповісти
Підтримати
Ювженко Денис
Ювженко Денис System Architect в Intellias 18.02.2024 11:16

Ну це релевантно для невеликих тасок)
Бо іноді для того аби зрозуміти, треба прочитати 10 документів і поговорити із 5 людьми.
Іноді з людьми, які працюють в різних компаніях і в різних часових зонах)

Відповісти
Підтримати
Oleg Androshchuk
Oleg Androshchuk Java developer в Amazon 18.02.2024 15:24

То вже цілий епік, а не таска :)

Відповісти
Підтримати
Ювженко Денис
Beaver Green 19.02.2024 14:05
Треба ескалювати питання і отримати уточнення, роз’яснення, консультації

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

Відповісти
Підтримати
Oleg Androshchuk
Dmytro Lapshyn Solution Architect 21.02.2024 17:12
він очікувано скаже: ви ж спеціалісти — маєте знати як робити чат-боти.

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

Відповісти
Підтримати
Beaver Green
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 21.02.2024 23:02
Ну на це є чудова відповідь:

... щоб клієнт просто пішов до іншої компанії.

нам треба зрозуміти бізнес-проблему, яку цей чат-бот буде вирішувати

Останнє що тут допоможе, це вимагати готовий

аналіз, як саме чат-боти покращують користувацький досвід на конкуруючих сайтах
Відповісти
Підтримати
Dmytro Lapshyn
Dmytro Lapshyn Solution Architect 23.02.2024 12:49
щоб клієнт просто пішов до іншої компанії.

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

Єдине що — ми не знаємо, які з тим клієнтом були домовленості щодо розподілу відповідальності стосовно бізнес-аналізу. Зазвичай таке прописують у work order / project charter чи як воно називається в різних компаніях.

Останнє що тут допоможе

Аргументуєте вашу думку, будь ласка?

Єдиний кейс, який я можу уявити, коли це не допоможе — це якщо компанія на початку співпраці наобіцяла з три короба щодо володіння «доменною експертизою». Але, тут вже як в старому жарті про двох ворів: «За язика тебе ніхто не тягнув, а за базар відповіси».

Відповісти
Підтримати
Oleksandr Bereziuk
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 23.02.2024 22:57
якщо компанія на початку співпраці наобіцяла з три короба щодо володіння «доменною експертизою».

:)) Пан володіє питанням.
Так, це воно — і якщо компанія А не готова, клієнт посто піде до компанії B, яка пообіцяє це володіння. І так, цілком можливо що далі проект з компанією B закінчиться фейлом — але для компанії А нічого, окрім морального задоволення це вже не принесе — гроші вже пройшли мимо.

які з тим клієнтом були домовленості щодо розподілу відповідальності стосовно бізнес-аналізу

Що це таке? У нас еджайл в усі поля, так що вперед, MVP через два місяці, PI-планінг завтра та юзер сторі самі себе не створять )

Відповісти
Підтримати
Dmytro Lapshyn
Beaver Green 22.02.2024 20:09

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

Відповісти
Підтримати
Dmytro Lapshyn
Dmytro Lapshyn Solution Architect 23.02.2024 13:01
Якби клієнти вміли хоч думати (не те, що аналізувати) — вони не приходили би до галер щоб їх розводили як лохів.

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

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

Ну нащо перекручувати? Звісно, що в цій уявній ситуації продавець-консультант спитає щось накшталт «А ваш онук буде переважно грати в ігри або використовувати компʼютер для навчання?». Але — в тому і справа, що це продавець, в нього робота така.

Але в аутсорсі є різні варіанти взаємодії команди із замовником. Якщо згідно договору в команді немає ролі BA, то якось дивно очікувати, що команда відповідальна за аналіз бізнес-кейсів використання чат-ботів на сайті. Це вже скоріше питання до етапу pre-sales, на якому було б бажано зрозуміти, наскільки замовник сам в змозі адекватно формулювати бізнес-вимоги, або йому дійсно потрібна «няня» у вигляді BA / proxy product owner / you name it.

Відповісти
Підтримати
Beaver Green
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 23.02.2024 23:03
Звісно, що в цій уявній ситуації продавець-консультант спитає щось накшталт «А ваш онук буде переважно грати в ігри або використовувати компʼютер для навчання?».

І отримає відповідь — «ну він студент першого курсу. Ще іноді бачила що чорти якісь по екрану бігають на його старому комп’ютері»

Відповісти
Підтримати
Dmytro Lapshyn
Мамка Жука 15.02.2024 19:28
рефакторинг.

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

Відповісти
Підтримати
Олександр Мощенко 15.02.2024 19:33

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

Відповісти
Підтримати
Мамка Жука
Serg Vasylchenko 18.02.2024 18:06

Рефакторинг не имеет срока. Рефакторинг идет по полного удовлетворения. Иначе нет смысла и начинать. Ну и без покрытия тестами рефакторить запрещено.

Відповісти
Підтримати
Мамка Жука
Mykola Gatilov Senior DevOps 15.02.2024 19:20

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

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

Відповісти
Підтримати
Oleg Androshchuk Java developer в Amazon 17.02.2024 19:53

Як правило, на рефакторінг є 0% часу

Відповісти
Підтримати
Mykola Gatilov
Mykola Gatilov Senior DevOps 17.02.2024 21:59

Так тоді бісить не рефакторінг, а відсутність на нього часу ;)

Відповісти
Підтримати
Oleg Androshchuk
Yegor Chumakov founder в startup 15.02.2024 19:17
Резервне копіювання даних, Legacy code і рефакторинг

Обожаю такое. Расслабон же)

Відповісти
Підтримати
cheryman 15.02.2024 18:05

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

Відповісти
Підтримати
Eugene Fomenko 15.02.2024 19:17

только так и стают не джунами

Відповісти
Підтримати
cheryman
Karina Kosenko PHP developer в IT Craft 15.02.2024 17:31

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

Відповісти
Підтримати
Nikita Galkin GDE, Fractional CTO/Principal Engineer, Node.js Tech Speaker 15.02.2024 16:55

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

Відповісти
Підтримати
Beaver Green 15.02.2024 16:23

Особисто мене завжди дратувало коли клієнти твердо переконані що дешевше відремонтувати щось старе, ніж купити нове! І переконати такого клієнта майже неможливо.
Йому розповідаєш про прогрес, про масове виробництво що купивши зараз щось за умовні 1000 баксів — він отримає нову річ з гарантією, яка працює швидше ще й з новим функціоналом. А заплативши умовні 800 баксів — він отримає стару, ледь-працюючу річ у який через місяць ще щось відвалиться і знову треба буде платити — або цього разу вже викинути і таки купити нове.
І лох кожен раз обирає старе! Він платить за ремонт знову і знову — і це тільки переконує його що не можна викидати річ, на яку вже витратив умовні 10 000 баксів, хоча навіть кращу нову так само можна придбати за 1000.
Допомагає тільки «заміна клієнта» — як тільки закінчуються гроші і його бізнес купує хтось інший. Він передивляється активи, бачить стару річ, на ремонт якої витрачають купу бабок щомісяця — викидує (або продає!) її, купує нову — і записує собі значну оптимізацію витрат.
Ще більшим бовдуром виходить той, хто купив цю стару херню — тому що продавали дуже дешево і вона ж ніби працює! І через місяць настає його черга бути лохом — і платити за ремонт.
В ІТ усяке таке легасі як правило віддають на атусорс — отже галери старанно розводять лохов і обслуговують їх «мертвих конячек».
Я колись майже дахом не поїхав на такому проєкті — і написав про це статтю:
Старый ящик — новый ящик, белый ящик — черный ящик. Теорвер или эзотерика?
dou.ua/forums/topic/15512

Відповісти
Підтримати
Мамка Жука 15.02.2024 16:26
Я колись майже дахом не поїхав на такому проєкті — і написав про це статтю:

Статью не читал, но для меня это работа мечты.

Відповісти
Підтримати
Beaver Green
Олександр Мощенко 15.02.2024 16:49

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

Відповісти
Підтримати
Beaver Green
Beaver Green 15.02.2024 17:24
А з кодом геть все навпаки. «нове» буде коштувати в рази/на порядки дорожче, в рази/на порядки довше писатиметься і суттєво збільшить ризики втратити щось з даних в процесі міграції і щось з функціоналу через не до кінця формалізоване ТЗ.

Це теж аргумент, який мене подобається «раптом ми втратимо якийсь важливий функціонал». А коли питаєш який саме — ну так відразу не скажеш, але «важливий». Аргумент що у новій системі ви вже отримаєте сучасний вигляд і зможете легко додати фічі, які вже є у конкурентів — не діє. Забутий усіма старий функціонал — важливіше!
І можна було б виправдати бажання триматися за старе, якщо воно працює. Але — насправді ж його ремонт та підтримка постійно коштує грошей! Якщо скласти ці гроші за декілька років — то вистачило б на нове. А по-факту клієнт залишиться без нової системи, без грошей на неї, і з ще більш застарілою старою.
Тобто гроші потрачене на нове — це інвестиції в майбутнє, гроші потрачене на старе — просто закопані у землю.
Скільки ви бачили таких автолюбителів, які на постійний ремонт старих Жигулів витратили за декілька років стільки грошей, що вистачило б на б\у іномарку. А якщо порахувати ще й витрачений час і уявити що людина могла б цей час працювати в автосервісі за зарплату — то може вистачило б і на майже нову «лялечку».
Як каже прислів’я «скупий платить двічі»... ну а лох платить постійно!

Відповісти
Підтримати
Олександр Мощенко
Юра 15.02.2024 17:53
аргумент, який мене подобається «раптом ми втратимо якийсь важливий функціонал». А коли питаєш який саме — ну так відразу не скажеш, але «важливий».

зазвичай на нове треба більше грошей витягти з обороту.........
це і є втрачений функціонал...

знайомий кілька років тому назбирав грошей... на хорошу річ..., купив джип... здається, міцубісі паджеро спорт, за 600 тис. грн.
покатався по селу пару місяців... незручно... пальне, запчастини дорого...
продав джип, десь знайшов в інтернеті в іншій області за 500 км майже нову четвірку за 35 тисяч... вже кілька років на ній катається... дешево і сердито )

Відповісти
Підтримати
Beaver Green
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 15.02.2024 19:20
А коли питаєш який саме — ну так відразу не скажеш, але «важливий».

Якщо це дійсно велика core система, то там тільки епиків може бути імплементовано кілька десятків, не кажучи про literally сотні фіч. Так що так — на це запитання досить складно відповісти з голови.

ви вже отримаєте сучасний вигляд

Це передостаннє, що бентежить бізнес-користувачів — чи будуть вони вводити якийсь там номер договору у няшний modern-style-JS-framework-powered скрін або в old good JSP/ASP

Відповісти
Підтримати
Beaver Green
Олександр Мощенко 15.02.2024 19:26
А коли питаєш який саме

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

Відповісти
Підтримати
Beaver Green

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.