Майстерність програмування

Кент Бек - розробник програмного забезпечення, творець таких методологій розробки ПЗ як екстремальне програмування (XP) і розробка через тестування (TDD); в даний момент працює на Facebook. Вашій увазі пропонується переклад начерків ідей про те, як можна було б зробити свою роботу ефективнішою. Поділ програмістів на майстрів і підмайстрів, що використовується протягом статті, взято Кентом Беком з книги «Програміст-прагматик» Ендрю Ханта і Девіда Томаса.

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

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

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

Час

• Розбивка завдань (slicing). Візьміть великий проект, поріжте його на «тонкі» шматочки і переставте їх між собою так, щоб вони влаштували вас з урахуванням ваших обставин. Я завжди здатний розділити проект на ще більш дрібні завдання, і я завжди можу знайти нову перестановку цих завдань, яка буде відповідати іншим потребам.
• Одна справа за раз. Ми настільки зосереджені на ефективності, що намагаємося зменшити кількість циклів зворотного зв'язку в спробі зменшити «оверхед» (накладні витрати). Це призводить пізніше до появи скрутних випадків налагодження, передбачувана вартість якої буде більшою, ніж накладні витрати від циклу, якого ми уникли раніше.
• Зробіть, щоб це запрацювало; зробіть, щоб це було написано правильно; зробіть, щоб це працювало швидко (make it run, make it right, make it fast) (Тут слід навести приклади «Однієї справи за раз», «Розбивки завдання» і «Простоти змін»)
• Простота змін. Коли вам зустрічається складна зміна, спочатку зробіть її простою (обережно: це може виявитися важкою справою - не виключений рефакторинг і виплата технічного боргу), потім зробіть просту зміну (використовуйте розбивку завдань, зміну однієї справи за раз, концентрацію та ізоляцію). Найчастіше тут мається на увазі розбивка завдання на більш прості.
• Концентрація. Якщо ви хочете змінити декілька елементів, спочатку перетворите свій код так, щоб зміна була потрібна лише в одному елементі.
• Ізоляція. Якщо вам потрібно змінити тільки частину елемента, виведіть цю частину, щоб змінювався весь поделемент цілком.
• Вимірювання базового рівня (baseline measurement - точне вимірювання функціонування процесу перед тим, як буде здійснено будь-яку зміну). Починайте проекти з вимірювання поточного стану світу. Це йде врозріз з нашими інстинктами інженера, що зумовлюють відразу ж щось «фіксити» - але тільки після того, як ви проведете базове дослідження проекту, ви зрозумієте, чи дійсно ви щось виправляєте.

Навчання

• Знайте, що хочете зробити. Перед запуском коду, сформулюйте явне передбачення того, що станеться.
• Конкретні гіпотези. Якщо програма погано поводиться, точно і ясно висловіть думку про те, що по-вашому в ній не так, перш, ніж зробити зміну. Якщо у вас є одна або більше гіпотез, вам допоможе диференційна діагностика.
• Прибирайте сторонні деталі. Під час репортування, знайдіть найкоротший шлях з потрібних кроків для його відтворення. Коли ізолюєте порожній, знайдіть мінімальний тестовий кейс. Коли використовуєте нове API, починайте з найпростішого прикладу. «Вся ця дурниця не має значення» - дороге припущення, яке може обернутися проти вас, коли в підсумку щось піде не так. Приклад: якщо ви бачите порожній у мобільній програмі - спробуйте відтворити його за допомогою curl.
• Пробуйте різний масштаб. Вільно переміщуйтеся між рівнями «масштабування» проекту. Можливо, ви маєте справу з проблемою проектування, а не тестування. Можливо, проблема пов'язана з людьми, а не з технологією [читерство, оскільки це твердження завжди справжнє].

За межею логіки

• Симетрія. Речі, які з вигляду майже однакові, можна розділити на частини, які ідентичні, і частини, які точно (і чітко) різні.
• Естетика. Краса - це величний схил, на який буває так важко підійматися. Не дивно, що нітрохи не менше полегшення дає зневагу нею (наприклад, вбудовування купи функцій в один гігантський шматок коду, розібратися в якому вже не представляється можливим).
• Ритм. Очікування правильного моменту допомагає зберегти енергію і уникнути безладу в роботі. Коли прийде час діяти - діяти слід інтенсивно.
• Компроміси. Всі рішення схильні до компромісів. Важливіше знати, чим обґрунтовується прийняття рішення, ніж робити вибір просто тому, що він потрібен прямо зараз (в останньому випадку, замість розуміння загальної картини вам доведеться весь час згадувати, які конкретно вибори ви робили в минулому, щоб відштовхуватися від них в сьогоденні).

Ризик

• Список розваг. Коли до вас «по дотичній» приходять «ліві» ідеї, просто запишіть їх і швидко повертайтеся до роботи. Перегляньте цей список ідей трохи пізніше - після того, як у поточній справі ви досягнете місця, де можна зупинитися.
• Підгодовуйте ідеї. Ідеї схожі на дрібних птахів - їх також легко злякати; і якщо лякати їх регулярно, то вони перестануть прилітати до вас. Коли у вас з'являється ідея, «погодуйте» її трохи. Переконайтеся в неспроможності ідеї (тобто інвалідуйте її) настільки швидко, наскільки зможете - але обґрунтовуйте свою відмову взятися за неї за допомогою даних, а не через брак самооцінки.
• 80/15/5. Витрачайте 80% вашого часу на роботу з низьким рівнем ризику/достатньою віддачею. Витрачайте 15% вашого часу на роботу з високим рівнем ризику/з високою віддачею. Витрачайте 5% вашого часу на те, що не дає вам спокою, незважаючи на потенційну віддачу. Навчайте наступне покоління робити 80% вашої роботи. До того часу, коли хтось готовий взяти цей вантаж на себе, один з ваших 15% експериментів (або, що трапляється рідше, один з 5% експериментів) відплатить результатом і стане вашими новими 80%. Потім повторіть все спочатку.

Ув'язнення

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