Програмування мислення або друкування, мислення та друкування, Стаття
"Якщо не вміти думати, то може здатися, що програмування - це просто друкування команд на клавіатурі".
Уорд Каннінгем, з передмови до The Pragmatic Programmer
Розробка ПЗ — проектування, вирішення проблем, винахід оптимальних нових алгоритмів, вивчення нової мови програмування, рефакторинг плутаного коду та перетворення його на щось легше і красивіше — все це складна розумова робота.
Наприклад, вам може знадобитися вирішити завдання, яке ще жодного разу не вирішували — або ніхто до вас не вирішував. Або раніше вам вже доводилося вирішувати таке завдання, але ви в жодному разі не хочете повторювати своїх помилок і збираєтеся продумати більш оптимальний варіант рішення. Деколи вам потрібно зрозуміти написаний кимось код, щоб змінити його або відловити якийсь шкідливий баг. На все це може піти чимало часу, але зрештою виявиться, що для цього знадобилося написати не так багато коду.
Коли програмування – це просто друкування коду, а коли ні
Але при розробці ПЗ доводиться вирішувати й інші завдання, що вимагають не стільки розумової напруги, скільки набору цілих простирадл коду. Коли вже ясно, що треба зробити і як це зробити, залишається руками набрати масу коду, необхідного для виконання завдання. Ви вже робили це раніше і просто маєте зробити знову: ще скрипт, ще екран, ще звіт і т.д. У той же час більшу частину розумової роботи хтось уже виконав за вас: підготовлені каркасні моделі, вам точно відомо, як має виглядати і працювати додаток, як у ньому організується потік завдань, API докладно описані в специфікаціях. Від вас потрібно просто все це написати і по можливості допустити меншепомилок.
Налагодження - це мислення. Виправлення бага та забезпечення того, щоб редагування було протестовано та видано у готовому вигляді — це в основному набір тексту. Проектування та ранні етапи розробки, технічне зондування для перевірки якості технології, розробка архітектури – це напружена розумова робота. Підготовка третього, четвертого чи сотого екрана, а також будь-якого звіту – це написання коду. Проектування користувацьких взаємодій (UX) та прототипування: мислення. Планування підтримки CRUD-операцій та конфігураційних екранів: набір коду. Зародження класної ідеї для нового мобільного застосування: мислення. Її реалізація – набір коду. При вирішенні найпоширеніших бізнес-проблем потрібно писати дуже багато коду. При оптимізації бізнес-процесів на рівні коду необхідно багато і напружено думати. Серед наших колег є і ті, хто багато думає, і ті, хто переважно пише код. Вся справа в тому, що вони зайняті принципово різною роботою і, отже, керувати ними треба по-різному.
Іноді програмування – це просто друкування коду
«Насамперед ми складальники тексту і лише потім — програмісти».
Багато бізнес-додатків, по суті, є неглибокими. Вони мають безліч таблиць баз даних, файли з безліччю інформаційних елементів, маса екранів і звітів, виключно схожих інші такі ж екрани і звіти, величезна кількість інтеграційної роботи з купою полів, які мають відображатися між різними точками програми. Нарешті, є певні обмеження, необхідні відповідності правилам, і навіть експлуатаційні залежності, про які необхідно подбати. Довгі списки функціональних вимог, купа питань, на які потрібно відповісти та переконатися, що всі правильно розуміютьпоставлені вимоги, маса деталей, які потрібно запам'ятати та відстежувати.
Банківська справа, страхування, облік, фінансова звітність та білінг, управління матеріально-технічними ресурсами та ERP-системи (планування ресурсів підприємства), CRM-системи (управління взаєминами з клієнтами), додатки для операційних відділів (back office), а також інші бухгалтерські і облікові системи - ось як різноманітний цей бізнес-софт. Такі ж багато веб-порталів та інтернет-магазинів. Не слід забувати і про техпідтримку; оновлення платформи та робота з інтеграції системи, зміни у правилах та податкові зміни – все це рутинна копітка робота.
Припустимо, ви будуєте будинок, або міст, або торгові ряди, а можливо ремонтуєте таку споруду. Це великі проблеми, що часто наростають, вирішення яких часом обходиться недешево. Доводиться готувати велику кількість документації (набирати текст). Але такі завдання вже багаторазово виконувалися раніше; як правило, подібна робота полягає у вирішенні проблем із застосуванням добре опрацьованих патернів, відомих інструментів та методологій.
Коли проектування закінчено, основна робота зводиться до розуміння всіх деталей та вміння поводитися з ними, а також управління людьми та координації зусиль — тобто до написання готового коду. Це класичний приклад проект-менеджменту: бюджетування, планування, відстеження видатків та змін, а також ефективне делегування завдань. Основними аспектами роботи є логістика, масштабування, узгодженість та ефективність — так, щоб увесь проект не зійшов з рейок.
Існують і інші завдання: проектування ігрового двигуна, торгового алгоритму, логістичної схеми, системи онлайнового управління ризиками або, наприклад, оптимізація системконтролю, що працюють у реальному часі. У таких випадках програміст займається не так набором коду, як розумовою роботою. До подібних систем пред'являються дуже високі нетехнічні вимоги (масштабованість, продуктивність у реальному часі, надійність, цілісність та точність даних), у них діє складна логіка. Проте такі програми застосовуються для вирішення обмеженого кола проблем. Декілька розумних людей можуть осмислити такі завдання і знайти рішення для більшості з них. У таких випадках також потрібно набирати певну кількість коду. Зокрема, це стосується коду, що обрамляє, службового і сполучного коду, але основна частина роботи зазвичай виконується в напрочуд невеликій кількості коду. Щоб у цьому переконатися, достатньо відкинути всі невдалі експерименти та прототипи.
Тут ми торкаємося найчарівніших аспектів програмування — пропрієтарних або патентованих алгоритмів і дизайнерських осяянь, що лежать в основі успішної системи. Для виконання такої роботи потрібно проводити масу досліджень, займатися прототипуванням, вміти вирішувати проблеми, а також володіти справжньою технічною хваткою, глибокими знаннями предметної області або тим, і іншим одночасно.
Друкування та мислення – це різні види роботи
Необхідно відразу визначити, яка робота буде найважливіша у майбутньому проекті — набір великої кількості коду чи мислення. Виходячи з цього, приймаються рішення про те, скільки людей має бути в команді та яким людям ви готові доручити таку роботу. Зрозуміло, відрізнятимуться і методи управління такими командами, і принципи взаємодії у яких. Набір коду можна організувати шляхом аутсорсингу. Мислення – ні. Вам доведеться визначити, для вирішення яких проблем достатньопросто вміти набирати код, а яких випадках цього недостатньо. Також важливо вловити момент, коли розумова робота в основному закінчується і починається копіткий набір коду.
Розумна робота добре протікає у невеликих командах тісно взаємодіючих фахівців і повинна виконуватися саме ними. Можливо, достатньо буде лише одного генія, який працює самостійно. На етапі підготовки проекту або пошуку рішення для складної проблеми, експериментування вам не потрібно великої команди (і правильно). Хто б не працював над проблемою на цьому етапі, він повинен повністю поринути у вирішення завдання, приділити час на дослідження альтернатив, мати право на помилку та навчитися чогось на ній, або просто відійти та подивитися у вікно, коли виникне дефіцит ідей.
Ось де іноді допускаються фундаментальні помилки, іноді загрожують руйнуванням архітектури, завалом проекту, крахом кар'єри. Достатньо неправильно вибрати технологічну платформу. Невірно оцінити припустимі відхилення в реальному часі. Витратити занадто багато часу, щоб усунути труднощі (а то й взагалі не вирішити їх). Набрати в команду не тих людей чи неправильно поставити завдання, які потрібно вирішити. Пропустити фініш.
При управлінні роботою такого роду необхідно залучити до неї найкращих людей, яких ви можете знайти, переконатися, що у них є вся необхідна інформація та інструменти, постійно підтримувати їхню концентрацію на роботі, визначати можливі зовнішні ризики та завчасно усувати проблеми, що заважають вирішенню завдання .
Мислення непередбачуване. У нас не вбудована функція «копіювати-вставити», тому що інформацію нема звідки копіювати і нікуди порівняти. Неможливо врахувати все, тому що ви ніколи не можете точно окреслити обсягите, що вам невідомо. Просто намагайтеся видати найкраще рішення, яке можна підготувати за час.
Набір коду – передбачувана робота. Її обсяги можна і треба оцінювати. Найважливіше — врахувати весь код, який має бути написаний, зробити поправку на всі дрібні помилки та відхилення від курсу, які можуть виникнути під час роботи, оскільки подібні огріхи накопичуватимуться дуже швидко. Неакуратність і зрізання кутів, нерозуміння вимог, нехтування тестуванням, копіпаста - за все це вам доведеться зазнати додаткових витрат як сьогодні, так і в майбутньому.
Набір коду – досить некваліфікована робота. Для цього потрібні не експерти, а просто такі люди, які цілком компетентні, розбираються в основах мови та інструментах, ті, хто акуратно дотримуватиметься вказівок і терпляче напише весь потрібний код. Звичайно, кілька senior-розробників можуть робити таку роботу швидше за натовп простих кодерів, але тільки поки ця робота їм не набридне. Управління натовпом кодерів вимагає певного набору навичок, іншого підходу та інших навичок. Ви маєте бути і політиком, і дипломатом, і логістом, і законодавцем стандартів, а також адміністратором та економістом. Ви керуєте ризиками, пов'язаними з проектом та людьми, а не технічними ризиками.
Згодом проект переходить із фази розумової роботи у фазу набору коду. Рано чи пізно виявляються вирішені майже всі складні проблеми на кшталт "Не знаю, що ще ми повинні зробити і як це потрібно зробити". Більшість невідомих моментів прояснюється. Настає час опрацьовувати деталі та забезпечувати роботу системи.
Обсяг роботи з набору коду збільшується в міру того, як зростає ваша клієнтська аудиторія, доводиться мати справу з новими інтерфейсами, розгортати систему внових місцях та забезпечувати кастомізацію, займатися адміністративними справами, підтримкою та проблемами відповідності правилам. Система зростає, але більшість проблем вже відомі та розв'язувані. Має бути вивчити масу чужого коду, чомусь з нього навчитися, а щось скопіювати. Для цього потрібні люди, які вміють швидко схоплювати суть роботи та швидко друкувати.
Мислення та друкування
Отже, і розумова робота, і набір коду – рівнозначні частини розробки програмного забезпечення.
У статті "Програмування - не просто набір тексту" Брендан Енрік пояснює, чому парне програмування дійсно працює. Справа в тому, що така методологія допомагає людям одночасно займатися і мисленням і друкуванням коду.
Обидва партнери при цьому думають, але про різні речі. У одного з розробників завжди є під рукою клавіатура, і він зосереджений на тому, як висловити в коді всі необхідні ідеї (і досить швидко). Він набирає код, і розмірковує саме про цей код, а не про структуру програми.
Другий партнер, не зайнятий набором коду, весь цей час також мислить. Він простежує в думці той шлях, який у нього на очах проходить наборщик, не замислюючись при цьому про синтаксичну сторону коду. Правильність синтаксису має забезпечити саме його партнер. Програміста, що працює без клавіатури, можна порівняти зі штурманом. Він стежить за тим, щоб програма залишалася на правильному шляху і йшла оптимальним шляхом до вирішення завдання».
Майстерність розробника не зводиться до вміння набирати код, як майстерність наборника не обмежується швидкістю натискання клавіші. Зрозуміло, програміст повинен досконало володіти фундаментальними навичками програмування: добре знати мову, розбиратися в інструментах та вміти нимикористуватися, вміти орієнтуватися в коді і добре його писати і, звичайно, швидко керуватися з клавіатурою. Не можна недооцінювати важливість швидкого набору. І при цьому не слід писати код надмірно швидко – швидкість набору не повинна заважати мисленню.