А яке ваше ставлення до legacy? Обговорюємо!

Спільното, а ви мали досвід з legacy-проєктами? Яке ваше ставлення до цього явища: для вас це про користь чи про купу мороки?

Чи залежить ваше ставлення від того, з яким проєктом ви працюєте: передрелізним чи пострелізним?

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному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

Коли я перероблював оцей AUTOMAX на AllenBradley на одному феросплавному заводі в Штатах, він усе ще чудово виконував свої функції чи не 60 років поспіль. Оце “легасі” ))
lh3.googleusercontent.com/...​fXAh9IWw6=w800-no-tmp.jpg
lh3.googleusercontent.com/...​gHCvYSoFb=w800-no-tmp.jpg
lh3.googleusercontent.com/...​xbsYr2s0-=w800-no-tmp.jpg

Був випадок коли йшов на інтерв’ю на актуальний стек, а згодом. Виявляється що це ’ .... буде після x місяців а зараз необхідно підтримувати стару версію котрій ~10 років’

Якщо при цьому є виділення 10-20-30% часу (в залежности від локального рельєфу) на удосконалення/усучаснення/оновлення бази (і коду, і всього навкруги) і адекватне керівництво, що це дозволяє — ок.
Якщо ні — «БЕГN» (tm).
А тема майже та ж що з технічним боргом, тому моя відповідь там актуальна і тут.

PS: Випадки повністю старого стеку вимагають окремого обговорення.

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

Вивчиті нові технології не проблема взагалі, накидав базвордів у резюме, полистав туторіали та поговорив з чатЖПТ, хеллоу(чи Геллоу зараз вірно писати) ворлд, пара трійка невдалих співбесід і ок. Десь половни досвіду (це я мін 6 років) сидів на легасі, нічого не сталось, гребу далі, навіть тех лідом та архітектом останні роки 4.

Користь коли боїться
Але до першого лейофу
А потім якщо сидів на легасі і не вчився — вниз по дніпру

Насправді такого не буває, працюючи на проекті із «застарілими» технологіями ти якраз вчишся найголовнішому — підтримці, відповідно вчишся створювати або рефакторити існуючий код та відтворювати процесси з розробки які дозволяють усій команді його створювати. Умовно якщо ти писав на Angular.JS то перейти на Angular, React або Vue не така вже і складна задача. Нещодавно мені показував проект на Vue та Next.JS колега якому за 50, та він займався тим що би ми назвали legacy десь з 2016 року здебільшого на Java. Але компанію клієнта вороже поглинули конкуренти і проект закрили.
А от що справді йде мимо каси — це навички проходження інтервью, наймів і тому подібного. Тобто навички торгувати. За великим рахунком коли тобі 50 ти сам маєш винаймати на роботу, а ще точніше займатись кадровим резервом чи подібними технологіями типу PDP 360 і т.д. тощо та підвищенням людей до наймаючих менеджерів, а не тебе мають обирати проміж мідлів та джуніорів — писати код.
А це зовсім про інше — це про особисті стратегічні плани в житті, та навички ведення бізнесу.

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

Це як правило не про рекрутера. Ректрутер така сама наймана співробітник яка виконує наказ замовника, клієнта чи керівника. Наймаючи менеджери — хочуть одразу щоб робітник знався на технології і на проекті і т.д. і щоб йому/їй жодних ризиків, та бажано ніякої роботи, відпочивати собі по відпустках та на жовтих мустангах та якось розважатись з купою халявного бабла та соціальним статусом великого начальника. Коротше чистий Вовк з Уолстріт — наркота, шлендри та розваги.
Це якраз про рівень організацій і йдеться. По тих самих FAANG тому і перевіряють кандидатів на посади програмістів — не знання технологій, а на теоретичну підготовку зокрема комбінаторіку, дискретну математику та чисельні методи. Тобто фундаментальні знання. А коли відбирають менеджерів — дивляться на досвід створення власного бізнесу в першу чергу. Напевно друге не вірно, бо з рештою це погано скінчилось для : Стіва Джобса, Біла Гейтца, Ларі Пейджа та Сергія Бріна та низки інших. Коли відбираються амбітні люди — то вони приходять з ціллю зробити цей бізнес своїм замість вашого. Та і добрий бізнесмен — тобто торговець, зовсім не обов’язково має навички керування та організації робочого процесу. Як приклади — Скаллі та Балмер, які добре торгували але на цьому їх навички було вичерпано.
P.S. А взагалі коли людина на одному проекті 10+ років, то по суті їй нема чого заморочуватись відповідності потребам інтервьюверів. Робота та є — а подекуди платять не погано. Що правда — що станеться коли цієї роботи раптом не стане, тобі 55 але ти ніякий не C level директор ? Особиста криза гарантується, навіть як на рахунках грошей вже коли можна в принципі не працювати.

