PHP教程之标准4

会MYSQL吗?会，我会把我的信息在数据库里插入删除啦标准   --------------------------------------------------------------------------------
Create a Bug Tracking System Early and Not Often
The earlier people get used to using a bug tracking system the better. If you are 3/4 through a project and then install a bug tracking system it won't be used. You need to install a bug tracking system early so people will use it.
Programmers generally resist bug tracking, yet when used correctly it can really help a project:
Problems aren't dropped on the floor.
Problems are automatically routed to responsible individuals.
The lifecycle of a problem is tracked so people can argue back and forth with good information.
Managers can make the big schedule and staffing decisions based on the number of and types of bugs in the system.
Configuration management has a hope of matching patches back to the problems they fix.
QA and technical support have a communication medium with developers.
Not sexy things, just good solid project improvements.
FYI, it's not a good idea to reward people by the number of bugs they fix :-)
Source code control should be linked to the bug tracking system. During the part of a project where source is frozen before a release only checkins accompanied by a valid bug ID should be accepted. And when code is changed to fix a bug the bug ID should be included in the checkin comments.
Sources
Several projects have found DDTS a workable system (I 've not verified this link for this PHP release, DDTS may not work for PHP). There is also a GNU bug tracking system available. Roll your own is a popular option but using an existing system seems more cost efficient.
--------------------------------------------------------------------------------
Honor Responsibilities
Responsibility for software modules is scoped. Modules are either the responsibility of a particular person or are common. Honor this division of responsibility. Don't go changing things that aren't your responsibility to change. Only mistakes and hard feelings will result.
Face it, if you don't own a piece of code you can't possibly be in a position to change it. There's too much context. Assumptions seemingly reasonable to you may be totally wrong. If you need a change simply ask the responsible person to change it. Or ask them if it is OK to make such-n-such a change. If they say OK then go ahead, otherwise holster your editor.
Every rule has exceptions. If it's 3 in the morning and you need to make a change to make a deliverable then you have to do it. If someone is on vacation and no one has been assigned their module then you have to do it. If you make changes in other people's code try and use the same style they have adopted.
Programmers need to mark with comments code that is particularly sensitive to change. If code in one area requires changes to code in an another area then say so. If changing data formats will cause conflicts with persistent stores or remote message sending then say so. If you are trying to minimize memory usage or achieve some other end then say so. Not everyone is as brilliant as you.
The worst sin is to flit through the system changing bits of code to match your coding style. If someone isn't coding to the standards then ask them or ask your manager to ask them to code to the standards. Use common courtesy.
Code with common responsibility should be treated with care. Resist making radical changes as the conflicts will be hard to resolve. Put comments in the file on how the file should be extended so everyone will follow the same rules. Try and use a common structure in all common files so people don't have to guess on where to find things and how to make changes. Checkin changes as soon as possible so conflicts don't build up.
As an aside, module responsibilities must also be assigned for bug tracking purposes.
--------------------------------------------------------------------------------
PHP文件扩大名
我见过很多种PHP文件的扩大名（.html, .php, .php3, .php4, .phtml, .inc, .class...）
一切阅读者可见页面利用.html
一切类、函数库文件利用.php
来由
扩大名描写的是那种数据是用户将会收到的。PHP是注释为HTML的。
--------------------------------------------------------------------------------
不要难以想象的数字
一个在源代码中利用了的光秃秃的数字是难以想象的数字，由于包含作者，在三个月内，没人它的寄义。例如：
if      (22 == $foo) { start_thermo_nuclear_war(); }
else if (19 == $foo) { refund_lotso_money(); }
else if (16 == $foo) { infinite_loop(); }
else                { cry_cause_im_lost(); }
在上例中22和19的寄义是甚么呢？假如一个数字改动了，或这些数字只是复杂的毛病，你会怎样想？
利用难以想象的数字是该法式员是专业活动员的主要标记，如许的法式员历来没有在团队情况中任务过，
又或是为了保持代码而不能不做的，不然他们永久不会做如许的事。
你应当用define()来给你想暗示某样器材的数值一个真实的名字，而不是采取光秃秃的数字，例如：
define("PRESIDENT_WENT_CRAZY", "22");
define("WE_GOOFED", "19");
define("THEY_DIDNT_PAY", "16");
if      (PRESIDENT_WENT_CRAZY == $foo) { start_thermo_nuclear_war(); }
else if (WE_GOOFED            == $foo) { refund_lotso_money(); }
else if (THEY_DIDNT_PAY       == $foo) { infinite_loop(); }
else                                   { happy_days_i_know_why_im_here(); }
如今不是变得更好了么？
--------------------------------------------------------------------------------
Promise of OO
OO has been hyped to the extent you'd figure it would solve world hunger and usher in a new era of world peace. Not! OO is an approach, a philosophy, it's not a recipe which blindly followed yields quality.
Robert Martin put OO in perspective:
OO, when properly employed, does enhance the reusability of software. But it does so at the cost of complexity and design time. Reusable code is more complex and takes longer to design and implement. Furthermore, it often takes two or more tries to create something that is even marginally reusable.
OO, when properly employed, does enhance the software's resilience to change. But it does so at the cost of complexity and design time. This trade off is almost always a win, but it is hard to swallow sometimes.
OO does not necessarily make anything easier to understand. There is no magical mapping between the software concepts and every human's map of the real world. Every person is different. What one person percieves to be a simple and elegant design, another will perceive as convoluted and opaque.
If a team has been able, by applying point 1 above, to create a repository of reusable items, then development times can begin to shrink significantly due to reuse.
If a team has been able, by applying point 2 above, to create software that is resilient to change, then maintenance of that software will be much simpler and much less error prone.
--------------------------------------------------------------------------------
Thin vs. Fat Class Interfaces
How many methods should an object have? The right answer of course is just the right amount, we'll call this the Goldilocks level. But what is the Goldilocks level? It doesn't exist. You need to make the right judgment for your situation, which is really what programmers are for :-)
The two extremes are thin classes versus thick classes. Thin classes are minimalist classes. Thin classes have as few methods as possible. The expectation is users will derive their own class from the thin class adding any needed methods.
While thin classes may seem "clean" they really aren't. You can't do much with a thin class. Its main purpose is setting up a type. Since thin classes have so little functionality many programmers in a project will create derived classes with everyone adding basically the same methods. This leads to code duplication and maintenance problems which is part of the reason we use objects in the first place. The obvious solution is to push methods up to the base class. Push enough methods up to the base class and you get thick classes.
Thick classes have a lot of methods. If you can think of it a thick class will have it. Why is this a problem? It may not be. If the methods are directly related to the class then there's no real problem with the class containing them. The problem is people get lazy and start adding methods to a class that are related to the class in some willow wispy way, but would be better factored out into another class. Judgment comes into play again.
Thick classes have other problems. As classes get larger they may become harder to understand. They also become harder to debug as interactions become less predictable. And when a method is changed that you don't use or care about your code will still have to be retested, and rereleased.
--------------------------------------------------------------------------------
Recent Changes
2000-11-16. Release
--------------------------------------------------------------------------------
? Copyright 1995-2000. Todd Hoff and Fredrik Kristiansen. All rights reserved.
  培训的第三阶段，开始接触MYSQL，设计数据库，学习PHP如何去连接MYSQL数据库。对于MYSQL，我并不陌生，因为学校开设了Linux系统的课程，对于数据库的操作。

