Як ви справляєтесь із змінами у структурах з відкритим кодом, які використовуєте для своїх проектів?

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

Протягом останніх семи місяців ми зробили істотне перезапис нашого програмного забезпечення. Ми скинули рамку Xaraya, яка була повільною і по суті мертвою як продукт, і перейшли до PHE Cake. (Ми вибрали торт, тому що він дав нам можливість зробити дуже швидке перезапис нашого програмного забезпечення та достатньо підвищення продуктивності над Xaraya, щоб зробити його вартим нашого часу.)

Ми здійснили тестування одиниць за допомогою SimpleTest і дотримувались усіх умов іменування файлів і баз даних тощо.

Зараз торт оновлюється до 2.0. І, схоже, не існує життєздатного шляху міграції для оновлення. Умови іменування файлів докорінно змінилися, і вони відмовилися від SimpleTest на користь PHPUnit.

Це в значній мірі змусить нас залишитися на відділенні 1.3, тому що, якщо не існує якогось інструменту перетворення, оновити Cake не вдасться, а потім поступово вдосконалити наш застарілий код, щоб скористатися перевагами нового фреймворку Cake . Отже, як завжди, ми збираємося створити старий фреймворк у нашому сховищі Subversion і просто поправити його самостійно за потребою.

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

Як ви ставитесь до кардинальних змін у проектах з відкритим кодом, якими ви користуєтесь? І якщо ви розробляєте продукт з відкритим кодом, чи пам’ятаєте ви про шляхи оновлення, коли розробляєте нові версії?

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

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

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

Ми вирішили цю проблему, модулюючи наш код.

Наш основний веб-сайт був створений близько восьми років тому, і нам пощастило, щоб його створив один із перших учасників Весняних рамок, тому він був досить добре побудованим фундаментом. Але, на жаль, нам також не пощастило, що цей розробник вирішив роздрібнити Spring після суперечки про напрямок, в якому він рухався, тому ця база коду тепер застрягла на незбереженій форк Spring 1.1.4 (або щось із цього урожаю).

Ми намагалися переписати код, щоб перейти до нових версій Spring, але це виявилося надзвичайно важко. Тож наше рішення полягало в тому, щоб почати створювати нові функції сайту як модулі в абсолютно окремому додатку, використовуючи новітні рамки, такі як Spring 3.x, Hibernate 3.6 і т.д.

Зараз у нас є два веб-додатки, що працюють на одній базовій URL-адресі, і ми використовуємо модуль mod_proxy Apache для виділення кожного шляху до відповідної програми. Наприклад, "/ members" переходить до старої програми, а "/ members" переходить до нової програми. Однак відвідувач сайту не здогадується, що вони використовують різні програми; вони виглядають точно так само, як і користувачеві.

Ці два додатки потребують зв'язку, наприклад, коли учасник входить на сайт (використовуючи нашу нову програму), нам потрібно повідомити стару програму про те, що вони зараз увійшли. localhost. Обсяг інтеграції, необхідний між двома додатками, виявився мінімальним.

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

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

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

І це те, що отримує мене кожен раз.

Щоразу ? Ви повинні робити надзвичайно поганий вибір. Має бути один приклад, коли цього не сталося.

Коли чорти почнуть грати з новою блискучою іграшкою

Це натяк. Уникайте нових блискучих іграшок, використовуючи проекти з відкритим кодом. Уникайте випуску 1.0.

Як ви ставитесь до кардинальних змін у проектах з відкритим кодом, якими ви користуєтесь?

Крок 1. Вибирайте проекти з відкритим кодом дуже і дуже ретельно. Завжди порівнюйте два чи більше конкуруючих проектів.

Крок 2. Порівнюючи два конкуруючих проекти, спробуйте зрозуміти "суттєву" особливість, яку пропонують, і як вони обидва підходять до неї. Не уникайте "одруження" на одному конкретному API занадто рано.

Крок 3. Дотримуйтесь принципів дизайну "Пізнє прив'язування" та "Вільне з'єднання". Спробуйте ізолюватися від змін проекту з відкритим кодом.

Крок 4. Явно проведіть порівняння витрат / вигод між проектами з відкритим кодом та "прокатуванням власних". Час від часу створювати власне рішення може бути краще, ніж впоратися з відкритим рішенням.

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

Якщо це відбувається щоразу , тоді розробляйте кращі стратегії подолання. Оскільки ваше спостереження за реальним світом полягає в тому, що це завжди відбуватиметься, то сподівання на зміну реального світу насправді не допоможе багато. У вас є певний досвід перемог у змінах. Посилити це. Розгляньте це як інфекцію та виробіть власну імунну відповідь.