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

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

Найбільш часта ситуація, яку я можу привести в приклад str_repeat('дуже', 20) старий код, який не знає навіть класів, планується перенести або частково використовувати в сучасному фреймворку, але переписувати тисячі рядків і десятки залежностей немає часу. Таке буває, коли замовник раптом вирішує суттєво модернізувати або розвивати проект, який 10+ років працював без змін, а сапортил його один парттайм-олдскул-програміст зрідка перезавантажуючи пару-трійку сервісів і відновлюючи паролі.

Читати далі →

«Гасниця» проти «Патріотів»: як американські військові програмісти навчилися правильно округляти

11 лютого 1991 року Patriot Project Office отримав ізраїльські дані про дефект в ракетної системи Patriot. Вони знайшли, що якщо система працює 8 годин, вона починає мазати на 20%. Вони прикинули, що після 20 годин роботи система починає промахуватися настільки, що перестане бути здатною захоплювати, відстежувати і вражати балістичні ракети. Американські військові не взяли до уваги всю важливість відкриття, заявивши, що система призначена для портативних і короткострокових захисних операцій і що ніхто ніколи не буде використовувати систему більше 8 годин.

16 лютого був випущений Bug Fix, але щоб його впровадити в усі одиниці бойової техніки, потрібен час, бо війна.

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

25 лютого у Дахрані (Саудівська Аравія) в казарму в гості до американцям прилетіла баллистичекая ракета "гасниця" (вона ж Р-17, вона ж Scud). 28 вбито 96 поранено, тому що ЗРК «Патріот» промахнувся з-за програмної помилки.

26 лютого Bug Fix був доставлений у Дахран.




Читати далі →

Нове життя legacy проекту

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

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

Читати далі →

Кейс OZON.ru: Як зробити тарифікацію доставки прозорою і керованої

Ви стикаєтеся з тарифікацією доставки, коли робите замовлення в інтернет-магазині. Тарифікатор — IT-система, яка говорить яким способом товар доставлять, на які посилки розіб'ється кошик, скільки коштує доставка і коли привезуть замовлення. Тарифікатор збирає інформацію зі складу та служб доставки, переробляє і видає результати покупцям інтернет-магазину на сайті.

Ціна за доставку товару для покупця інтернет-магазину рідко збігається з ціною, яку транспортна компанія візьме з самого магазину. Захотіли ви привезти книги з допомогою DHL в Новосибірськ. OZON.ru виставить вам конкурентну ціну за доставку — 500 руб. При цьому DHL за цю доставку виставить OZON.ru рахунок на 1000 руб. Це здається дивним, але така реальність, яку диктує ринок.

Читати далі →

Що мати на увазі при переписуванні програмного забезпечення

При розробці якихось продуктів у команди часто виникає бажання перестати боротися з поточним станом проекту і переписати все знову, на цей раз "правильно" і "по науці". Зазвичай такі пориви не схвалюються, але в цей раз я б хотів запропонувати до прочитання переклад поста Hugo Baraúna, присвяченого тому, які питання потрібно задати собі, якщо все ж вирішили переписувати.
Також, як і великий рефакторинг, переписування продукту — непроста штука. За багато років ми набули достатньо досвіду, щоб вказати, що вам слід обдумати, плануючи і здійснюючи процес переписування.
чи Будуть обидві платформи існувати одночасно, чи ні?
Читати далі →

Legacy-код - це рак

Все частіше і частіше я бачу, що люди ухиляються від новітніх технологій, роблячи вибір на користь зворотної сумісності. «Ми не можемо підвищувати мінімальні вимоги до PHP до 5.5, тому що у нас 50% користувачів ще на 5.4» кажуть вони. «Немає ніякого способу оновитися до
Guzzle 4+
, у нас бекенд на версії 3 і переробляти його занадто довго і дорого». І найкращий аргумент від WordPress: «Ми не може прийти до повного ООП, тому що більшість користувачів сидять на shared-хостингах з 5.1 або не знають про MVC».

Нонсенс.

Legacy-код — це велике НЕМАЄ

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

Читати далі →

Революція PHP7: Типи значень і видалення артефактів

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

PHP 5.7 vs. PHP7

Як я вже говорив в минулому листі, 5.7 був відхилений на користь переходу безпосередньо до PHP7. Це означає, що не буде нової версії між 5.6 і 7 — навіть якщо вона і з'явилася б, то просто служила б сигналом тим, хто все ще загруз в застарілому коді. Спочатку, 5.7 не повинна була мати нові функції, але повинна була викинути повідомлення і попередження про старіння коду, який скоро зміниться в v7.

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

Читати далі →

Legacy-фобія

Колеги, у мене для вас є чудова новина, ми отримали чудовий проект, його кілька років писали невідомі нам розробники, адреса яких ми навряд чи дізнаємося (щоб «поділитися зворотним зв'язком»), писали дуже давно і не відомо під ніж, і нам треба його підтримувати і розвивати. Проект зараз знаходиться на піку своєї продуктивності і ми скоро упремося, будь неакуратні зміни можуть його покласти, але ми будемо його розвивати. Ура!

Погодьтеся, дивно звучить? Як марення хворого на голову програміста. Хто ж любить legacy? Це ж завжди говнокод (адже тільки ми самі пишемо ідеально), в ньому повно багів (а ми самі пишемо без помилок), жахливі рішення (адже тільки ми самі вибираємо відповідну архітектуру), і майже завжди його складно читати (адже тільки ми самі пишемо зрозуміло і красиво).


Читати далі →