Нормального розробника передають по рекомендаціям без всяких тестів та лайвкодінгу. Це дуже показово во фріланс біржах де кількість зроблених проектів зменшує тестування до нуля. Тобто вміння в алгоритм Дейкстри не гарантує що задачи буде зроблено вчасно та якісно. Або креативно — де це потребує. Щодо амбіцій це дуже специфічна річ- знаю людей котрі з QA до VP топ. Компанії дійшли за 15-17рокв, також знаю розробників коли за 20 років Рівень мідл-сеньор (правда в дуже специфічному стеку) . Взагалі зараз типова стеля розробника в типової компанії це або архітектор або делівері менеджер. Або своя контора — це ’світить’ тільки для 3-5%

По рекомендаціям передають добрих бізнесменів, в першу чергу. Створення сталої клієнтської бази це з азбуки торгівлі. Я не кажу, що повністю згоден з методологію наймів з Долини. За великим рахунком алгоритми гугляться, а олімпіаді задачи це про не про креатив а про надрачуваня на типові задачі, ну тобто це усе при бажанні хакається. Джоел Спольскіту Верблюдах та пісочниці пропонував зовсім інший методи, бо пояснював як його дурили Індуси коли він відбирав на аутстафінг, обманюючи систему найму зазубрюючи вірні відповіді (я сам так робив неодноразово і вчив інших бо бізнес є бізнес).
2. Ми вже десь обговорювали і про неіснуючі тайтли, менеджерів з доставки — які напевно доставляють піцу і в кожній конторі це щось своє, зазвичай accounting тобто по суті бухгалтерія. Так само десь обговорювали чим відрізняється керівник від еталонної водо свинки — менеджеру з продажів, це право фінансового підпису. Це вічні теми.
Тут про інше — чим ви ризикуєте працюючи з технологіями які з якихось причин програють ринок, насправді ризикуєте ви здебільшого конкретним психічним зривом та й усе. На повірку то усе одне і те саме Algol 60, тільки в іншій упаковці. А ще клієнтами скаргами — дуже часто.
А не беруть на роботу часто — тому що вік і ейджизм, і це стосується далеко не єдиної професії. Такий світ він жорстокий. Тому тепла бульбашка довго проекту, коли ти ним не керуєш — погано закінчується в будь якому разі. Зазвичай розводиш руками «А як це так, із стільки років?». Та нічого особистого — лише бізнес.

А чому з легасі кодом важко працювати, його ж також писали професіонали?
Через 15 років теперішній код також стане легасі і з ним також буде важко працювати?

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

іноді на свій старий код дивишся і не можеш вкурити хід своїх думок рік тому

Чому це важко?
Треба тільки вкурити хід думок попередніх поколінь

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

То математичний код самодостатній.
А програмний — контекстно залежний :)

та проносити цю спадщину

Вона може бути як корисною, так і випадковою = фіговою.
І у другом випадку її треба не проносити, а рефакторити і викидати.
Бо, самі автори так планували зробити :) Потім, а зараз — ото скотчем якось скрутимо оці картонні коробки з смітника, тимчасово...

от і вкурюй хід думок попередніх поколінь...

