Ідеальний програміст: тези
“Ідеальний програміст” Роберта Мартіна давно став керівництвом з професіоналізму у сфері IT та однією з основоположних праць у сучасній розробці, нарівні з “Чистим кодом”, “Чистою архітектурою” та “Чистим еджайлом”.
Про професіоналізм
Професіоналом ми називаємо того, хто працює швидко, але без поспіху, хто розумно оцінює ситуацію та виконує свої зобов’язання. Професіонал знає, коли треба говорити “ні”, але чесно намагається сказати “так”.
Непрофесіонали не несуть відповідальності за роботу, що виконується — вони залишають відповідальність своїм роботодавцям. Якщо непрофесіонал робить помилку, то сміття за ним прибирає роботодавець. Але якщо помилка відбувається професіоналом, то усувати наслідки доводиться йому самому .
Фахівці часто роблять героїчні справи, але не тому, що хочуть бути героями. Професіонали стають героями, коли вони добре виконують свою роботу, без порушення термінів та бюджету.
Професіоналізм передається від однієї людини до іншої. Старші навчають молодших. Колеги обмінюються між собою. Старші, спостерігаючи за молодшими, бачать його збоку та навчаються заново. Професіоналізм поширюється наче свого роду інтелектуальний вірус. Не можна переконати людей бути фахівцями. Прийняття професійного ставлення не так раціональним, скільки емоційним рішенням. Стати зразком для наслідування. Ви стаєте професіоналом самі та показуєте свій професіоналізм іншим. А потім нехай концепція сама зробить усю роботу.
Про тестування
Деякі фахівці використовують службу контролю якості для виявлення помилок. Вони розраховують на те, що контроль якості виявить помилки та поверне їх список розробникам. Передавати на контроль якості код, працездатність якого ви не можете гарантувати непрофесійно. Напишіть модульні тести, які можна виконати будь-якої миті, і запускайте їх якнайчастіше. Кожен написаний вами рядок коду має бути протестований. Крапка.
Група розробки повинна прагнути до того, щоб контроль якості не виявляв жодних дефектів. Щоразу, коли служба контролю якості щось виявляє, це має стати тривожним сигналом для розробників. Вони повинні запитати себе, як це сталося, і вжити заходів для запобігання таким інцидентам у майбутньому.
Про автоматизацію тестування
Час налагодження обходиться фірмі рівно таку ж суму, що час написання коду. Ви як фахівець повинні прагнути по можливості наблизити час налагодження до нуля.
Витрати на проведення автоматизованих тестів настільки малі в порівнянні з витратами на ручне тестування, що написання сценаріїв, що запускаються вручну, не має жодного економічного сенсу. Професійні розробники вважають за свій обов’язок простежити за тим, щоб приймальні тести проводилися в автоматизованому режимі. Не варто розглядати ці тести як зайву роботу – краще розглядайте їх як значну економію часу та грошей. Тести запобігають помилкам у реалізації системи та допоможуть дізнатися, коли ваша робота закінчена.
ПРО TDD
Три закони TDD:
- Новий робочий код пишеться тільки після написання модульного тесту, який не проходить.
- Ви пишете такий обсяг коду модульного тесту, який необхідний для того, щоб цей тест не проходив (якщо код тесту не компілюється, вважається, що він не проходить).
- Ви пишете такий обсяг робочого коду, який необхідний для проходження модульного тесту, який в даний момент не проходить.
TDD – вибір професіоналів. Ця методологія підвищує впевненість, надає сміливості розробникам, знижує кількість дефектів, формує документацію та покращує архітектуру.
TDD – не релігія і не панацея. Виконання трьох законів не гарантує жодної з перерахованих переваг. Поганий код можна написати навіть за попереднього написання тестів.
Про чистоту коду та архітектури
Ніщо не має більш ґрунтовного та довгострокового негативного ефекту на продуктивність групи програмістів, ніж бруд у програмному коді. Рух вперед по багнюці (коли ви знаєте, що це бруд) є найгіршим з різновидів інверсії пріоритетів. Рухаючись вперед, ви обманюєте себе, обманюєте вашу групу, обманюєте свою компанію та замовників. Ви кажете їм, що все буде гаразд, хоча насправді ви ведете їх до загальної катастрофи. Професіонал не піддається спокусі влаштувати бруд у коді, щоб швидко рухатися вперед. Брудно – завжди означає повільно!
Чистий код простіше зрозуміти, простіше змінювати та простіше розширювати. Зі спрощенням коду ймовірність дефектів стає ще нижчою. Відбувається стабільне покращення кодової бази — замість «загнивання коду», такого звичного для нашої галузі.
Про чисту архітектуру
Щоразу під час роботи з модулем слід потроху удосконалювати його структуру. Кожне читання коду має призводити до доопрацювання структури.
Додавання функціональності на шкоду структурі – остання справа. Структура коду забезпечує його гнучкість. Порушуючи структуру, ви руйнуєте майбутнє коду. Усі програмні проекти базуються на фундаментальному припущенні про простоту змін. Якщо ви порушуєте це припущення, створюючи негнучкі структури, то ви тим самим підриваєте економічну модель, закладену в основу всієї галузі.
Про довіру до своїх робочих методів
Щоб зрозуміти, у що ви по-справжньому вірите, спостерігайте за собою у кризовій ситуації. Якщо під час кризи ви не відхиляєтеся від своїх робочих методів, ви дійсно переконані в їх ефективності. Якщо ваш код залишається чистим у звичайний час, а в кризу ви розводите в ньому бруд, значить ви не вірите, що бруд уповільнює вашу роботу.
Виберіть методи, з якими ви комфортно відчуваєте себе в кризовій ситуації. А потім використовуйте їх постійно. Не змінюйте свою поведінку у напруженій ситуації. Якщо ваші методи дійсно оптимальні, то вони повинні дотримуватися навіть у найважчі часи. Якщо ви потрапили у скрутну ситуацію, довіряйте своїм методам.
Про саморозвиток
За свою кар’єру ви відповідаєте самі. Ваш роботодавець не повинен піклуватися про вашу популярність на ринку праці. Він не повинен навчати вас, відправляти вас на конференції або купувати книги. Всім цим повинні займатися ви самі .
Читайте книги, статті, блоги, твіти. Відвідуйте конференції та збори власних груп. Беріть участь у дослідницьких групах. Вивчайте те, що лежить за межами звичної зони. Якщо ви програміст .NET – вивчайте Java. Якщо ви програмуєте на Java, вивчайте Ruby. Якщо ви програмуєте на C – вивчайте Lisp. А якщо вам захочеться серйозно попрацювати мізками, вивчайте Prolog та Forth!
Якщо ви не подбаєте про розширення власного кругозору, це може призвести до небажаного звуження резюме та менталітету.
Виконуйте громадсько-корисну роботу, беручи участь у проекті з відкритим кодом. Професійні програмісти тренуються особисто. Ваш роботодавець не зобов’язаний піклуватися про підтримку вашої кваліфікації або розширення вашого резюме.
Про передачу досвіду
Професійні розробники навмисно намагаються разом програмувати, разом тренуватись, разом проектувати та планувати. Найкращий спосіб чогось навчитися — вивчати інших. Факти запам’ятовуються найшвидше тоді, коли ви повинні їх повідомити іншим людям, за яких ви відповідаєте. Таким чином, основну користь від викладання отримує передусім викладач.
Відповідальність за навчання менш кваліфікованих програмістів покладається на їхніх досвідчених колег. Навчальних курсів недостатньо. Книг недостатньо. Ніщо не приведе молодого розробника до високої продуктивності швидше, ніж його власне бажання у поєднанні з ефективним навчанням старших товаришів.
Про відповідальність
Перший обов’язок професійного програміста – дбати про інтереси своїх роботодавців. Це означає, що ви повинні спілкуватися з вашими начальниками, бізнес-аналітиками, тестерами та іншими учасниками групи, щоб глибоко розуміти комерційні цілі проекту. Професійний програміст повинен виділити час вивчення комерційної боку справи.
Професіонал завжди допомагає бізнесу знайти спосіб досягнення його цілей, але він не завжди приймає він зобов’язання, прийняті за нього.
Професіонали не беруть на себе зобов’язань, якщо вони не впевнені в можливості їх виконання. Зобов’язанням властива визначеність. Інші люди приймають ваші зобов’язання та використовують їх як основу для побудови власних планів. Порушення зобов’язань обернеться величезним збитком для вашої репутації; це прояв непорядності, лише трохи кращий за відкриту брехню.
Професіонали проводять чітку різницю між оцінками та зобов’язаннями. Вони не беруть на себе зобов’язань, доки не будуть твердо впевнені в успіху. Також вони стежать за уникненням неявних зобов’язань. Вони наскільки можна чітко обумовлюють ймовірнісний розподіл своїх оцінок, щоб керівники могли будувати відповідні плани.
Професіонал зобов’язаний допомогти своїй групі створити програму настільки якісну, наскільки це можливо. А це означає, що всі повинні приділяти увагу можливим помилкам та промахам колег та спільно працювати над їх виправленням.
Кожен професіонал повинен розуміти предметну область програмованих ним рішень. Бути експертом не обов’язково, але до вивчення теми необхідно ставитись відповідально. Найгірший різновид непрофесіоналізму — просто програмувати за специфікацією, не розуміючи, чому ця специфікація підходить для вирішення свого завдання. Ви повинні мати достатні знання в предметній області для того, щоб розпізнати та виправити можливі помилки у специфікації.
Про обіцянки
Ретельно вибирайте формулювання, які ви використовуєте у своїх обіцянках, тому що, за словами, часто можна судити про подальший перебіг подій. Якщо вам не вдається підібрати потрібні слова, швидше за все, ви недостатньо відповідально ставитеся до сказаного або не вірите у його здійсненність.
Обіцяйте тільки те, що знаходиться під повним контролем. Якщо кінцева мета залежить від когось іншого, обіцяйте лише конкретні дії, які сприяють досягненню кінцевої мети. Якщо ви не можете виконати свою обіцянку, дуже важливо якнайшвидше повідомити про це того, кому ви обіцяли.
Коли говорити “так” і “ні”
Професіонали говорять правду наділеним владою. У них достатньо сміливості, щоби сказати «ні» своїм начальникам.
Як сказати «ні» начальнику? Це ж ваш начальник! Хіба ви не повинні робити те, що каже начальник? Ні! Говоріть “ні”, якщо ви професіонал. Рабам забороняється говорити “ні”. Наймані працівники неохоче кажуть «ні». Але професіоналу належить говорити «ні». Більше того, добрим керівникам дуже потрібні люди, у яких вистачає сміливості сказати «ні». Тільки так можна справді чогось досягти.
Професіонал не повинен відповідати «так» на все, що від нього вимагають. Проте він має докласти максимум зусиль до того, щоб це так стало можливим. Коли професіонали говорять так, вони використовують такі формулювання, щоб у співрозмовника не виникало сумнівів у надійності їхніх обіцянок.
Про виконання своєї роботи
Професійні розробники мають лише одне визначення: виконано — значить виконано. Зроблено — це означає, що весь код написаний, всі тести пройдені, служба контролю якості та ключові учасники прийняли результат. Зроблено.
Найгірший із усіх видів непрофесіоналізму з боку програміста — це спроба видати недоробку за готовий продукт. Іноді це просто відкрита брехня, що досить погано. Але набагато небезпечніша інша ситуація — спроби підвести раціональну основу під нове визначення «готовності».
Ця хвороба заразна. Якщо одному програмісту така поведінка сходить з рук, інші бачать і наслідують його приклад. Один з них розширює визначення «готовності» ще далі, і всі інші наслідують його приклад. Коли група потрапляє до цієї пастки, начальство чує, що все йде нормально. Усі звіти про хід робіт показують, що роботу буде завершено до терміну. Ситуація нагадує пікнік сліпих на залізничних рейках: ніхто не бачить вантажний склад незавершеної роботи, що наближається, поки не буде занадто пізно.
Проблема хибної готовності вирішується створенням незалежного визначення готовності. Для цього слід доручити бізнес-аналітикам та фахівцям із тестування створити автоматизовані приймальні тести, без проходження яких продукт не може вважатися готовим. Тести мають бути зрозумілими для бізнесменів та ключових учасників проекту, не пов’язаних з технічною стороною.
Про аврали
Поспіх безглуздий. Ви не змусите програмувати себе швидше. Ви не змусите швидше вирішувати завдання. А якщо спробуєте — ви тільки уповільните роботу та влаштуєте хаос, який уповільнить роботу інших.
Щоб звести до мінімуму проблеми, пов’язані з відставанням, пам’ятайте про два найважливіші аспекти: раннє виявлення та прозорість. Найгірше, коли ви до останнього моменту запевняєте оточуючих, що роботу буде завершено вчасно, а потім підводьте всіх. Не робіть цього. Регулярно перевіряйте хід проекту по відношенню до кінцевої мети та уявіть три обґрунтовані кінцеві дати: найкращу, номінальну та гіршу.
На понаднормову роботу можна погоджуватися лише за виконання деяких умов: 1 — особисто ви можете її собі дозволити; 2 – аврал триватиме недовго, не більше двох тижнів, і 3 – у керівництва є резервний план на випадок, якщо ваші зусилля завершаться невдачею.
Про концентрацію
Професійні розробники навчаються керувати своїм часом так, щоб повною мірою використати свою ману концентрації. Ми пишемо код, коли резерв мани високий, а коли її залишається мало – займаємось іншими, менш творчими справами. Якщо ви витратите всю ману концентрації на зустрічі, то у вас залишиться менше ресурсів для програмування.
Професійні розробники управляють своїм графіком сну те щоб резерв мани концентрації досягав максимуму на той час, що вони вранці приходять працювати.
Після того, як мана піде, зберігати концентрацію силою волі неможливо. Ви можете писати код, але вам майже напевно доведеться переписувати його наступного дня.
Фізична концентрація допомагає відновити розумову, причому це більше, ніж проста перезарядка. Регулярні фізичні вправи підвищують потенціал інтелектуальної концентрації.
Якщо ви не можете достатньо зосередитися на своїй роботі, у вас вийде поганий код. У ньому буде багато помилок. Він матиме неправильну структуру. Він вийде заплутаним та непрозорим. Він не буде відповідати справжнім потребам замовника. Якщо ви втомилися або не можете зосередитися, не пишіть код.
Обов’язково стежте за сном, здоров’ям і способом життя, щоб ви могли щодня присвятити роботі вісім хороших годин.
Про взаємодію всередині команди
Про зустрічі
Зустрічі коштують приблизно $200 на годину на кожного учасника. Тут враховуються зарплати, премії, витрати використання приміщення тощо.
Професіонали знають, що зустрічі коштують дорого. Ви не повинні відвідувати кожну зустріч, на яку вас запрошують. Більше того, відвідувати дуже багато зустрічей непрофесійно. Отримавши запрошення, не приймайте його, якщо ваша участь не пояснюється негайною і значною необхідністю для поточної роботи.
Один із найважливіших обов’язків вашого керівника — утримувати вас від участі в зайвих зустрічах. Хороший керівник більш ніж охоче захистить вашу відмову від участі, тому що ваш час представляє для нього таку ж цінність, як і для вас.
Ви повинні ефективно управляти своїм часом. Якщо ви застрягли на зустрічі, яка лише марно витрачає ваш час, знайдіть спосіб ввічливо покинути цю зустріч. Якщо вас просять прийти на зустріч, переконайтеся, що ви знаєте, які теми будуть обговорюватися, скільки часу на них виділено і яка мета має бути досягнута. Якщо вам не вдається отримати чітких відповідей на ці запитання, ввічливо відмовтеся від участі.
Зустріч має відбуватися досить швидко: коротке обговорення щодо кожного елементу списку реалізації, після чого елемент або вибирається, або відхиляється. На жодний елемент не повинно йти більше 5 або 10 хвилин. Якщо буде потрібне докладніше обговорення, заплануйте його на інший час з частиною групи.
Остерігайтеся зустрічей, які проводяться лише для придушення розбіжностей та підтримки однієї зі сторін. Також уникайте зустрічей, на яких присутня лише одна зі сторін, що сперечаються.
Про роботу у групах
Одна з найгірших ознак неправильно функціонуючої команди — коли кожен програміст зводить стіну навколо свого коду і забороняє іншим програмістам торкатися його. Професійні розробники не забороняють колегам працювати зі своїм кодом. Працюючи з інших частин системи, вони вчаться друг в друга.
Професіонали поєднуються в пари, тому що це найкращий спосіб рецензування коду. Найефективніший і найдієвіший спосіб рецензування коду — участь у його написанні. Фахівці працюють разом.
Професіонали також поєднуються в пари, тому що це найкращий спосіб обміну знаннями. Професіонали не створюють «банки знань» — натомість вони вивчають різні аспекти системи та бізнесу, поєднуючись у пари.
Про “притерті” групи
Групи формуються не відразу. Між учасниками поступово налагоджуються стосунки. Вони вчаться працювати один з одним, дізнаються дивацтва, сильні та слабкі сторони своїх колег. Згодом учасники «притираються» один до одного.
У «притертій» групі є щось чарівне: вона здатна творити чудеса. Учасники розуміють один одного, підтримують та вимагають максимальної віддачі. Завдяки їхній взаємодії досягаються результати.
«Притерта» група разом планує, разом вирішує завдання, разом розбирається з проблемами та досягає результатів. Професійні фірми-розробники доручають проекти існуючим «притертим» групам, а чи не формують групи конкретного проекту.
“Притерта” група зазвичай містить близько дюжини учасників. До групи повинні входити програмісти, тестери та аналітики. І в неї має бути керівник проекту. Добре «притерта» група з 12 осіб може складатися із семи програмістів, двох тестерів, двох аналітиків та керівника проекту.
Створити добру групу складніше, ніж створити проект. Відповідно, краще формувати групи з постійним складом, які переходять від одного проекту до іншого і можуть займатися кількома проектами одночасно.