Програми — це складні механізми, які розв’язують складні задачі. У наші часи складність програм і систем все зростає і зростає. Які головні проблеми виникають у початківців-програмістів? І що робити для їх вирішення?

      На ці питання нашому журналісту Івану відповів Олександр Узун, Senior Java Developer і спеціаліст з протоколів передачі файлів у компанії Finbotica.

      «Програмісти, на жаль, через особливості характеру: інтровертності, замкнутості, намагаються підвищити свою цінність, ускладнюючи життя всім навколо, і в тому числі колегам. Самим собі вони здаються розумнішими, але це не так. Комусь твій код треба буде супроводжувати, розширяти. Ідеально — це якщо людина відкрила твій код, все зрозуміла, щось хірургічно підправила, закрила і все працює. А не так, щоби відкрили:« І — що там? Навіщо це, навіщо те?»  Ви вже самі не пам’ятаєте…», - каже Олександр.

Іван:

— Якщо патерни — це лише засіб розв’язання складних задач, а фреймворки — всього лише інструменти, то що головне у об’єктно-орієнтованому програмуванні? Що таке розподіл відповідальності у програмуванні? Як досягти принципу «найменшого здивування» читача?

Олександр:

 — Проблеми найменування. 

      Проблеми, з якими я стикався у ході своєї кар’єри, вони носили такий доволі кумедний з одного боку, але фундаментальний характер. Проблеми найменування, а основне — це розподіл відповідальності.

      У об’єктно-орієнтованому програмуванні головне — це розподілити відповідальність так, щоби ізолювати складність і облегшити внесення змін, розширення. Це фундаментальна річ.

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

      Мої прагнення були близькі до «літературного коду», як його розумів Кнут.

      Сенс у тому, щоб облегшити читачу задачу:
 

- Читає назву методу і розуміє, що він робить.

- А якщо потрібні подробиці — відкрив метод і прочитав.

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

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

      Мої багатоденні роздуми знайшли відклик у популярній нині концепції Domain-Driven Design (DDD).

      Аспект патернів грає якусь роль, але не можна на ньому концентруватися. Назви ваших класів мають описувати роботу предметної області, а не патерни, які для них використані. Це не мають бути «Adapter», «Bridge». Читач має зрозуміти, що робить програма, і всередині знайти ті об’єкти, які цьому відповідають. 

Принцип — найменшого здивування 

      Читач має прочитати опис предметної галузі, і має в програмі знайти ті ж самі дії, а не адаптери, фасади та кінгстони.

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

      Є правила найменування, їх Макконнелл і Кент Бек описували. Треба полегшувати задачу читачу і не економити букви. Більшу частину часу ти все одно думаєш, а не друкуєш. 

Іван:

— А що б ти порадив нашим юним читачам, які хочуть стати гарними програмістами? Що читати, що робити?

Олександр:

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

      Для цього є фундаментальні чорно-жовті книги — «Архітектура комп’ютера» Тененбаума, «Комп’ютерні мережі». Щоб розуміти, як процесор виконує команди, як на мікрокоді будується асемблер.

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

       Якщо ви берете нову бібліотеку — розбирайтесь, як вона влаштована.

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

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

      Другий момент — читайте код. Як книжку.

Професія програміста означає, що ви будете читати та писати код.

Просто брати великі проєкти та читати…

До речі, є гарна серія книг — «The Architecture of Open Source Applications», там три книжки вийшло. Це про те, як влаштовані великі проєкти на С. Це дуже цікаво, бо спочатку дуже важко зрозуміти як саме спроєктувати проєкт.

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

      Фундаментальне розуміння і читання коду. Це головне. 

Дякуємо Олександру Узуну за змістовне інтерв'ю. 

Бесідував Іван Синенко