Правильні запитання — частина відповіді!

А чому з легасі кодом важко працювати, його ж також писали професіонали?

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

Через 15 років теперішній код також стане легасі і з ним також буде важко працювати?

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

Через 15 років теперішній код також стане легасі

Я вже наводив купу прикладів, коли програмні продукти суттєво старші за 15 років. Ніхто при цьому не називає їх legacy тобто тими що дістались в спадок. Та от хоча би Exel створеного під керівництвом Джоела Спольски взяти в 1988 році — 36 років тому. Stack Overflow теж його робота. Рекомендую його книги uk.wikipedia.org/wiki/Джоел_Спольськи
Те що ви звете legacy, це швидше про стан ентропії коду, коли розробка зайшла в тупик та модернізація і підтримка стає вкрай складною. Тобто і вкрай важко фіксити баги, або додавати нові фітчі. А переніс та портування на іншу програмно-апаратну систему, навіть просто нову версію минулої системи типу новий iOS, Android, Windows чи Linux — стає величезним викликом.
Це вже про інше, це про архітектуру та дизайн системи. Більшість систем в ІТ індустрії створюється експериментальним шляхом, тобто без жодного проектування як такого. Щось випробовуєм — не працює вносимо корективи (фіксим баги, костиляймо і т.д.). Пробуємо знову і так по колу. З рештою код стає некерованим і «одним загальним багом».
І цим страждають усі в тому числі і я — бо в бізнесі тобі кажуть на позавчора, не зробиш — шукатимеш з рештою іншу роботу, навіть якщо ти в курсі, що так не правильно робити. Бо щоб робити правильно — треба бути керівником який має фінансовий підпис, тобто і приймає рішення.

Ніхто при цьому не називає їх legacy тобто тими що дістались в спадок. Та от хоча би Exel

Серйозно? А ви читали того ж Спольського про той жах що у Excel всередині?
Легасі як воно є.

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

І ентропія :)

В решті — згоден.

А ви читали того ж Спольського про той жах що у Excel всередині?

Насправді це не та проблема. Рефакторінг це звичана практика створення ПО, сьогодні жахливо — через 10 років не так вже і жахливо. В цілому Exel переписали повністю вже під Windows NT. А Word довелось переробляти майже одразу. Також проект потрапив і в строки і в бюджет, Word їх постійно провалював. Бо була документація.
Звісно Microsoft це зразок агресивного бізнесу, і стратегії клонування якої ніби як дотримуються лише китайці. Word — від початку клон Word Start, Excel від початку колон Lotus 1-2-3.
В коді DOS як відомо були фрагменти коду на асемблері які взагалі ніхто не знав як працюють, для цього довелось переманювати програміста який створив систстему собі в штат і т.д.
MS-DOS->QDOS якраз клон CP/M яку вимагав IBM для того щоб IBM PC мав головну фітчу «персонального комп’ютера для простих людей» яка до ери ігор і інтернет в першу чергу полягала в тому щоби бути просунутою друкарською машинкою з вбудованим калькулятором — геніальна ідея Возняка та Джобса. Електро-механічні та механічні друкарські машинки застаріли одним днем, будь який офіс негайно став потребувати комп’ютерів. Тому сама ідея була в тому щоб склонувати усі найкращі продукти які були ринку мікрокомп’ютерів.
Ентропію коду ви легко отримуєте на найновіших проектах, з супер-дупер новітніми технологіями типу Mega Super Turbo Rust for Flutter Reactive GPT +++ Знаєте чому ? Тому що це маркетингова назва чергового покращеного Algol 60 або COBOL. Та сама ідея Дейкстери як відомо потерпіла повний крах, от чітке пояснення як на мене youtu.be/LZflL44SVVY?t=1262.
Ця мега модна технологія, яку негайно треба вам продати, ніяк не додасть вам в команду наприклад сіньйорного бізнес анналіста та пару професійних тестувальника докупи до тих що є. І це ще добре, коли скажімо в команді менеджмент який щось вміє.
В 80% випадків у вас не процес — а банда щось там пилить, може вийде може ні. Невідтворюваний процес, на слензі «Ляп-Ляп і в продакшн» cf3.ppt-online.org/...​5A8V0BOELuyai/slide-5.jpg