有位前辈曾经跟我说过，phper 至少要掌握200个函数 编起程序来才能顺畅点，那些不熟悉的函数记不住也要一拿手册就能找到。所以建议新手们没事就看看php的手册（至少array函数和string函数是要记牢的）。

开发工具也会慢慢的更专业，每个公司的可能不一样，但是zend studio是个大伙都会用的。

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

我还是推荐用firefox ，配上firebug 插件调试js能省下不受时间。谷歌的浏览器最好也不少用，因为谷歌的大侠们实在是太天才啦，把一些原来的js代码加了一些特效。

有位前辈曾经跟我说过，phper 至少要掌握200个函数 编起程序来才能顺畅点，那些不熟悉的函数记不住也要一拿手册就能找到。所以建议新手们没事就看看php的手册（至少array函数和string函数是要记牢的）。

有位前辈曾经跟我说过，phper 至少要掌握200个函数 编起程序来才能顺畅点，那些不熟悉的函数记不住也要一拿手册就能找到。所以建议新手们没事就看看php的手册（至少array函数和string函数是要记牢的）。

要进行开发，搭建环境是首先需要做的事，windows下面我习惯把环境那个安装在C盘下面，因为我配的环境经常出现诡异事件，什么事都没做环境有的时候就不能用啦。

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

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

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

曾经犯过一个很低级的错误，我在文件命名的时候用了一个横线\\\\\\\'-\\\\\\\' 号，结果找了好几个小时的错误，事实是命名的时候 是不能用横线 \\\\\\\'-\\\\\\\' 的，应该用的是下划线  \\\\\\\'_\\\\\\\' ;

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

Ps：以上纯属原创，如有雷同，纯属巧合

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

你很难利用原理去编写自己的代码。对于php来说，系统的学习我认为还是很重要的，当你有一定理解后，你可你针对某种效果研究，我想那时你不会只是复制代码的水平了。

其实也不算什么什么心得，在各位大侠算是小巫见大巫了吧，望大家不要见笑，若其中有错误的地方请各位大虾斧正。

写js我最烦的就是 ie 和 firefox下同样的代码 结果显示的结果千差万别，还是就是最好不要用遨游去调试，因为有时候遨游是禁用js的，有可能代码是争取结果被遨游折腾的认为是代码写错。

其实也不算什么什么心得，在各位大侠算是小巫见大巫了吧，望大家不要见笑，若其中有错误的地方请各位大虾斧正。