目錄文檔
所有的目錄下都需要具有README文檔，其中包括：
該目錄的功能及其包含內(nèi)容
一個(gè)對(duì)每一文件的在線說明（帶有l(wèi)ink），每一個(gè)說明通常還應(yīng)該提取文件標(biāo)頭的一些屬性名字。
包括設(shè)置、使用說明
指導(dǎo)人民如何連接相關(guān)資源：
源文件索引
在線文檔
紙文檔
設(shè)計(jì)文檔
其他對(duì)讀者有幫助的東西
考慮一下，當(dāng)每個(gè)原有的工程人員走了，在6個(gè)月之內(nèi)來的一個(gè)新人，那個(gè)孤獨(dú)受驚嚇的探險(xiǎn)者通過整個(gè)
工程的源代碼目錄樹，閱讀說明文件，源文件的標(biāo)頭說明等等做為地圖，他應(yīng)該有能力穿越整個(gè)工程。
--------------------------------------------------------------------------------
Use a Design Notation and Process
Programmers need to have a common language for talking about coding, designs, and the software process in general. This is critical to project success.
Any project brings together people of widely varying skills, knowledge, and experience. Even if everyone on a project is a genius you will still fail because people will endlessly talk past each other because there is no common language and processes binding the project together. All you'll get is massive fights, burnout, and little progress. If you send your group to training they may not come back seasoned experts but at least your group will all be on the same page; a team.
There are many popular methodologies out there. The point is to do some research, pick a method, train your people on it, and use it. Take a look at the top of this page for links to various methodologies.
You may find the CRC (class responsibility cards) approach to teasing out a design useful. Many others have. It is an informal approach encouraging team cooperation and focusing on objects doing things rather than objects having attributes. There's even a whole book on it: Using CRC Cards by Nancy M. Wilkinson.
--------------------------------------------------------------------------------
Using Use Cases
A use case is a generic description of an entire transaction involving several objects. A use case can also describe the behaviour of a set of objects, such as an organization. A use case model thus presents a collection of use cases and is typically used to specify the behavior of a whole application system together with one or more external actors that interact with the system.
An individual use case may have a name (although it is typically not a simple name). Its meaning is often written as an informal text description of the external actors and the sequences of events between objects that make up the transaction. Use cases can include other use cases as part of their behaviour.
Requirements Capture
Use cases attempt to capture the requirements for a system in an understandable form. The idea is by running through a set of use case we can verify that the system is doing what it should be doing.
Have as many use cases as needed to describe what a system needs to accomplish.
The Process
Start by understanding the system you are trying to build.
Create a set of use cases describing how the system is to be used by all its different audiences.
Create a class and object model for the system.
Run through all the use cases to make sure your model can handle all the cases. Update your model and create new use cases as necessary.
--------------------------------------------------------------------------------
Open/Closed Principle
The Open/Closed principle states a class must be open and closed where:
open means a class has the ability to be extended.
closed means a class is closed for modifications other than extension. The idea is once a class has been approved for use having gone through code reviews, unit tests, and other qualifying procedures, you don't want to change the class very much, just extend it.
The Open/Closed principle is a pitch for stability. A system is extended by adding new code not by changing already working code. Programmers often don't feel comfortable changing old code because it works! This principle just gives you an academic sounding justification for your fears :-)
In practice the Open/Closed principle simply means making good use of our old friends abstraction and polymorphism. Abstraction to factor out common processes and ideas. Inheritance to create an interface that must be adhered to by derived classes.
--------------------------------------------------------------------------------
Design by Contract
The idea of design by contract is strongly related to LSP . A contract is a formal statement of what to expect from another party. In this case the contract is between pieces of code. An object and/or method states that it does X and you are supposed to believe it. For example, when you ask an object for its volume that's what you should get. And because volume is a verifiable attribute of a thing you could run a series of checks to verify volume is correct, that is, it satisfies its contract.
The contract is enforced in languages like Eiffel by pre and post condition statements that are actually part of the language. In other languages a bit of faith is needed.
Design by contract when coupled with language based verification mechanisms is a very powerful idea. It makes programming more like assembling spec'd parts.
--------------------------------------------------------------------------------
其他雜項(xiàng)
這一部分包含著各種各樣的該做的和不該做的。
在需要用到離散的數(shù)值使，不要使用浮點(diǎn)數(shù)變量。采用浮點(diǎn)數(shù)來做循環(huán)計(jì)數(shù)器無異于向自己的腳
開槍。測(cè)試浮點(diǎn)數(shù)時(shí)總要使用 <= 或 => ，永遠(yuǎn)不要用 = 或 => 。
不要使用程序自動(dòng)美化器，得益于好的程序樣式的主要的人就是程序員自己，特別是剛開著手代
碼、算法設(shè)計(jì)的程序員，使用程序自動(dòng)美化器僅僅能根據(jù)語法來更正程序，因此當(dāng)對(duì)空白和縮進(jìn)
的注意有很大需要時(shí)，它是不可能做到的。正常的細(xì)心注意細(xì)節(jié)的程序員們能很好的用清晰直觀
的樣式來完成一個(gè)函數(shù)或文件（換句話來說，一些直觀的樣式是意向的規(guī)定而不是程序自動(dòng)美化
器能讀懂的智慧）。馬虎的程序員應(yīng)該學(xué)習(xí)細(xì)致的程序員，不要依賴程序自動(dòng)美化器來增加程序
的可讀性。最初的美化器是必須分析源代碼的程序，復(fù)雜的美化器不值得通過這樣獲得好處，美
化器最好用于生成總的機(jī)器建立（machine-generated）格式代碼。
對(duì)邏輯表達(dá)式第二個(gè) = 不小心的忽略是一個(gè)問題，以下顯得混亂而且更像是錯(cuò)誤：
if ($abool= $bbool) { ... }
 
