我现在是这样编的.docxVIP

作者:? HYPERLINK /u/867608/blog \t _blank 豆浆油条??发布时间: 2013-08-13 15:56??阅读: 9892 次??推荐: 75??? HYPERLINK /u/867608/blog/138002 \t _blank 原文链接??? HYPERLINK javascript:add_to_wz() [收藏]?? 　　我在做什么 　　曾经，我试过接到一些需求。一眼带过后，脑袋马上随着高昂的斗志沉溺在代码的世界中 ，马不停蹄地敲着键盘直到最后测试的完成。我从思绪中恢复过来，乍一看自己写的功能，和需求差了十万八千里，我TM都在干嘛？ 　　除此之外，我还见过类似的很好笑的事情。有一个程序员，经理提了需求，然后他在那里折腾了一天。结果不但没做出来，而且和实际需求都是完全搭不上调。经过询问发现，他不知道经理说了什么，也不知道自己到底在做什么。 　　代码的世界可能是昏天暗地的，但是我们的思维不能这样随之混乱，否则一切都会前功尽弃。所以我现在编写程序的时候，经常会想一下：我要做什么，我在做什么。更好的方法是把详细需求落实到文档，并时刻核对文档。 　　大局为重 　　2-8法则告诉我们，一个项目核心的功能只有很少，其它大部分都是对核心功能辅助或增强的。但当任务分发下来，我手头总有一些自己很想开发的模块，不过它们不属于那20%。我以前经常会在这些感兴趣的模块上花费很多时间和精力。 　　结果项目快要到上线期限，主要的功能却没开发完成，其它一些不起眼的功能却做得很好，但为此项目不得不延期了。如果反过来，只要对整体功能预期不会有太大偏差，可以将就的先上线。重要一点是：即使功能还有遗漏，但项目可以上线了，老板自然不会太追究，自己工作也能图个安心。如果不知道那些功能模块是最重要的，先问问经理。 　　人总是喜欢做一些自己感兴趣或者有挑战的事。不过在这方面，为了项目和团队着想，应该尽量压制这种诱惑。 　　性能永远不是优先考虑的问题 　　我从来不会一开始就考虑性能问题。如果项目成本很低，甚至到项目结束时，如果没有感觉到明显的性能问题，也不会去管。要知道现在已经不是DOS的年代，CPU的计算能力很高，但成本很低了。重要一点是，如果只针对提升性能对代码做改动，很容易破坏代码的复用性和可维护性。而返过来，提高了代码的复用性和可维护性，则很容易提高性能。 　　下面有一个PHP的代码实例，功能是帮助用户重置密码（代码为了简单说明问题，请不要太在意一些无关的细节） 　　requestResetPassword是接收用户重置密码的请求并且做了相应的检查。为了更好的复用性，我将重置密码的操作单独分配到一个新的resetPassword的函数，更改完密码的后再调用sendEmail向用户发送一封通知邮件。 01 /** 02 * 用户请求重置密码的接收器 03 */ 04 function requestResetPassword() { 05 //检查用户是否存在 06 if( !checkUserExists( $_GET[userid] ) ) { 07 exit(抱歉，用户不存在，请确认用户帐号。); 08 } 09 resetPassword( $_GET[userid] ); 10 //最后向用户发送一封邮件 11 sendEmail( $_GET[userid], 重置密码成功, 新的密码是xxxx ); 12 exit(新密码已经发送到你的邮箱。); 13 } 14 15 16 /** 17 * 帮助用户重置密码 18 */ 19 function resetPassword( $userid ) { 20 //检查用户是否存在 21 if( !checkUserExists( $userid ) ) { 22 return false; 23 } 24 25 //进行重置用户密码的操作 26 //略... 27 return true; 28 } 29 30 31 /** 32 * 向用户发送一封邮件 33 */ 34 function sendEmail( $userid, $title, $content ) { 35 //检查用户是否存在 36 if( !checkUserExists( $userid ) ) {