Commits

Herbert Breunung committed 3ed2808

fix latest chapter

  • Participants
  • Parent commits 993a6d4
  • Branches sp3

Comments (0)

Files changed (1)

File doc/CompleteProgramming.pod

 
 As stated several times: CP doesn't recognizes a clear distinction between writing
 documentation or building the program. Docs are been written as a first step of
-programming and we write also code to document ideas. That might include writing
-a comment that marks and explains what is expected to happen at that place.
-But I mean also creating files, inserting classes, methods, attributes - even
-variables that have a name and purpose we already could agree upon.
+programming and we write code to document ideas. That might include writing comments,
+that marks and explains what is expected to happen at that place. But I mean also
+creating files, inserting classes, methods, attributes - even variables,
+that have a name and purpose we already could agree upon.
 
 First of all this makes ideas very, very concrete. If you see your ideas like that,
-you get a much better sense how the program will be look like - much less boring
-than pages of UML - diagrams. Spotting design flaws or misleading names become
-easy - plus the compiler helps to find out, it thats even doable. Don't neresmae
-the power of names. They are equally important as the logical structure helping
-to communicate the inner workings - the intentions of the architect. In CP we
-spend some time just contemplating dummy code to finde the right hierarchies and
-names. Maybe other people don't call that programming, but we certainly do.
+you get a much better sense how the program will be look like. Spotting design
+flaws or misleading names becomes easier - plus the compiler tells if the plan is
+even doable. Don't underestimate the power of names. They are equally important as
+the logical structure, helping to communicate the inner workings and the intentions
+of the architect. In CP we spend some time just contemplating dummy code to find
+the right hierarchies and names.
+Maybe other people don't call that programming, but we certainly do.
 
 Secondly: having this dummy code in place (just do it for the current stage),
-team member will comprehend the current goals and where to put their work into.
-Sources are telling the current state of planning and also communicate changes.
-This also means: if the architect changes his mind - he has to clean up the mess
-the change created. Of course nobody is allowed to check in code that breaks tests.
+team member will comprehend the current goals and where to put their work into
+much clearer than from text desctiptions or boring UML-diagrams. Sources will tell
+the current state of planning and also communicate changes. This also means:
+if the architect changes his mind - he has to clean up the mess the change created.
+Of course nobody is allowed to check in code that breaks tests.
 
 Only completed features with their tests as one commit are acceptable. This means:
+at this point we use short lived feature branches, that pick the the code from a
+use case prototype and bring it into the program.
 
-
-
-
-branches
-cycles
-tested code
+   * tested code
    * documentation (user, programmer, comments)
    * prototypes
    * logic (main program)