Написання кращого коду для проектів на базі WordPress

Я точно не пам’ятаю, коли вперше натрапив на блог Джоела Спольського Joel on Software, але це було наприкінці середньої школи.

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

Насправді я був таким фанатом, що, закінчивши навчання, купував його книги (які були збірками статей на його сайті) і читав їх від обкладинки до обкладинки. Я зберігав їх копії на своєму столі на роботі, і я використовував одну з його книг «Розумний і справляє справи», коли я був керівником команди.

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

Написання кращого коду

Натомість це пов’язано з процесами, пов’язаними з кращим кодом. І я випадково натрапив на статтю – 16 років тому, – і я все ще вважаю її такою ж актуальною сьогодні, як і коли я вперше її знайшов.

За винятком того, що зараз я сам дивуюся, як це стосується мого поточного концерту розробки.

Тест Джоела

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

1. Ви використовуєте контроль джерел?
2. Чи можете ви зробити збірку за один крок?
3. Ви робите щоденні збірки?
4. У вас є база даних про помилки?
5. Чи виправляєте ви помилки перед написанням нового коду?
6. Чи є у вас актуальний графік?
7. У вас є специфікація?
8. У програмістів тихі умови роботи?
9. Чи використовуєте ви найкращі інструменти, які можна купити за гроші?
10. У вас є тестери?
11. Чи пишуть нові кандидати код під час співбесіди?
12. Ви проводите тестування зручності використання в коридорі?

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

Цікава особливість тесту Джоела полягає в тому, що на кожне запитання можна швидко відповісти «так» чи «ні ». Вам не потрібно з’ясовувати кількість рядків коду на день або середню кількість помилок на точку перегину. Дайте своїй команді 1 бал за кожну відповідь «так».

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

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

Тест Джоела для WordPress

Можливо, для тих із нас, хто використовує WordPress як основу розробки, наш набір запитань виглядатиме приблизно так:

1. Ви використовуєте контроль джерел?
2. Чи можете ви виконати розгортання за один крок?
3. Чи виконуєте ви щоденні розгортання?
4. У вас є база даних про помилки?
5. Чи виправляєте ви помилки перед написанням нового коду?
6. Чи є у вас актуальний графік?
7. У вас є вимоги та макети?
8. У програмістів тихі умови роботи? Або, якщо віддалено, програмістам дозволено переходити в режим «Не турбувати»?
9. Чи використовуєте ви найкращі інструменти на ринку, чи то безкоштовні з відкритим кодом, чи то преміум-класу?
10. У вас є тестери? (І я можу запитати, чи дозволяє бюджет проекту також час на написання модульних тестів для автоматизованого тестування)?
11. Чи є у кандидатів зразки коду, доступні на GitHub, у блозі чи загальнодоступному місці, які можна переглянути?
12. Чи є у вас група людей, з яких ви можете протестувати незавершену роботу?

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

О, і вся ця річ із забиттям?

12 балів – це ідеально, 11 – допустимо, але 10 і нижче – у вас серйозні проблеми. Правда полягає в тому, що більшість організацій, що займаються програмним забезпеченням, мають 2 або 3 бали, і їм потрібна серйозна допомога…

У кожного з нас є до чого прагнути, чи не так?

На наступне десятиліття?

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

Але на момент написання цієї статті я можу сказати, що я не можу сказати «так» усім цим, не кажучи вже про, можливо, половині з них. Хоча, можливо, до кінця року я зможу.

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