Code Design Process?

Question

I am going to be working on a project, a web application. I was reading 37signals getting real pamphlet online (http://gettingreal.37signals.com/), and I understand the recommended process to build the entire website. Brainstorm, sketch, HTML, code.

They touch on each process lightly, but they never really talk much about the coding process (all they say is to keep code lean). I've been reading about different ways to go about it (top to bottom, bottom to top) but I dont know much about each way. I even read somewhere that one should write tests for the code before they actually write the code??? WHAT?

What coding process should one follow when building an application.

if its necessary, I'm using PHP and a framework.

Answer 1

According to the Test-Driven-Development methodology, you should write tests before you write you code. This helps make the code cleaner, more modular, etc - and lets you test the code at any point to make sure it works properly.

In practice, using TDD is a choice left up to you. I'll admit that I usually only use TDD when developing libraries or code that makes heavy use of algorithms. But there is a fair amount that can be automatically tested in a web app.

In any case, what they may be getting at is that you should start your code off small, just coding up what you need. Then iterate, and write more code as necessary, testing as you go. The simpler your code is, the easier it will be to test and extend over its lifetime.

Answer 2

So you have looked at everything up to the coding process and you have an architecture and a design as well mock-ups of the web pages.

Pick the functionality that will give you the most bang for the buck. (Show something to the customer, which can be management or the people that are buying this from you.)

Start coding that piece of functionality and make sure it fills the requirements and do not introduce any future possible hooks. A lot of time gets wasted trying to guess what people may want in the future with the "programmers crystal ball".

The code needs to follow best practices for that language, hopefully somebody knows the language you are developing in well enough to guide you.

As you are done with each function point do a code review, review early and often in the beginning of the project.

Once you are done with coding the initial piece and the customer is happy, you can start on new pieces.

If you find common pieces of functionality, whether they are horizontal (domain specific) or vertical (architecture specific) then you need to refactor them. Remember, no cut and paste.

Answer 3

Lean code means you are not writing code just because you are a programmer. You are writing only enough code to get the job done. Any extra code is just wasted time and money. If you find you are adding code to "use later". Stop. Later rarely comes and applications live long lives. That code you added for later only confuses later. Think of it this way. Every piece of paper on your desk must be handled. Every line of code must be dealt with.

I have read their book "Getting Real". I do not agree with everything. Yet, much of what they say does apply to web development and wouldn't apply to desktop or device applications. It seems a lot of the content, especially near the end, is just noise to fill a book.

How I Generate Lean Code

• Document (for yourself) what you need to do and your understanding of what needs to be done. Be absolutely clear on your understanding. Better to get a yes/no now then a bug, or worst, a design issue, later that will cost you weeks, which always results in "hacked" code.

• Generate a rough draft of a brief user-guide. Even if you are the only one who will read it. Do this with pencil and paper. Do not waste time with a word processor. You will waste more time "formatting" then writing content. If you cannot write it in words, how can you code it? It does not have to be pretty. Ugly is okay.

• Generate any kind of documentation with pencil and paper as much as possible. (Hey, didn't I already say that.) It is much faster, it is clear, users can write on it, you can copy it, hang it on the wall, and so on. More importantly, you can erase it and start over with the user right there. Did I mention it is much faster.

• Perform personal code reviews. One good method is to compare each file before checking into source control. I guarantee you will find bugs, items your forgot to do, and so on. This is a good time to clean up the code and generate any user or technical documentation and last minute testing.

For instance, I spent a day creating an Excel workbook to document a model I needed to create. I did this for myself. The model was already designed by specialists (on paper). I found, I should say Excel found, a circular reference. I reported this but was told that the model has been worked out carefully over the past month and the problem was my understanding. Two months later, fixing that "circular reference" costs us two weeks. We barely made the deadline. What could have been resolved in eight man-hours, costs us over sixty man-hours and lots of stress. Yet, because my code was "lean" the fix was only a few lines of code to a small table function.

Most programmers will code first. Most developers with document first. In general, every minute documenting early will save you ten minutes later. (Read "Code Complete".) Yet, do not forget to "get real". Your job is not to code, but to build solutions. Think of it this way, a writer's job is not to write but to create a document that someone will read. He doesn't add a chapter just because he or you might need it later. He continually has to make a decision on what to include or exclude to reach his reader. Better to take a few minutes to make a decision about code then spend a day coding, only to realize the code is not needed.

---

Generally, I do not write Test-Driven-Development (TTD) code. I find you end up writing a lot of code for no reason, instead of providing a solution. Before I get "flamed", I always write TTD on paper first. If I cannot work something out, I will create a "discard" project and write some code. If I find I have to dig deeper, I create a "wip" (Work-In-Progress) project, and if that fails, I will finally create an actual Test project. With that said, as Justin Ethier mentions, if I am writing libraries or core functions for an application, I always create a Test project.

Tidbit

For an application, I once created and embedded a RSS Pane control that downloaded company financial information from Google. My supervisor requested this feature to "wow" the managers before a demo. It did. Everyone absolutely loved it. While working with a company, users would get instant news alerts specifically for that company. It took me four hours to create and implement, which I did right before the demo. Yet, because this was a feature the users did not ask for, they constantly complained that I was wasting time implementing unnecessary features, especially features they did not ask for when I couldn't provide the features they requested. (Which was not my decision.) About two months later this control started throwing exceptions. It took me two days to troubleshoot and fix. This feature was a great success, but imagine the problems if it wasn't.