Код майбутнього підтвердження

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

Ну, перш за все, є деякі речі, які потребують уточнення:

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

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

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

Мій 2с

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

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

Хороший спосіб переконатися в цьому - використовувати тест-керування та розробку. Тестові випадки виходять із специфікації та випадків використання. Увесь код повинен скласти тестовий пропуск. Необхідний код не слід писати. Роблячи це таким чином, легко визначити, потрібен він чи ні.

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

• Для мене, майбутня перевірка коду, - це написання таким чином, що він зможе взаємодіяти з розвиваються технологіями. Це передбачає модулізацію вашого коду, щоб кожна частина вашої програми могла взаємодіяти незалежно від мови та технології програми в цілому. Хорошим прикладом цього може бути використання XML або JSON для передачі даних між різними частинами програми. Однак технологія розвивається, дуже ймовірно, що вона завжди зможе читати XML та JSON.

• Подібно до вищезазначеного, оголення частини вашої програми через SOAP або REST API дозволяє досягти подібного. Які б технології не розвивалися, вам не обов’язково потрібно буде переписувати кожну частину програми, оскільки нові технології все ще зможуть спілкуватися зі старими.

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

Таким чином, будь-яким чином, зробіть кодове майбутнє доказом (NASA все ще надсилає космічні кораблі за допомогою Fortran), але не пишіть код "на всякий випадок".

Подумайте, скільки разів ви включили фрагмент коду вниз у виробничому середовищі, і подумайте: "Слава Богу, я написав це 2 роки тому!".

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

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

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

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

Усунення невизначеної поведінки : багато коду має поведінку, яка просто розвивається з нізвідки. Певні комбінації введення призводять до певного результату, який ніхто насправді не мав наміру, але так буває. Тепер неминуче хтось буде покладатися на таку поведінку, але ніхто про це не дізнається, оскільки це не визначено. Той, хто намагатиметься змінити поведінку в майбутньому, ненавмисно порушить справи. Використовуйте перевірки безпеки зараз і намагайтеся видалити / заблокувати всі не визначені способи використання коду.

Автоматизований набір тестів : я впевнений, що ви можете знайти томи, написані про необхідність одиничних тестів. Що стосується майбутнього підтвердження, проте це є критичним моментом у дозволі комусь переробити код. Рефакторинг має важливе значення для підтримання чистого коду, але якщо не вистачає гарного набору тестів, ви не можете безпечно переробляти.

Ізоляція та сегрегація : інкапсуляція та правильна модуляція є хорошим принципом проектування, але вам потрібно вийти за рамки цього. Ви часто виявляєте, що вам потрібно використовувати бібліотеку, API чи продукт, який може мати сумнівне майбутнє. Можливо, через проблеми з якістю, проблеми з ліцензуванням або постійний розвиток авторами. У цих випадках потрібен додатковий час, щоб нанести шар між вами та цим кодом. Наріжте API так само, що вам потрібно, щоб з'єднання було дуже низьким, щоб в майбутньому було легше замінити.

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

"Майбутнє підтвердження" в кращому випадку означає "слабко пов'язаний дизайн". 80% часу люди мають на увазі "гнучких", коли кажуть "докази у майбутньому". Іноді кажуть, щоб спробувати звучати круто. Але принаймні вони доставляють щось своєчасно, що працює.

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

Є два крайні корпуси.

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

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

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

ЯГНІ = Вам це не потрібно .

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

Див. Також: Позолота .

Ігноруючи заголовок питання та дотримуючись основного пункту про "розміщення матеріалів, тому що хтось може цього захотіти"

Відповідь - НІ. Ніколи. Не пишіть шви коду, який вам сьогодні не потрібен. Ось чому:

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

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