We need to consider
things as follows:
How Our Project is Laid Out on the File System
This would include the following:
How we handle third-party code
Coding style
How we are going to name our files
What we are going to store in our revision control
When (or how often) we are going to put our changes into revision control
What we need to be able to develop e.g. compilers, IDEs, etc.
All these need to be documented??”another word that can send developers running
for the hills! This may seem like a significant amount of work to do before we even
think about our first line of code, but it will save us time in the long run. In addition,
once we have done this once, we will be able to reuse some or all of these details for
other projects to get a head start next time.
Developers Are Users Too
We need to turn our preparation work into a best-practices guide for our developers.
They are the users of our system, and they need a user guide to allow them to
use it as we intend it to be used. Investing the time in preparing the system and
its documentation means that more time can be spent on actual development.
By providing our developers, or rather users, with clearly defined standards and
practices we remove all ambiguity and reduce friction that could delay our project.
Pages:
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32