程序員在這里真的是要賦值么？一般常常是，但通常又不是這樣。這樣避免引起這樣的混亂呢？解
決方案就是不要這樣做，利用顯式和隱式的判斷測(cè)試，推薦的方法是在做測(cè)試前先做賦值：
 $abool= $bbool;
 if ($abool) { ... }

--------------------------------------------------------------------------------
使用if (0)來注釋外部代碼塊
有時(shí)需要注釋大段的測(cè)試代碼，最簡單的方法就是使用if (0)塊：
 function example()
 {
great looking code
if (0) {
lots of code
}
more code
}
你不能使用/**/，因?yàn)樽⑨寖?nèi)部不能包含注釋，而大段的程序中可以包含注釋，不是么？
--------------------------------------------------------------------------------
Different Accessor Styles
Why Accessors?
Access methods provide access to the physical or logical attributes of an object. We disallow direct access to attributes to break dependencies, the reason we do most things. Directly accessing an attribute exposes implementation details about the object.
To see why ask yourself:
What if the object decided to provide the attribute in a way other than physical containment?
What if it had to do a database lookup for the attribute?
What if a different object now contained the attribute?
If any of the above changed code would break. An object makes a contract with the user to provide access to a particular attribute; it should not promise how it gets those attributes. Accessing a physical attribute makes such a promise.
Implementing Accessors
There are three major idioms for creating accessors.
Get/Set
 class X
 {
function GetAge(){ return $this->mAge; }
function SetAge($age){ $mAge= $age; }
var $mAge;
 }
One Method Name
 class X
 {
function Age() { return $mAge; }
function Age($age) { $mAge= $age; }
var $mAge;
 }
Similar to Get/Set but cleaner. Use this approach when not using the Attributes as Objects approach.
Attributes as Objects
 class X
 {
function Age() { return $mAge; }
function rAge(){ return &$mAge; }
function Name(){ return mName; }
function rName() { return &$mName; }
var $mAge;
var $mName;
 }
 X $x;
 $x->rName()= "test";
The above two attribute examples shows the strength and weakness of the Attributes as Objects approach.
When using rAge(), which is not a real object, the variable is set directly because rAge() returns a reference. The object can do no checking of the value or do any representation reformatting. For many simple attributes, however, these are not horrible restrictions.
--------------------------------------------------------------------------------
Layering
Layering is the primary technique for reducing complexity in a system. A system should be divided into layers. Layers should communicate between adjacent layers using well defined interfaces. When a layer uses a non-adjacent layer then a layering violation has occurred.
A layering violation simply means we have dependency between layers that is not controlled by a well defined interface. When one of the layers changes code could break. We don't want code to break so we want layers to work only with other adjacent layers.
Sometimes we need to jump layers for performance reasons. This is fine, but we should know we are doing it and document appropriately.
--------------------------------------------------------------------------------
Code Reviews
If you can make a formal code review work then my hat is off to you. Code reviews can be very useful. Unfortunately they often degrade into nit picking sessions and endless arguments about silly things. They also tend to take a lot of people's time for a questionable payback.
My god he's questioning code reviews, he's not an engineer!
Not really, it's the form of code reviews and how they fit into normally late chaotic projects is what is being questioned.
First, code reviews are way too late to do much of anything useful. What needs reviewing are requirements and design. This is where you will get more bang for the buck.
Get all relevant people in a room. Lock them in. Go over the class design and requirements until the former is good and the latter is being met. Having all the relevant people in the room makes this process a deep fruitful one as questions can be immediately answered and issues immediately explored. Usually only a couple of such meetings are necessary.
If the above process is done well coding will take care of itself. If you find problems in the code review the best you can usually do is a rewrite after someone has sunk a ton of time and effort into making the code "work."
You will still want to do a code review, just do it offline. Have a couple people you trust read the code in question and simply make comments to the programmer. Then the programmer and reviewers can discuss issues and work them out. Email and quick pointed discussions work well. This approach meets the goals and doesn't take the time of 6 people to do it.
--------------------------------------------------------------------------------
Create a Source Code Control System Early and Not Often
A common build system and source code control system should be put in place as early as possible in a project's lifecycle, preferably before anyone starts coding. Source code control is the structural glue binding a project together. If programmers can't easily use each other's products then you'll never be able to make a good reproducible build and people will piss away a lot of time. It's also hell converting rogue build environments to a standard system. But it seems the right of passage for every project to build their own custom environment that never quite works right.
Some issues to keep in mind:
Shared source environments like CVS usually work best in largish projects.
If you use CVS use a reference tree approach. With this approach a master build tree is kept of various builds. Programmers checkout source against the build they are working on. They only checkout what they need because the make system uses the build for anything not found locally. Using the -I and -L flags makes this system easy to setup. Search locally for any files and libraries then search in the reference build. This approach saves on disk space and build time.
Get a lot of disk space. With disk space as cheap it is there is no reason not to keep plenty of builds around.
Make simple things simple. It should be dead simple and well documented on how to:
check out modules to build
how to change files
how to add new modules into the system
how to delete modules and files
how to check in changes
what are the available libraries and include files
how to get the build environment including all compilers and other tools
Make a web page or document or whatever. New programmers shouldn't have to go around begging for build secrets from the old timers.
On checkins log comments should be useful. These comments should be collected every night and sent to interested parties.
Sources
If you have the money many projects have found Clear Case a good system. Perfectly workable systems have been build on top of GNU make and CVS. CVS is a freeware build environment built on top of RCS. Its main difference from RCS is that is supports a shared file model to building software.