目錄文檔 所有的目錄下都需要具有README文檔，其中包括： 該目錄的功能及其包含內容 一個對每一文件的在線說明（帶有link），每一個說明通常還應該提取文件標頭的一些屬性名字。 包括設置、使用說明 指導人民如何連接相關資源： 源文件索引 在線文檔 紙文檔 設計文檔 其他對讀者有幫助的東西 考慮一下，當每個原有的工程人員走了，在6個月之內來的一個新人，那個孤獨受驚嚇的探險者通過整個 工程的源代碼目錄樹，閱讀說明文件，源文件的標頭說明等等做為地圖，他應該有能力穿越整個工程。 -------------------------------------------------------------------------------- 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 youll 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. Theres 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 dont 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 dont 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 thats 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 specd parts. -------------------------------------------------------------------------------- 其他雜項 這一部分包含著各種各樣的該做的和不該做的。 在需要用到離散的數值使，不要使用浮點數變量。采用浮點數來做循環計數器無異於向自己的腳 開槍。測試浮點數時總要使用 <= 或 => ，永遠不要用 = 或 => 。 不要使用程序自動美化器，得益於好的程序樣式的主要的人就是程序員自己，特別是剛開著手代 碼、算法設計的程序員，使用程序自動美化器僅僅能根據語法來更正程序，因此當對空白和縮進 的注意有很大需要時，它是不可能做到的。正常的細心注意細節的程序員們能很好的用清晰直觀 的樣式來完成一個函數或文件（換句話來說，一些直觀的樣式是意向的規定而不是程序自動美化 器能讀懂的智慧）。馬虎的程序員應該學習細致的程序員，不要依賴程序自動美化器來增加程序 的可讀性。最初的美化器是必須分析源代碼的程序，復雜的美化器不值得通過這樣獲得好處，美 化器最好用於生成總的機器建立（machine-generated）格式代碼。 對邏輯表達式第二個 = 不小心的忽略是一個問題，以下顯得混亂而且更像是錯誤： if ($abool= $bbool) { ... } 程序員在這裡真的是要賦值麼？一般常常是，但通常又不是這樣。這樣避免引起這樣的混亂呢？解 決方案就是不要這樣做，利用顯式和隱式的判斷測試，推薦的方法是在做測試前先做賦值： $abool= $bbool; if ($abool) { ... } -------------------------------------------------------------------------------- 使用if (0)來注釋外部代碼塊 有時需要注釋大段的測試代碼，最簡單的方法就是使用if (0)塊： function example() { great looking code if (0) { lots of code } more code } 你不能使用/**/，因為注釋內部不能包含注釋，而大段的程序中可以包含注釋，不是麼？ -------------------------------------------------------------------------------- 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 rN
