PHP网页编程之标准3

因为函数实在是太多了，慢慢的你就会知道，知道有这个函数就可以。标准   目次文档
一切的目次下都需求具有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 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.
--------------------------------------------------------------------------------
其他杂项
这一局部包括着各类各样的该做的和不应做的。
在需求用到团圆的数值使，不要利用浮点数变量。采取浮点数来做轮回计数器无异于向本人的脚
开枪。测试浮点数时总要利用 <= 或 => ，永久不要用 = 或 => 。
不要利用法式主动丑化器，得益于好的法式款式的次要的人就是法式员本人，出格是刚开着手代
码、算法设计的法式员，利用法式主动丑化器仅仅能依据语法来更正法式，因而当对空白和缩进
的注重有很大需求时，它是不成能做到的。正常的仔细注重细节的法式员们能很好的用明晰直不雅
的款式来完成一个函数或文件（换句话来讲，一些直不雅的款式是意向的划定而不是法式主动丑化
器能读懂的聪明）。纰漏的法式员应当进修仔细的法式员，不要依附法式主动丑化器来增添法式
的可读性。最后的丑化器是必需剖析源代码的法式，庞杂的丑化器不值得经由过程如许取得优点，美
化器最好用于生成总的机械创立（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 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.
  培训的第四阶段，就是应用PHP语言开发实际的程序。以结合实际的项目开发来进行学习，效果真的很好，在学习完之后就开始练习，能比较容易掌握所学的知识，这是学校的学习所没法比的。

如果你可以写完像留言板这样的程序，那么你可以去一些别人的代码了，

其实没啥难的，多练习，练习写程序，真正的实践比看100遍都有用。不过要熟悉引擎

使用 jquery 等js框架的时候，要随时注意浏览器的更新情况，不然很容易发生框架不能使用。

如果你可以写完像留言板这样的程序，那么你可以去一些别人的代码了，

写的比较杂，因为我也是个新手，不当至于大家多多指正。

在我安装pear包的时候老是提示，缺少某某文件，才发现 那群extension 的排列是应该有一点的顺序，而我安装的版本的排序不是正常的排序。没办法我只好把那群冒号加了上去，只留下我需要使用的扩展。

这些都是最基本最常用功能，我们这些菜鸟在系统学习后，可以先对这些功能深入研究。

刚开始安装php的时候，我图了个省事，把php的扩展全都打开啦（就是把php.ini 那一片 extension 前面的冒号全去掉啦），这样自然有好处，以后不用再需要什么功能再来打开。

最后介绍一个代码出错，但是老找不到错误方法，就是 go to wc （囧），出去换换气没准回来就找到错误啦。

最后祝愿，php会给你带来快乐的同时 你也会给他带来快乐。

有时候汉字的空格也能导致页面出错，所以在写代码的时候，要输入空格最好用引文模式。

当留言板完成的时候，下步可以把做1个单人的blog程序，做为目标，

作为一个合格的coder 编码的规范是必须，命名方面我推崇“驼峰法”，另外就是自己写的代码最好要带注释，不然时间长了，就算是自己的代码估计看起来都费事，更不用说别人拉。

遇到出错的时候，我经常把错误信息直接复制到 google的搜索栏，一般情况都是能搜到结果的，不过有时候会搜出来一大片英文的出来，这时候就得过滤一下，吧中文的弄出来，挨着式方法。

没接触过框架的人，也不用害怕，其实框架就是一种命名规范及插件，学会一个框架其余的框架都很好上手的。

多看优秀程序员编写的代码，仔细理解他们解决问题的方法，对自身有很大的帮助。

说点我烦的低级错误吧，曾经有次插入mysql的时间 弄了300年结果老报错，其实mysql的时间是有限制的，大概是到203X年  具体的记不清啦，囧。

装在C盘下面可以利用windows的ghost功能可以还原回来（顺便当做是重转啦），当然啦我的编译目录要放在别的盘下，不然自己的劳动成果就悲剧啦。

为了以后维护的方便最好是代码上都加上注释，“予人方便，自己方便”。此外开发文档什么的最好都弄齐全。我觉得这是程序员必备的素质。虽然会消耗点很多的时间。但是确实是非常有必要的。