对软件开发一点体会

一年来很少写日志，更多地是项目开发和研究他人的经验和知识。

做开发4年来，给我一个总体的感觉是痛苦并且快乐着。相信很多朋友和我一样，解决了一个棘手的问题，更有甚者这个问题他人不能解决时，成就感油然而生。至于痛苦的方面，这可能和他人不同，我很少会为不能解决的问题而困惑，更多的是来自于团队合作和团队工作质量。有时候，会对队友很失望，无论是经验程度，还是处理人事的方法。

对于软件开发，笔者一点体会，简单地说，为了一个共同的目标，一个或多个团队相互合作，产生一定“结果”的社会过程。个人偏好地认为是一种过程，通常来说，由项目立项、可行性分析、需求分析、架构设计和技术选型等等。在不同的场合，这些过程增加或者减少。无论怎么样的变化，其决定性因素的还是人，处理好人事等于成功了一半。在软件工程，没有最好，只有更好，永远牢记着只做正确和适合自身的开发方法，尽量不要教条主义和理想主义。笔者曾经就犯过错误，严格地按照敏捷那套执行，开始就遇到了同事的反对，理由是他不能理解，执行起来困难重重，照搬是不行的。

万事开头难，尤其是软件项目，把握需求是困难的，一般而言，很难做到所有的需求细节一一列出，只可能在一个相对抽象的需求上不断地“演化”，甚至发生变化。开发人员最苦恼的地方莫过于需求变迁所带来的反复开发或者修改，所谓的“Change is welcome"，那是“Communism”。若要把项目致力于灵活多变，无疑是困难的。从事多年开发的同仁会感觉，如果有一个不需要编码，只需要简单配置，能够完成需求，那该多好。不过，据我所知，不管模型化建模，还是代码自动产生器都不能很好完成需要，毕竟需求是各异的。

找不到理想中的“乌托邦”，最终还是回到现实。重担还是落在开发人员身上，开发人员面对“脆弱的”需求，尤其是架构师团，更需要抽象业务逻辑，构建需求的蓝图和界限。笔者认为成功的架构师是务实的，我见过不少“理想主义“的架构师，写出来的方案有点像“八股文”，甚至一些方案在实际情况中是“死胡同”。

架构设计并不是越抽象越好，更不是越技术先进越好，成熟大于高新，务实大于花哨。

说句题外话，我看到过很多同学，尤其是初出茅庐的，在简历上面写了不少的“高新”技术，动不动就是“精通”的字样，有经验的HR看都不会看这样的简历。反思一下，为什么不少公司招聘信息注明，行业经验优先考虑。不难看出业务理解优先于技术实力。技术是要落到实处来解决实现的问题的。好比钞票，如果不流通，它就是废纸。

架构设计和技术选型之后，详细设计，一个和客户或者和开发人员内部讨论过程，无论你的角色是什么，沟通的素质是必须的。作为开发人员，要了解自己的输入和输出。作为项目经理，需要合理安排人力资源和协调团队，同时和客户互通。

人力资源安排是一门大学问，首先需要了解团队人员的素质，主要是技术实力和需求理解能力，其中需求理解至关重要。

项目经理好比军队中的“帅”，架构师好比“参谋”，开发人员则是前线将士。团队的执行力，往往决定项目的成败。首先，需要了解部下，一个稳定的团队是相当重要的。众所周知，IT行业是一个流通性相对比较大的行业，尤其在时间拮据的情况下，大多数通过面试手段来招募贤士，少数则是通过推荐。无论哪种方法，在短期内，知人善任是困难的，项目经理很难全面的了解开发员的才能。笔者就遇到了这个问题，开始觉得挺不错，感觉后来越来越差，人才真是凤毛麟角。当项目进行到一定阶段的时候，临时“易将”是不明智，重新招募和培训新的员工，无论是时间成本还是人事处理都是不合适的。一个权宜的方法就是培训员工，因为技术和素养是可造的。一些上了年纪或者有家庭的员工很难进行“培训”，其兴趣和精力不在于此，处理这样的问题比较棘手，至今效果不理想。

事情不能改变的时候，只能适应其规律。

