| | 高效开发的6个技巧 | [align=right] [/align]
|
1.开放代码库，提倡资源共享
在我所管理的每一个开发团队里，都要求开发人员开放各自的开发成果，有用的源代码都需要集中存放在CVS代码资源库中，CVS代码库的模块对开发人员全部是开放式的。因为代码库是开发人员智慧的结晶，看看彼此间的代码，能提高整体开发水平，特别是对新来的职员，更是一个非常好的借鉴前人经验的过程。更有价值也富有趣味性的是，通过开发人员之间交错的代码浏览，有时还犹如白盒测试，代码浏览者会无意中发现代码中隐藏的错误。
但在面对目前越来越严峻的技术保密及安全问题上，需要对相关的部门和团队组织从制度上加以约束。对于还没有正常融入团队的新聘人员，需要一个阶段考查期，代码中隐含着技术保密及安全内容，不得不加以预防。
2.未雨绸缪，学会技术探索
由于技术障碍而延误项目工期的先例也不算少，其中既有对技术需求评估的过于乐观，也有开发人员的麻痹心态或者冒险心里所引发的。比如当一个组件升级后，未经测试而直接置入实际项目中，可能是开发人员觉得凭着自己多年的设计经验以及对此组件先前的认识，坚信能够马上使用，蜀不知有的升级并非只是停留在修正小错误，而可能对结构、接口、甚至实现机理也会变动。当然有如此大变的不是很多，但所谓不怕一万就怕万一，要保障项目的成功，不可疏忽任何小节。
一般的，在系统分析师作项目分析时，就应该安排部分开发人员对即将应用的技术进行预先测试了，这既有对新技术的探究，也有对久经未用的老技术的热身。对决定着软件核心、体系架构等的测试更需要提前，在作技术可行性研究时，就应该模拟简单环境来尝试了。
另外，设计之前的预先测试，不可能面面俱到，还有开发人员本身的差异性也很大，有些开发人员对某项技术很熟悉，但有些开发人员可能很陌生。对于陌生的技术千万不要拿项目来边学习边测试，这包括组件、数据结构、算法等，如果先前未经实践应用而只停留在理论认识，可以单独另外建立一个测试工程，专门对陌生技术进行模拟测试，等测通可行之后，再搬迁至实际工程（当然复制、引用都行）。如果直接在实际工程中测试应用，或多或少的会留下无用代码或破坏代码整洁性，因为在尝试的过程中很少能顺利的一路过关斩将，势必会有频繁改动，有的改动甚至是漫无目的，难免会破坏原本写好的的部分代码。
3.每日整合，只有经整合后的半成品软件才能准确体现整体进度
每一个软件项目，一般都有好几个开发人员，较大的项目还可能是好几个开发组一起参与设计的。在这样的环境下，多个人一起投入设计的时候，难免会出现步调不一致，甚至某些成员在设计上会背离整体要求。为了减少某些成员设计偏差所带来的损失，只有尽早把每个人的设计成果拿出来，整合构建在一起。而且这个构建的过程是不断重复，整合的代码是不断累积的。即便上次构建很成功，也难以保证当前的设计都很正常，为此就需要重复构建。每天下班前构建一次，是比较常见的做法，下班前每个人的工作都有一个小段落了，不会引起写了一半的算法，为整合编译过去而不得不注释掉正常的一段代码。
或许有人认为，频繁整合会浪费很多时间。其实不然，虽然每天得花上半个小时左右的时间整合，一星期累积也就两三个小时。如果你的小组在一星期之内只整合一次，唯一的一次整合未必能在半天之内成功。更为严重的是，如果有一个开发人员的设计偏离了方向，不仅是浪费他自己一星期的时间，可能会导致其他人的工作无法继续，只得先等他纠正。
从项目进度的角度来看，也只有经完全整合的半成品软件才能充分的体现整体进度。否则无法把握每个人所写的部分代码是否真正满足项目的需求，更无从真正知道能否和其他人无缝结合。所以，如果认为每个人完成了90%的工作，整体完成量就是90%，那是绝对的错误，真正的结果是或许只有50%，或许更少。
4.关注界面友好，适时视觉冻结
发人员往往沉迷于代码质量以及程序功能，不注重界面的友好，包括界面布局的杂乱、表现不直观，提示信息的不全、有歧义或过于专业，以及操作繁锁等。好多软件原本内核功能做的不错，却因操作界面不友善而失败，或者重新返工。Windows的成功也得益于界面友好，能让一个没接触过电脑的人很容易学会上网。我们做的软件何不让客户也能快速的学会使用呢？开发人员要学会换位思考，设计的时候，多想想开发的软件是给谁用的，要站在使用者的角度来看待这个软件。有条件的项目团队中，要有相当数量的专业界面策划美工人员，十人以下的团队一般有一至两名界面设计师足够了，在分工上好多界面设计师同时也可以参与文档编辑和产品包装。
"视觉冻结"一词引自马魁尔的《微软研发致胜策略》，意思是说在开发后期，界面就固定不动了。这样做能使手册文档可以定稿，以便能让手册也能尽快与客户见面。在开发后期这样做的确很有必要，否则也容易引起文档编辑和开发人员的内部矛盾，如果有非不得已的界面更改，开发人员应该及时与文档编辑人员沟通。
5.代码少不了重构，但不可过频，需要计划
重构就是在不改变外在行为的前提下，对程序的内部结构做出调整、修改，以改善性能、减少隐含的错误。成功的重构，花很小的代价，就能给软件注入新的生机，从而延长软件的生命周期。
重构的好处显而易见，能使老牛变快车，能让软件更加稳定。也正因为，好多程序员都沉迷于重构，今天写明天构，频率过高，最终延误进度。我理解每一位程序员对代码的成就感，也理解一个善于创新的程序员，每当回头看原来写的程序时，总会发现许多不足。（这个不足并非说原先分析不到位、设计没规划好，而是等有了一定的经验积累，或通过其它途径学到新知识之后，会觉得原来做的不够好。）但是重构是需要有计划的，一般而言普通的项目计划里是不含有重构日程安排的，除非是纯粹的重构项目计划。
当然，不让原始设计和重构并行，也并不是死搬硬套的，比如在项目开发中，如果某个常用函数不加以重构，调用的地方速度明显过慢，就该考虑及时采取动作了。一般的，不是为迫切解决错误，而对其它地方影响面又较少的代码，如果项目时间不宽余就不应该重构（或者更确切的说是设计与重构并行），应以进度里程计划为重。
6.代码不仅要易读，易用，更要追求多用
在软件度量上，经常把代码行作为衡量软件规模的标准之一，正由此，有些程序员经常以为自己写过的代码行数可以作为资历或能力的证明。其实不然，软件是由众多代码通过一定的逻辑堆积而成的，而非机械可见物的形体堆积，量大并不代表功大。
我经常在程序设计小组会上强调代码要以"易读，易用，多用"为原则。
易读这一点很好理解，学过程序语言的人都明白，不过易读强调的是能让人家容易读懂你的程序，所以在一个团队里一般都要求一致的代码风格，包括注释、命名、空格等，有时还考虑代码整洁美观。
易用，一般指一些公共的函数库，能够很方便的供他人调用。其中涉及到的有，参数的初始化，对象的创建、释放，函数的健壮性等。
多用，一方面指执行概率，比如一个公共的函数被别人调用次数越多，说明这个函数的价值越大；另一方面指生命周期，比如一个软件经过无数次的重构或者升级，其中的一段代码还是被原样保留（当然觉得好才保留），说明这段代码的价值就大。
所以，多用才是重点，其最能体现代码的价值，也是评价程序员优劣的标准。
|
|
|
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理