Насправді це не та проблема. Рефакторінг це звичана практика створення ПО, сьогодні жахливо — через 10 років не так вже і жахливо.

Про «звичайну практику» ви розкажіть комусь хто не бачив, як це не робиться тому, що завжди погоня за фічами і навіть 5% на підтримку не дається ;\

А Word довелось переробляти майже одразу. Також проект потрапив і в строки і в бюджет, Word їх постійно провалював. Бо була документація.

Що? Наявність документації — причина поразки зі строками? Визнайте, що жартуєте.

яку вимагав IBM для того щоб IBM PC мав головну фітчу «персонального комп’ютера для простих людей» яка до ери ігор і інтернет в першу чергу полягала в тому щоби бути просунутою друкарською машинкою з вбудованим калькулятором — геніальна ідея Возняка та Джобса.

Не були Джобс і Возняк тут першими, не думайте. Возняк взагалі інженер і відомий тим, що умостив в маленькі ресурси досталь функціоналу — але всі його досягнення були технічні. А Джобс виїхав разом з Apple на тому, что Apple I продавався як готовий вироб, а не конструктор — ось саме це і було його головною ідеєю. Взагалі ж індустрія персональних компʼютерів — у вигляді саме конструкторів — уже була декілька років дуже розвинута.
«„„в квітні 1976 року Apple I був презентований в Клубі саморобних комп’ютерів в Пало-Альто, Каліфорнія.““» (вікі)
В клубі, Карл.

Початок 70тих був характерний тим, що прогрес, який призвів до персональних компʼютерів, йшов активно... в стані інших персональних компʼютерів(!): у вигляді їх дуже спеціалізованої групи — ігрових автоматів. Їх будували спочатку на розсипусі, а потім на маленьких процесорах, головним чином 4-бітних (як Intel 4004, але тоді було під десяток таких). Потім, з підйомом ресурсів десь в середині 70-х, стало можливо робити їх вже на рівні чогось з повною клавіатурою і екраном (хоча за дикі гроші, повний комплект збирався за 2-4 тис. $$, зараз треба помножити на 5 для еквівалента).

Читайте реальну історію, а не лайно від джобсоманів або будь-якої іншої категорії тих, хто побачив компʼютер вже в часи Pentium III.

Це вже не має відношення до головної теми, але... з таким відношенням до фактів складно повірити, що ви і все інше будете адекватно сприймати.

Ентропію коду ви легко отримуєте на найновіших проектах, з супер-дупер новітніми технологіями типу Mega Super Turbo Rust for Flutter Reactive GPT +++ Знаєте чому ? Тому що це маркетингова назва чергового покращеного Algol 60 або COBOL.

І ваше посилання не має ніякого відношення до питання. Наявність ресурсів, да, дає можливості не економити на деяких аспектах. Але і це було завжди. Ще з OS/360 відомо, наскільки слабкі, неефективні і несекьюрні були її перші версії — але не було альтернативи, і люди мусили платити. Рівень догонявся роками. А перший Unix? Його лаяли за неефективність аж до 90-х. Але зручність була важливішою.
Треба все розглядати в комплексі.

Три статї Джоела про архитектурних анстронавтів колись давно перевернули мій світ )) І шо саме кумедне — цих астронавтів тільки більшає. www.joelonsoftware.com підписаний вже років з 15-20

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

А чому з легасі кодом важко працювати, його ж також писали професіонали?

