What you could have learned in this course: 3 x 3
I Programming is a People Discipline
----------------------------------------
1. Software is developed so that other programmers can read
it. (It accidentally runs on computers.)
2. Producing software means reasoning about deep logical
artifacts. Only a few of our thoughts (e.g., the grammatical
correctness of our programs, their type consistency) can be
checked with tools. But we can't reason on our own all the time
and expect to get every (little) thing right. The best way to
proceed is to work with others, all the time. Continuous
reviews (i.e., pair programming) and discrete reviews (design
walks, code walks) are the best solution to this dilemma.
3. Software is for customers. They change their mind all the time,
so software developers must learn to read their customer's
mind.
II Accept Change
----------------------------------------
We can't read our customer's mind. So what do we do?
1. Establish a base for the core of the product and develop small
increments after getting a customer's feedback.
2. Have the customer help you with the specification (and even
implementation) of "acceptance tests" early on. If you develop
with small increments in time, this is doable and saves you
time.
3. Accept reorganization of everything in your world as a given.
Refactor tests and software as soon as there is a problem.
III Developing Software
----------------------------------------
1. Learn to doodle so you can discuss ideas about software without
staring at plain code. Remember that there are structural
relationships and action sequences. (Well, there is more but
these are a good start.)
Use the doodles to write concise documentation and/for
interfaces first.
2. Write automated test suites for all your units. You can even
use insight from your programming to enhance the tests.
3. Use well-known patterns to code. Patterns help you to extend
your product with functionality without modifying working code
too much.
Consider something simple like this.
You have some working (i.e., it works for all the tests) code
base A. It provides some interface I to make its functionality
available. Your colleague has a need in code base B for all the
functionality in A, but unfortunately he can only deal with
interface J.
+------------+ +------------+
| | | |
| Code A | o Code B |
| exists = J o exists |
| works = I o works |
| = | |
| | | |
+------------+ +------------+
+------------+ +------------+
| Tests | | Tests |
| for A | | for B |
+------------+ +------------+
If you were to change A to implement J (in addition or instead
of I), you would jeopardize your code. Right now it works for
all the tests and who knows what happens when you edit
it. Ditto for B.
So you use an adapter pattern. You implement a module X that
bridges the gap between I and J and you don't touch either A or
B. You just make them work together with a bridge. Better
still, if an error shows up, the likelihood that it is in A or
in B is much lower than that it is in your new code. In other
words, implementing a bit of extra code also helps you with
debugging.
+------------+ +------------+ +------------+
| | | | | |
| Code A | | Adapter X o o Code B |
| exists = = o J o exists |
| works = I = o o works |
| = = | | |
| | | | | |
+------------+ +------------+ +------------+
+------------+ +------------+
| Tests | | Tests |
| for A | | for B |
+------------+ +------------+