接下来，沟通和协调团队。它是双向的，逐渐地了解队友的习惯和素质，合理地安排任务的分配。笔者举一个二期开发项目的例子，见到的一个常景就是，各个队员开发个自己的小模块并且保留接口，接口之间可用性和风格各异。由于笔者偏好开发，因此有“Code review”的习惯。出于尊重前辈（笔者的年纪最小，平均小了10岁），时常在代码上面添加注释，建议修改或者改进。由于项目前期，测试用例极少，导致了目前修改后的bug不断，项目中出现了相互职责的问题。经过一段时间的调整，最终统一了意见。过程可以说是步履维艰，其消耗了大量的开发时间。在一个团队中，很少的人对软件的思考，过多的是实现功能性。软件作为一门艺术，开发是苦难的。如果仅仅停留在功能性实现的层面上，可以说没有什么价值。若把它定位到哲学高度，则是力于美的结合。虽然软件是虚拟的，但是它能够体现一个团队背后的智慧，从学术的角度，就是软件的制造工艺。工艺水平直接或间接地体现了软件的架构能力。提升团队的素质，应该从这个方面入手，有限地提高。

顾客就是上帝。

有时候这些上帝也比较“疯狂”，提出来很多不合理的需求。相信大家喜欢技术型出身的客户，那样会更有“人情味”。推掉不合理的需求也是一门学问，如果能够化“被动”为“主动”，那更是“艺术”。处理顾客关系，使用软件技术手段是行不通的。有意思的是，软件工程里面很少有“人文关怀”，而是过多的“工程实践”。笔者认为“人文”方面是不可少的。事实上，项目经理多不是“技术”官，而是“行政”官，不少人误解了其作用。

由于时间和经验的关系，只能写到这里。针对一些问题，我会做“专题”，从行政管理到软件架构，甚至到开发实践方面，相当地欢迎朋友们一起讨论或者指点迷津。

评论

39 楼 middin 2010-06-22  

开发者永远满足不了客户的要求……

38 楼 chenyulong1 2010-06-18  

楼主是我们的榜样哈。

37 楼 youngxu 2010-06-18  

LZ说的很实在，做好软件开发不容易。

36 楼 colinsage 2010-04-09  

越来越感觉到：程序员出来混，玩的是人不是技术

35 楼 bomb2121 2010-03-07  

同样是四年的工作经验，楼主成长和自我总结的比我要好多。回想四年下来接触了各种各样的技术，但没有一样能说是精通的。面对层出不穷的各种新的技术、框架，多的是浮躁和不安。没有一个长期积累到沉淀的过程，在这个行业很难有所突破。写程序需要的是耐性，做软件靠的是团队协作，另外做一名合格的程序员还需要一张安静的书桌。

34 楼 xlongbuilder 2010-03-07  

楼主写的真的很不错 很期待你后续文章
给个良好

33 楼 zhao3546 2010-03-06  

难得一见的好文，可见作者对软件开发还是有尝试思考的

32 楼 arong 2010-03-04  

LZ，这么年轻就有这么深的提炼，佩服，不是一般人。文笔也很不错。

31 楼 rdsuncn 2010-03-03  

LZ 意识有点到位了

30 楼 yanx730 2010-03-03  

感觉不错，沟通是个技术活

29 楼 derekop 2010-03-02  

写的真非常好 现在逐渐得感到了

28 楼 lxinfor08 2010-03-02  

现在的我确实只是在一个功能实现的层面上，感觉这是一道坎、、、、、、

27 楼 qiaoakai 2010-03-02  

写的挺好！！支持一下！！呵呵。。。

26 楼 donggua63966659 2010-03-01  

软件作为一门艺术，开发是苦难的。如果仅仅停留在功能性实现的层面上，可以说没有什么价值。若把它定位到哲学高度，则是力于美的结合。虽然软件是虚拟的，但是它能够体现一个团队背后的智慧，从学术的角度，就是软件的制造工艺。工艺水平直接或间接地体现了软件的架构能力。提升团队的素质，应该从这个方面入手，有限地提高。

很赞成。

25 楼 wx851205 2010-03-01  

架构设计并不是越抽象越好，更不是越技术先进越好，成熟大于高新，务实大于花哨。

英雄所见略同

24 楼 mercyblitz 2010-03-01  

showr 写道

楼主几年开发经验啊 ？

比同时普遍小10岁？

莫非就 20 出头？

能写出这样的体会 ？

学习了 ~~~！！！

收藏 ！

24，也不小了，呵呵。

23 楼 showr 2010-03-01  

楼主几年开发经验啊 ？

比同时普遍小10岁？

莫非就 20 出头？