Саме тому і важко :(

Бо у 99% випадків — заплата на заплаті.

Ось наприклад sendmail. Досі в деяких BSD системах за замовчуванням. Гасло — «40 років без рефакторингу!» Код можна відправляти в хрестоматію.

Ось наприклад sendmail

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

Але зазвичай на старті більша частина функціоналу невідома нікому в світі. Потреба в ньому виникне в майбутньому.
Причому поступово. І вийде що з човника зробили самокат.

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

Інші ж види проєктування не взлетіли. З різних причин.

для вас це про користь чи про купу мороки

Польза от всего, за что платят.
За что не платят, за то не беремся

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

По-перше, потрібні додаткові зусилля, щоб розібратися в коді — будуть криваві і затяжні дебаг-сессії.

Отже девелоперам або треба добре доплачувати за такі легасі — проєкти, або шукати БДСМ девелоперів, які люблять страждання.

їм же вже платять ЗП. Додаткові зусилля — більше часу

Legacy — тобто наслідування від когось іншого програмного продукту, це абстрактне явище. Абсолютно новий код можна написати так, що краще би він був від когось наслідуванний.
Як відомо програмісти дуже часто ігнорують структурну якість коду і його ясність. Можна подивитись на код Лінуса Торвальдса навіть 30 річної давності на С і який небудь спагетті, без жодної документації на супер-дурер новий мові програмування типу Rust чи Kotlin.
Ви знайдете в усіх авторів в книгах за 50 років, що найбільша чеснота якісного дизайну коду — це його підтримування, тобто відносна простота додавання нових функцій, без того щоб переробляти для цього пів проекту.

P.S. Про добрі дизайни, які по суті купа народу відтворює на жаргоні роблять Fork.

  • Транслятори та компілятори — Джон Бекус, Пітер Наур та Дональда Кнут як ідеолог. Дизайни самих мов програмування, щоби мова не була занадто складною щоби програмісти могли розуміти написане щось кимось іншим, та відповідно працювати в команді та підтримувати кодову базу якнайдовше — Едсгер Де́йкстра та Ніклаус Вірт саме тому Algol 68, Ada або наприклад, Ruby це не найкращій дизайн. Описано наприклад в книзі дракона en.wikipedia.org/...​es,_Techniques,_and_Tools Книга має 6 редакцій
  • Операційні системи — Кен Томпсонон, Деннісом Рітчі та в цілому колектив Bell Labs(AT&T). Описано причудово — en.wikipedia.org/...​Design_and_Implementation Книга має 3 редакції. В редакції 2006 аспіранти детально розписали устрій Linux та Windows NT
  • Бази даних. Реляційна модель даних — Едгар Кодд. Описано дуже багато де і багато ким.Особисто мені подобається Томас Кайт. В цілому є 12 правил Кодда — uk.wikipedia.org/wiki/12_правил_Кодда,
    NoSQL: СAP моделі даних Ерік Брюер — описано теж багато де. Напевно фундаментального твору нема, за базу можна брати cloud.google.com/bigtable Це специфічний дизайн і його не можна давати в приклад як універсального. Так само як і графові (Neo4J, Amazon Neptune і подібне), або документ орієнтовні бази (MongoDB, CouchDB і т.п.)
Можна так піти і в наші улюблені AI де усі так чи інакше роблять Перцептрони Фрэнк Розенблатт (1957) з багаторівневими та backpropagation Пол Вербос та Александр Галушкін (1974) доповнення Румельхарт та Хинтон (1986) , CNN Ян Лекун (1988). І звісно фундаментально Джеффри Хинтоном зі сталою теорією глибинного навчання 2007. В цілому людство в лиці наукового прошару працює над штучними нейронними мережами та іншими методами штучного інтелекту з 1943 року. А от саму концептуальну ідею проробили як не дивно письменники фантасти. Найвідоміша трійка : Айзек Азимов, Артур Кларк та Роберт Хайнлайн. Вони працювали в той самий час як : Маккалок, Піттс та Тюрінг — між іншим в самий розпал Другої Світової війни.
Legacy — тобто наслідування від когось іншого програмного продукту, це абстрактне явище.

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

Аналогічно Delphi 7 проект також буже legacy.

Якість коду це окреме питання. Якщо брати Linux Kernel, то що там буде legacy? Напевне якийсь стиль Керніган та Річі. А от більш-менш сучасний Сі таким вже не буде. Тому якщо брати сучасне ядро, то вони не виглядає legacy.

K&R legacy example:

void foo(a,b)
int a;
float b;
{
    /* body */
}
Legacy це те, що має доведену можливість вирішувати проблеми, замість того, щоб створювати нові.

Якщо програмний продукт добре робить те, для чого створений і не викликає з часом нових проблем — то це не Legacy, а цілком робочий продукт.
Ось, наприклад: калькулятор, блокнот, пасьянс нарешті — десятки років працюють, виконують свою функцію і не створюють нових проблем.
Більш складний приклад MS Excel — майже стандарт у бізнесі. Але усе одно коли пішла мода на веб-аплікейшини то довелося і для нього писати веб-версію. Хоча і десктоп ніхто не відміняв.
Інша справа коли з часом продукт починає таки створювати проблеми. У першу чергу — через застарівання. Колись IE був еталонним браузером — але забарився з розвитком і за декілька років з лідера перетворився на аутсайдера. Якщо раніше девелопери страждали роблячи версію під не-IE, то потім підтримка IE стала новим кошмаром. Чудовий приклад того, що мертву кобилу краще поховати (особливо якщо вже винайшли трактор).
Іноді продукт продовжує працювати як треба — але технічний борг не дозволяє йому розвиватися. Так сталося з Windows — вона була і залишається чудовою для PC та ноутів. АЛЕ з роками вона тільки ставала більшою і важчою. І коли стала потреба зробити Windows для планшетів та мобільних телефонів — це виявилося неможливим! З часом розробили вже різні версії Windows, включаючи embeded — але час було втрачено і конкуренти захопили цю частину ринку.
Головна проблема Legacy ще й у тому, що технології розробки теж не стоять на місті. Старий продукт може бути досі гарним та користуватися попитом. Але він розробляється по-старому і відповідно коштує. У цей же час сучасні технології дозволяють створити такий самий продукт удвічі швидше та дешевше. І якщо цією можливістю не скористаються автори старого продукту — то неодмінно скористаються конкуренти!
Отже навіть якщо ти створив продукт, яким сьогодні користуються усі і він майже ідеальний — то можна декілька років «почивати на лаврах», купатися у грошах і нічого не міняти. Але так буде не завжди! Приклад Microsoft це чудово доводить: їм доводилося як бути майже монополістами — так і дивитися як інші захоплюють ринок інноваціями. Бо «краще — ворог гарного» і поки хтось плекає своє Legacy — інші розробляють його вбивцю!

Приклад Microsoft це чудово доводить: їм доводилося як бути майже монополістами — так і дивитися як інші захоплюють ринок інноваціями

Ну тут треба не повністю погодитись. Хто їх головні конкуренти ? Google, Apple та Amazon. При чому усі зазначені їм виплачують по патентах або за ліцензії. Десь йшлось що Microsoft заробляє з Android більше ніж Google, через патентні виплати. А Apple давно бізнес партнер, власне саме Біл Гейц витягнув з повної дупи Apple коли його приятель Стів Джобс повернувся, про це зокрема йшлось в сумісному інтерв’ю www.youtube.com/watch?v=ACucrVBq8Yg Так звана ворожнеча, це насправді була не більше як маркетингова стратегія яку насправді Джобсу та Гейтсу нав’язали, в рамках маркетингової стратегії «Think different». Насправді компанії були партнерами з часів створення, а Гейтс та Джобс товаришували усе життя. Щодо втрати ринкової вартості компанією і т.п. то це повністю заслуга Стіва Балмера, який геніальний комерційний директор і одночасно виявився нікчемним менеджером та жахливим CEO тобто ген директором. Це з рештою скінчилось www.youtube.com/watch?v=Vhh_GeBPOhs
Між іншим ранній Джобс теж був жахливим керівником та і в цілому дуже не зрілою персоною який часто наприклад ридав на нарадах вищого менеджменту. З рештою через це його підсиділи та звільнили, при чому по факту наближені Скаллі та Маркула.
З рештою Micorsoft це по суті частина Долини, в сутності проекту розвитку приватного бізнесу окремої індустрії урядом США. Цю підтримку з розвитку, в першу чергу з фінансово вмотивованого менеджменту, дуже добре видно на прикладі Ілона Маска зараз. Уряди США влили величезні гроші в його проекти як Tesla так і Spase X. При чому «супер зірку» на заміну вакантних місця Едісона, Джобса і т.п. по факту з нього зробив уряд демократів Барака Обами. Там рахунки на мільярди йдуться. США давно ведуть цілеспрямовану політику з мотивації людей щось робити ще з Рузвельта.В СРСР були : Стаханов, Зайцев, Павлюченко, Покришкін, Кожедуб, Гагарін, Терешкова і т.д. При чому так і звались — герої і медаль давали відповідну. А урядовий метод мотивації героями — з глибокої античності.

Якщо та приходить на ’аут ов дейт’ стек , умовний ангулар 1.1 та bower — то це не ок, такий експеріенс не потрібен для проф. Та кар’єрного росту. Що писати в резюме ?

Досвід з не треба плутати з методами технологічної конкуренції на ринку. Звісно маркетинг Microsoft та Apple в першу чергу, який почали копіювати усі кому не лінь включно з Google, Netflix та Amazon нас привчили, що от якщо не супер-дупер якись новий Flutter — або ChatGPT то завтра ви вилитете з ринку, усе втратите та підете на панель, в окопи або на папірть і помрете голодним. Вони почали цю маркетингову стратегію з Windows 95 з моєї пам’яті. На повірку — виходить, що там усе, що і було тільки в новій упаковці.
А якщо порахувати — ті самі : С — 1973, C++ — 1985, Python — 1991, Java — 1995, PHP — 1995, JavaScript — 1995 і наймолодший C# - 2001, з яким був хайп в три рази більший за ChatGPT не менший за BitCoin чи Windows 95 — хоча це чистий клон Java і розроблявся саме як завдання — склонувати Java, бо саме так було поставлено завдання Гейсбелргу керівництвом.
Ну тобто з усім чим працюємо подекуди старше за тих, хто з цим працює. Але від початку дизайни які були закладені в компілятори та інтерпретатори ще в 50-60 роки, та чудово описані в великій кількості наукових робіт, та вдалі дизайни мов програмування відносно великої кількості конкурентів, роблять продукти дуже добре підтримуваними.
Те саме можна сказати про операційні системи — Unix — та подібні Linux та Mac OS X, Windows NT (це усе починаючи з Windows 2000 по сучасну 11). Те саме реляційні бази данних і низка іншого. З тими самими штучними нейронними мережами — те саме, їх вже десятиліттями розробляють вчені.
А з точки зору праце влаштування — теж усе по старому, скажімо в Києві роботи в мало не в два рази більше ніж в Харкові. А зарплата більше на 40-50% і вже давно. А в Сан Франциско зарплата більше ніж в Києві в 100 разів, і роботи в ІТ теж більше — але робота така яка в Україні, в США здебільшого в Нью-Йорку, там теж зарплатня в в 50 разів більша за Київ. В Долині же роблять переважно технологічні «новинки» бо там був прямий доступ до інвесторів. Звідси і цей маркетинг — що як не щось нове, то тобі кінець (насправді зовнішні фактори на ринку є основою, а ні щось інше. Тобто — основа багатства є політика, бізнес процвітає лише у відповідних умовах). Усе теж, відносно по старому. Лише його величність інтернет вносить свої непоправні корективи і міняє світ, який ніколи не мав такого доступу до інформації за усю історію.

Смотря что понимать под легаси (только старый код или старый и плохой код) и смотря какие цели у работника. Это может быть как нормально так и нет. Нужно больше контекста

Майкл Фризис в книзі Work Effectively with legacy code — дає термін про будь який код який вам дістався від когось в спадок. Прямо кажучи і код який ви сам писали експериментальним чином, не проробляючи дизайн та архітектуру тобто не проектуючи, в раші під тиском менеджменту може бути не меншою проблемою за спадок від когось. Добре описано Фредеріком Бруксом в The Mythical Man Month 1975. Бо в спадок можна отримати як і один глобальний технічні й борг і жодної документації, так і скажімо Unix, Spring Framework і тому подібне.
З мого досвіду ця проблема лежить багато в чому зовсім не в сфері безпосереднього кодування. Проблема ширша і вона по суті стосується якості організації з виробництва програмного продукту. До цього теж приходить купа народу роpбляють різні моделі оцінок можливості колективів до створення програмного продукту.
Як на мене щонайкраще це описує — Capability Maturity Model від американського SEI uk.wikipedia.org/...​Capability_Maturity_Model. Їх досліди в цілому показують, що існує 5 рівнів організацій які здатні створювати програмні продукти.
Лише 20% компаній в США за їх дослідами, взагалі мали рівень вище першого !
Інакше кажучи, за дослідами Software Engineering Institute 80% ІТ бізнесу як такого — це мало компетентні організації, які в принципі не здатні створювати складні програмні системи відтворюваним чином.
Серед інших таких методик оцінок — наприклад COCOMO Баррі Боема, та інші.
Те саме стосується окремих відділків та проектів в великих корпораціях, де різні підрозділи один від одного відрізняються радикально та по суті мають мало чого спільного. В аутстафінгу — тобто на галерах, усе залежить взагалі від клієнта як у нього, так і в проекті. Власне саме через це за доброго клієнта, війна така сама як і на відкритому конкурентному ринку, вже в середині галери.

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

Софт для банків, атомних станцій (і при чому там теж бувають баги які можуть навіть бути присутніми десятиліттями) військових і інших державних установ розроблять по сьогодні . І ціна помилки як була високою так і є, це софт який вимагає якісного бізнес аналізу та тестування. Єдине що сильно змінилось — це потреба розробляти ще більше софту, ще скоріше. Індустрія в цьому звісно продвинулась, але не так кардинально як потреби людства. За великим рахунком ми працюємо з покращеними версіями та процесами з минулого сторіччя. Навіть просто з описання абстракцій, візьмемо скажімо UML — там просто нема діаграм за допомогою яких можна описати структуру кластеру гетерогенної системи, тих самих мікросервісів. Є купа приблуд типу network diagram в різних системах за допомогою яких це можна описати. Те саме з усім, принципово будь який новий Rust чи TypeScript, це просто сильно покращений Alogol 60 чи Basic. Концептуально програмування на них нічим не відрізняється. Просто ці мови трошки краще пристосовані для написання набагато більше складних програмних систем, краще перевіряють від простих помилок. Зі складними, усе як було погано так і є. Жодна мова не захищає від автоматизації повторення структури організації, яка приносить збитки сама по собі, на приклад. Або реалізації фітчі якою ніхто не користуватиметься бо в ній нема жодної потреби і т.д. і т.п.

суб’єктивно вважаю, що тут потрібно визначитись з точкою зору на легасі:
— з боку девопса, — що отримав саппорт проекту, що деплоїться ручками в консолі на впн та рестартом пм2 — то є ок, бо немає про що турбуватись з інфрастуктурою та дженкінсом, докером та іншими кубернетсами
— з боку бекенд девелопера, — що має працювати у якомусь застарілому варіанті того ж СейлсФорс під екліпсом, чи ВордПрессом на пхп5.6 — теж ок, бо нічого нового не прилетить, а всі старі багі вже відомі і є в інтернеті мануали як це все фіксити
— з боку фронтендера, — якщо він спокійно, без антидепресантів, кокаіну, гейш, та магній Б6, приймає роботу з дЖквері2 — то теж все ок. (але це не точно, бо де ж знати такого фронтендера?.. раніше їх називали веб-майстер чи Анікей !!! )

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