Розмір проекту та «Простота»
З будь-якої причини існує постійне протиріччя (принаймні з моєї точки зору) між корисністю створення чогось для когось і кількістю часу, необхідного для того, щоб це створити.
Під цим я маю на увазі, що коли справа доходить до WordPress, відносно легко створювати невеликі прості плагіни та утиліти для інших, які не обов’язково дотримуються найкращих сучасних практик.
А щодо цієї публікації я б сказав, що сучасні найкращі практики є приблизно такими:
- менеджер пакетів на стороні сервера,
- менеджер пакетів на стороні клієнта,
- належне модульне тестування,
- добре продумані заняття,
- документований код,
- і так далі.
І все це чудово і, можливо, необхідно для великих проектів (особливо тому, що технічне обслуговування та послідовний розвиток відіграватимуть таку важливу роль).
Зберігаючи це просто
Але як щодо менших проектів, де ви більш-менш єдиний розпорядник кодової бази? Я не кажу, що хороші практики не слід застосовувати. Я думаю, ми повинні:
- мати добре задокументовану кодову базу,
- дизайн функції або класу, який відповідає майбутньому розвитку,
- а також оптимізацію коду як на стороні клієнта, так і на стороні сервера
Але чи означає це, що ці проекти повинні мати великі каталоги постачальників або великі каталоги node_modules?
Photo by Artur Pokusin on Unsplash
Коротко кажучи, я так не думаю. Я думаю, що це пов’язано з надмірною інженерією.
Робіть речі максимально простими, але не простішими.
Це не означає, що ми відмовляємося від ретельності, необхідної для написання якісного коду в контексті нашої IDE.
Потенційні рекомендації
Але, можливо, на цьому все зупиняється. Тобто, можливо, хорошим емпіричним правилом є:
- Якщо проект вимагатиме безперервної інтеграції, то він повинен мати необхідні огорожі для забезпечення якості як локально, так і в середовищі проміжної роботи та безперервного процесу інтеграції.
- Якщо проект збирається створювати, а потім випускати (і робити це ітеративно), то більшість якості має вимірюватися та забезпечуватися через IDE.
Я не знаю, чи це найкращий спосіб підійти до цього, але це те, про що я витрачав час на роздуми, і продовжую досягати набору вищезв’язаних бар’єрів.
Зараз я пишу електронну книгу (разом із різноманітним іншим преміум-контентом). Якщо вам цікаво, перевірте, що ви отримуєте.