Readme Driven Development
Пишіть Readme в першу чергу.Ось у принципі і все. Але чому?
Щоразу, коли ви починаєте програмний проект, будь то ваш особистий проект або належить компанії на яку ви працюєте. Ви повинні (по можливості) прагнути писати зрозумілий код, який можна використовувати багаторазово.
У кожного є своя думка про те, які інструменти, практики та процеси сприяють поліпшенню програмного забезпечення. Наприкінці дня ваша програма, як і раніше, має працювати. Це легко забути, якщо занадто сильно зосередитися на тому, щоб закінчити її або використати всікрасиві рішення.
Робота програми це не тільки про її код.Якщо ніхто не може використовувати програму, тому що не знає як, то не важливо чи містить вона купу помилок чи не містить жодної.
Скромняга Readme
Readme – це найважливіший файл у всьому проекті. Він повинен містити короткий огляд завдань проекту (його призначення, навіщо він створений), інструкції зі встановлення, відомі проблеми та досить докладний опис того, що потрібно зробити, щоб швидко почати користуватися програмою, для тих людей, які ніколи до цього не користувалися вашим програмним забезпеченням .
Не зрозумійте мене неправильно, Readme це не вся документація, яка тільки може вам знадобиться. Однак, ви можете здивуватися, дізнавшись, що невеликий Readme охоплює переважну більшість проблем і питань тих людей, які його читають.
Якщо ви напишете свій Readme, перш ніж приступити до написання коду, ви отримаєте кілька крутих переваг:
- Ви отримаєтеповний огляд того, яку функціональність ви повинні реалізувати, і як ви можете забезпечити її за допомогою публічного API. У цей момент, перш ніж ви почали писати код, ви можете легко змінювати архітектуру проекту.
- Коли ви почнете писати код, ви матимете чітке уявлення, що і як саме має бути реалізовано.
- Readme також може виступати як індикатор для вас самих та інших людей про прогрес у розробці проекту.
- Якщо ви працюєте в команді з іншими розробниками, ви матимете майже ідеальну специфікацію. Інші розробники зможуть підключатися до проекту з меншим страхом того, що специфікація може змінитися в процесі розробки.
- Обговорення дуже важливі. І набагато легше обговорювати те, що записано. Легше змінити Readme ніж нескінченно сперечатися про те, якщось має працювати, коли іякщови до нього дістанетеся.
- Як правило, найбільш активна та захоплююча частина проекту на початку. Це найкращий час, щоб написати невеликий обсяг документації, який згодом служитиме Вам та іншим людям. Пізніше написання документації завжди затягується і я дуже здивуюся, якщо в результаті ви пам'ятатимете всі деталі реалізації і відомі проблеми.
- Змінюються навіть найпродуманіші проекти, сподіваюся, що ці зміни відбуватимуться не через якісь проблеми. а додавання нової функціональності. Але вони однаково неминучі і зазвичай відбуваються шляхом розвитку. Єдиний документ (сподіваюся, у системі контролю версій) може бути ідеальним середовищем для зв'язку між змінами у міру того, як вони відбуваються. Також варто відзначити, що записувати зміни в міру того, як вони відбуваються набагато простіше, ніж намагатися згадати їх все потім.
Ви можете допомогти і перевести небагато коштів на розвиток сайту