能写出这样的体会 ？

学习了 ~~~！！！

收藏 ！

22 楼 mercyblitz 2010-02-28  

<div class="quote_title">windflawlyq 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div"><span><span style="font-size: small;">笔者曾经就犯过错误，严格地按照敏捷那套执行，开始就遇到了同事的反对，理由是他不能理解，执行起来困难重重，照搬是不行的。</span></span></div>
<p> </p>
<p>    我觉得不是太严格，而是不够严格，或是严格不起来。</p>
<p> </p>
<p>    我也在项目中推行敏捷，团队成员虽然嘴上都说支持，但除了我给他们上的一些敏捷的课，似乎大家再也没有主动去深入研究敏捷。因为缺乏对敏捷的理解，使得实践起来显得很形式化，没能真正体现出敏捷的价值。同时基于这种没有价值，团队成员就会对敏捷的一些具体做法提出怀疑，删减具体一些实践或对实践进行修改。</p>
<p> </p>
<p>    例如，在提倡用TDD后，更多人觉得我们先从无到有的引入测试就好，至于测试是否先行，测试是否驱动设计都给出了否定。结果在大多的时间下，大家都写的测试代码越来越少，一个大模块，可能就只写了几个无关紧要的测试，这些测试写得又长又臭，在设计发生调整时测试代码不易修改，最要要嘛不对设计进行重构，要嘛重构了，干脆整个测试注释掉。</p>
<p> </p>
<p>    我觉得学一样东西，不要还没去看去悟就开始反对教条。我们不是做得太过，而是根本就还没入门。大家都不是大师，却个个具备对大师的评判能力，动辄去怀疑去否定。我不反对做学问带着怀疑的态度，只是觉得怀疑的时间点不对。我更愿意一开始依葫芦画瓢的一步一步去做，遇到问题反复去咀嚼书上的话，去看论坛里的分析，去思考，等真正用一段时间后，才开始去总结体会，去适度评判。</p>
<p> </p>
</div>
<p> </p>
<p>和你相同的感受～</p>

21 楼 windflawlyq 2010-02-28  

<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div"><span><span style="font-size: small;">笔者曾经就犯过错误，严格地按照敏捷那套执行，开始就遇到了同事的反对，理由是他不能理解，执行起来困难重重，照搬是不行的。</span></span></div>
<p> </p>
<p>    我觉得不是太严格，而是不够严格，或是严格不起来。</p>
<p> </p>
<p>    我也在项目中推行敏捷，团队成员虽然嘴上都说支持，但除了我给他们上的一些敏捷的课，似乎大家再也没有主动去深入研究敏捷。因为缺乏对敏捷的理解，使得实践起来显得很形式化，没能真正体现出敏捷的价值。同时基于这种没有价值，团队成员就会对敏捷的一些具体做法提出怀疑，删减具体一些实践或对实践进行修改。</p>
<p> </p>
<p>    例如，在提倡用TDD后，更多人觉得我们先从无到有的引入测试就好，至于测试是否先行，测试是否驱动设计都给出了否定。结果在大多的时间下，大家都写的测试代码越来越少，一个大模块，可能就只写了几个无关紧要的测试，这些测试写得又长又臭，在设计发生调整时测试代码不易修改，最要要嘛不对设计进行重构，要嘛重构了，干脆整个测试注释掉。</p>
<p> </p>
<p>    我觉得学一样东西，不要还没去看去悟就开始反对教条。我们不是做得太过，而是根本就还没入门。大家都不是大师，却个个具备对大师的评判能力，动辄去怀疑去否定。我不反对做学问带着怀疑的态度，只是觉得怀疑的时间点不对。我更愿意一开始依葫芦画瓢的一步一步去做，遇到问题反复去咀嚼书上的话，去看论坛里的分析，去思考，等真正用一段时间后，才开始去总结体会，去适度评判。</p>

20 楼 抛出异常的爱 2010-02-27  

java_fxj 写道

fantasy 写道

渴望有个好的团队 不如创造一个好的团队

新手，肯定想加入一个好的团队啊。以后才能创建一个好的团队。
一开始，便可以创建一个好的团队的是天才！很可惜，我是不天才。

要什么天才？
非要弄出一个皇上
大家来贡着他，
心里才会安心么。

需要什么资源就去要，
向老板要，
向客户要，
座那里等着？
等老板同意你拿他的资源作实验么