Readme Driven Development

RDD - це вкрай проста практика. І тут «DD» може означати «хвилина на освоєння і все життя для майстерності». Але, на щастя, не в цьому випадку.

Пишіть Readme в першу чергу. Ось в принципі і все. Але чому?

Кожен раз, коли ви починаєте програмний проект, будь то ваш особистий проект або належить компанії на яку ви працюєте. Ви повинні (по можливості) прагнути писати зрозумілий, підтримуваний код, який можна використовувати багаторазово.

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

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

Скромняга Readme

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

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

Якщо ви напишете свій Readme, до того як приступити до написання коду, ви отримаєте кілька крутих переваг:

1. Ви отримаєте повний огляд того, яку функціональність ви повинні реалізувати, і як ви можете її забезпечити за допомогою публічного API. У цей момент, до того як ви почали писати код, ви можете легко змінювати архітектуру проекту.
2. Коли ви почнете писати код, ви будете мати чітке уявлення, що і як саме має бути реалізовано.
3. Readme також може виступати в якості індикатора для вас самих та інших людей про прогрес у розробці проекту.
4. Якщо ви працюєте в команді з іншими розробниками, у вас буде майже ідеальна специфікація. І інші розробники зможуть підключатися до проекту з меншим страхом того, що специфікація може змінитися в процесі розробки.
5. Обговорення дуже важливі. І набагато легше обговорювати, те що записано. Легше змінити Readme ніж нескінченно сперечатися про те, як щось має працювати, коли і якщо ви до нього доберетеся.
6. Як правило, найбільш активна і захоплююча частина проекту на початку. Це найкращий час, щоб написати невеликий обсяг документації, який згодом буде служити Вам та іншим людям. Пізніше написання документації завжди затягується і я дуже здивуюся, якщо в підсумку, ви будете пам'ятати всі деталі реалізації і відомі проблеми.
7. Змінюються навіть найбільш продумані проекти, сподіваюся, що ці зміни будуть відбуватися не через будь-які проблеми. а для додавання нової функціональності. Але вони все одно неминучі і як правило відбуваються шляхом розвитку. Єдиний документ (сподіваюся, в системі контролю версій) може виступати ідеальним середовищем для зв'язку між змінами у міру того, як вони відбуваються. Також варто відзначити, що записувати зміни в міру того як вони відбуваються набагато простіше, ніж намагатися згадати їх все потім.

Додавання RDD до існуючого проекту вимагає окремої статті. Але на даний момент, сподіваюся, у вас з'явилася їжа для роздумів.