Code Complete («Досконалий код»)
У мене є guilty pleasure – читати старі книжки про розробку ПЗ. Чому guilty? Бо часто інформація в них уже неактуальна. Чому pleasure? Бо цікаво бачити, який шлях пройшла індустрія: як еволюціонували підходи, як спростилася реалізація, і як фокус змістився з залізних обмежень на покращення Developer Experience, а не на оптимізацію ресурсів.
TL;DR
Особисто я не отримав багато користі з цієї книги у 2025 році. Але якщо ви – джун або мідл, і вам цікаво подивитись, як мислили розробники у 90-х–2000-х, – з хорошим ментором поруч ця книга може дати корисну рамку мислення. Але не варто сприймати все буквально – багато речей застаріли або стали де-факто стандартом, про який навіть не переймаєшся.
Мені знадобилось 10 років, щоб виділити час, сісти й прочитати її від початку до кінця. До цього були кілька спроб, але завжди щось зʼявлялося пріоритетніше. Ця книга була в моєму «must read» списку професійної літератури.
Каюсь: колись для мене був ред флег на співбесіді, якщо кандидат не читав жодної книги з цього списку. Зараз – байдуже. Не важливо, звідки ви черпаєте ідеї, хоч з TikTok.
І хоч я вважаю цю книгу не вартісною для сучасного рівня розробки, у ній є кілька думок, що мені відгукуються.
Пишіть код у першу чергу для людей
Це, як на мене, – головний принцип розробки якісного ПЗ. Ваша ціль – не просто «вирішити бізнес-проблему», а зробити так, щоб це рішення можна було підтримувати.
- Хитрий код = поганий код
- Пишіть так, щоб зрозумів програміст рівнем нижче
- Коментуйте мету коду, а не що він робить
- Пояснюйте все, що стосується помилок, edge cases, хаків, порушень стилю
- Написання читабельного коду не займає більше часу, ніж заплутаного
Звісно, є винятки: оптимізації, обхід залізних/платформних обмежень. Але навіть тоді напишіть чому так, яка була альтернатива, і чим цей варіант кращий.
Програмуйте з використанням мови, а не на мові
Не обмежуйте мислення лише тими концепціями, які явно підтримуються мовою. Спочатку сформулюйте, що ви хочете зробити, а вже потім – як цього досягти за допомогою інструментів, що у вас є.
Ретроспектива еволюції розробки ПЗ
Основна проблема залишилась незмінною: боротьба зі складністю.
Complexity is the primary killer of productivity and quality.
Але стало набагато простіше й комфортніше писати якісний код: лінтери, автоформатування, watch-режим для тестів, AI-асистенти, набагато потужніші компуктери як інструменти.
Ми пройшли шлях від «мистецтва програмування» до «мистецтва перетворення бізнес-вимог у готове рішення». Швидкість доставки зросла в рази, а якість – не впала. Хоча… може й впала, якщо глянути, наскільки легше стало щось реалізовувати, і водночас наскільки поганими стали продукти в нормі індустрії.
Не довіряйте сліпо «оракулам програмування»
(і тим більше – моїм записочкам)
Жодна методика не вирішує всі проблеми. Не вірте в обіцянки типу «наша система універсальна». Тестуйте на практиці. Порівнюйте. Ітеруйте. Беріть ідеї з різних предметних областей, мов, технологій. Експериментуйте.
Я не знав, що мій підхід має назву
Виявилось, те як я зазвичай пишу код називається Pseudocode Programming Process. Спочатку я описую проблему на високому рівні, накидаю алгоритм словами, а потім іду по ньому і реалізую вже кодом.
Це дозволяє не губити думку, швидше ітерувати і не фокусуватись одразу на синтаксисі.
Code Complete – книга свого часу. Вона допомагає побачити, з яких ідей виростала сучасна культура програмування, і чому багато речей, які ми сьогодні сприймаємо як очевидні, колись були проривом.
У 2025 вона навряд чи відкриє вам нові інструменти, патерни чи практики. Але може дати історичну глибину, рефлексію, і допомогти сформулювати для себе відповідь на питання: що саме ми вважаємо «хорошим кодом» і чому.
Уперше опубліковано в моєму Telegram-каналі.