Резервне копіювання даних, 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

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

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

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

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

І коли саме змушують робити рефакторинг

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

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

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

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

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

хоча по факту написати з нуля буде в 5 разів швидше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Треба ескалювати питання і отримати уточнення, роз’яснення, консультації

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

він очікувано скаже: ви ж спеціалісти — маєте знати як робити чат-боти.

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

Ну на це є чудова відповідь:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Якби клієнти вміли хоч думати (не те, що аналізувати) — вони не приходили би до галер щоб їх розводили як лохів.

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

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

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

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

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

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

рефакторинг.

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

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

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

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

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

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

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

Резервне копіювання даних, Legacy code і рефакторинг

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

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

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

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

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

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

Я колись майже дахом не поїхав на такому проєкті — і написав про це статтю:

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

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

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

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

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

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

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

А коли питаєш який саме — ну так відразу не скажеш, але «важливий».

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

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

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

А коли питаєш який саме

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

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