PHP 開発チームの管理に関する簡単なディスカッション

　　说明：本文节选自《浅谈PHP开发团队管理及程序员做人问题》。全文请点击这里访问。

　　看了标题，也许很多程序员会反感的说：“程序员的做人问题先不用谈，你想出来这个标题，那你做人是不是有问题吧！”

　　笔者本人并不反驳这样的说法，每个人都有自己的做人原则。法国人的那句俗话说的好：“我不苟同你的思想，但是我绝对捍卫你思想的自由”。 是，这是站在个人的立场上可以那么说。但是如果站在一个团队的立场上呢？一切不尽然了！

　　无论马拉车的原理也好，还是木桶原理也好，西方人整出来那些比喻确实是值得赞赏的。但是个人认为还是欠缺一些！ 其实作为一个完整的团队，有几个出类拔萃的技术人才是非常必要的。技术团队在技术上必须要有阶梯，否则对于一手抓金钱，一手抓发展的程序员而言，抓不住他的心啊！所以说，这些西方人的东西放到政治中，或者下放到没有什么研发必要，只是熟练工的环境中，是必须的，必要的。但是在技术团队中，并不是最优的。

　　引导一个正确的技术方向，对于整个团队的发展及壮大有举足轻重的必要。既然今天主要谈PHP，那么班门弄斧的多说2句PHP的东西。

　　首先要规范大家编码习惯，采取拿来主义就可以了！

　　数据库层建议全部使用ADODB的数据库类，以尽量减少程序员直接写SQL语句的可能性为目的。这对于以后数据库移植及本身的安全都有好处，最关键的还是规范大家的书写习惯。虽然很多人抱怨效率不太好，但是笔者始终认为一个稳定高于效率、个人必须服从团。如果还抱怨效率问题，那加个CPU，换上2GB的内存。不知道抱怨的主儿，是否不用ADODB写出的代码比加个CPU还要快？

　　数据库建议还是使用MYSQL吧！ 起码要4.1以上的版本。支持事务是非常有必要的。

　　采用MYSQL的原因有很多。第一：兼容性好；第二：功能相对完善；第三：容易配置；第四：支持开源。MYSQL5，这里就不多说了。因为国内程序员开发依然以MYSQL4+PHP4为主，笔者不想给团队造成开发成果不兼容的现象。

　　Apache 是笔者坚决的选择。从国际市场占有率62%就知道了：）安全，高效的突出特点无疑是IIS无法企及的。虽然最近WINDOWS2003 SERVER抢占了一些市场分额，但是依然难以撼动Apache的地位。这中间还有一个更主要的角色，那就是LIUNX。 这里不过多讨论LIUNX了，但是作为一个好的PHP程序员，如果他一点都不了解LIUNX，那无疑也是郁闷的事情。笔者用自己的情况可以大概说说：几年前，笔者开发一个LIUNX虚拟主机的管理软件，拿到需求后，就做技术方案的可行性分析，发现涉及大量的对MYSQL数据库及APACHE的操作，如何完成这些操作呢？这其中要求你必须对LIUNX系统有一定的了解，否则项目根本无法进行！当然还有很多例子，例如PHP的负载均衡解决方案；数据库双备份方案…...太多了。

　　PHP依然以4.0版本为主要开发工具，但是起码需要掌握SMARTY。逻辑业务和页面是必须要分离的。在这里要尤其谈到PEAR。 这里还是有人提出执行效率的问题。笔者依然强调，那个不是问题。PEAR也有自己的数据库类。程序员完全可以考虑和ADODB交换使用，无所谓了。看个人的开发嗜好。

　　但是PEAR丰富的类库，让笔者垂涎三尺啊：）

　　提到PHP。不能不说说ZEND。

　　ZEND是好人啊！ 没有ZEND就没有PHP的今天，那么大家也就没有了今天的饭碗，今天的这篇文字。

　　ZEND 的系列工具及解决方案都是每个PHP程序员必须去理解的。

　　起码在一个团队中，ZEND STUDIO 应该能被熟练的运用，这对项目的管理及开发都有深远的意义。ZEND 系列产品有版本管理，代码优化，代码加密等等优秀功能举不胜举。这里不多说的。大家有机会可以去http://www.phpchina.cn 或 http://www.zend.com 去自己看。

　　最后说到SVN或CVS做版本管理，那也是必不可少的。为什么还用说吗？

　　最后总结下来，无非就是编码的规范和统一。从技术上获得了思想的统一，大家在协作开发的时候才能心有灵犀，才能事半功倍。没有一个程序员会使用自己不感冒的开发工具去做出赏心悦目的作品来的！

　　对于团队的管理，具体下来还是对人的管理。程序员无非要2种东西，钱和发展。

与える量をコントロールすることがチーム全体の調和の鍵です! 遅れをとっている者は支援されなければならず、攻撃的すぎる者は抑制されなければなりません。あなたが守るのは全員の利益であり、一人の利益ではありません。公正と正義は経営者が身につけなければならないものです。

個人的な友人関係に関しては、思いやりと理解を学ばなければなりませんが、物事がその過程に入ると、つまり、それが一定の高さに達すると、個人的な関係を放棄し、正義を求めなければなりません。

さて、上記ではマネージャーの観点から多くのチーム管理の問題について説明しました。基本的には私自身の理解とアイデアの一部です。