Readme Driven Development

RDD is an extremely simple practice. And here “DD” can mean “a minute for mastering and the whole life for mastery”. But, fortunately, not in this case.

Write the Readme first. That's basically it. But why?

Whenever you start a software project, whether it is your personal project or company owned by you. You should (if possible) strive to write clear, supported code that can be reused.
')
Everyone has their own point of view about what tools, practices and processes contribute to the improvement of the software. At the end of the day, your program should still work. It's easy to forget if you focus too much on how to finish it or use all the beautiful solutions .

The work of the program is not only about its code. If no one can use the program, because it does not know how, then it does not matter whether it contains a bunch of errors or does not contain any.

Skromnyaga Readme

Readme is the most important file in the entire project. It should contain a brief overview of the project’s tasks (its purpose, why it was created), installation instructions, known problems, and a sufficiently detailed description of what needs to be done to quickly start using the program for people who have never used your software before. .

Don't get me wrong, the Readme is not all the documentation that you may need. However, you may be surprised to learn that the small Readme covers the vast majority of problems and questions of those people who read it.

If you write your Readme, before starting to write code, you will get some cool advantages:

1. You will get a complete overview of what functionality you need to implement, and how you can provide it with a public API. At this point, before you start writing code, you can easily change the architecture of the project.
2. When you start writing code, you will have a clear idea of ​​how and how exactly it should be implemented.
3. The readme can also act as an indicator for you and other people about the progress in project development.
4. If you work in a team with other developers, you will have an almost perfect specification. And other developers will be able to connect to the project with less fear that the specification may change during the development process.
5. Discussions are very important. And it is much easier to discuss what is written. It is easier to change the Readme than arguing endlessly about how something should work , when and if you get to it.
6. As a rule, the most active and exciting part of the project at the beginning. This is the best time to write a small amount of documentation that will later serve you and other people. Later writing documentation is always delayed and I would be very surprised if in the end, you will remember all the implementation details and known problems.
7. Even the most thoughtful projects are changing, I hope that these changes will not occur due to any problems. and to add new functionality. But they are still inevitable and usually occur through development. A single document (hopefully, in a version control system) can be the ideal medium for communication between changes as they occur. It is also worth noting that recording changes as they occur is much easier than trying to remember them all later.

Adding RDD to an existing project requires a separate article. But at the moment, I hope you have some food for thought.