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

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

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

Як ви маєте справу з еволюцією стандартів кодування у вашому проекті?

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

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

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

Що ми робимо - це еволюція (а не революція) для бази коду, ми також використовуємо оновлений стандарт, коли;

• новий код написано
• код відновлюється
• помилки виправлені
• нові частини додаються до існуючого класу

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

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

Однак, для зміни стандарту кодування слід розглянути два випадки:

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

Це дійсно має залежати від типу продукту, який ви створюєте:

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

Особисто я б вирішив зберігати старі коди такими, якими вони є, і дотримуватися нових стандартів від того, що ви робите новим. Більш конкретно, я не буду використовувати подвійні стандарти в старих. Але якщо я збираюся створити new.c, він може використовувати новіші, вдосконалені синтаксиси :)