对软件开发一点体会

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

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

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

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

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

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

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

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

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

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

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

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

顾客就是上帝。

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

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

评论

19 楼 xiongfhvk 2010-02-27  

楼主分析很透彻啊。学习了。。。

18 楼 wujt 2010-02-27  

楼主说的很好，身受其同。

17 楼 ahead_zhan 2010-02-27  

一个团队中真的是各种人才都需要，可以不全是技术最牛的，可以不全是学历都很高的，可以不全是N年工作经验的，但必须是极力为团队做贡献的,能共享及分享自己的技术，经验和阅历.
我喜欢这样的团队

16 楼 mercyblitz 2010-02-26  

xixix2004 写道

系统架构告诉大家用什么样的技术，以什么样的方式，做出什么样的东西。

项目经理负责敦促大家将其做成，并为此创造一切便利条件。

这就是2者的区别。

臆断一下，楼主是处女座的人，呵呵。
不合格的架构师见得太多了。

要么是夸夸其谈，一味追求时髦的技术而不考虑开发人员的技术水品，拔苗助长。
要么是“大而全”，不考虑实际需求，什么都想要，把简单的系统搞得复杂无比。

牢骚归牢骚，还是要面对残酷现实啊。

我是射手座～

15 楼 xixix2004 2010-02-26  

系统架构告诉大家用什么样的技术，以什么样的方式，做出什么样的东西。

项目经理负责敦促大家将其做成，并为此创造一切便利条件。

这就是2者的区别。

臆断一下，楼主是处女座的人，呵呵。
不合格的架构师见得太多了。

要么是夸夸其谈，一味追求时髦的技术而不考虑开发人员的技术水品，拔苗助长。
要么是“大而全”，不考虑实际需求，什么都想要，把简单的系统搞得复杂无比。

牢骚归牢骚，还是要面对残酷现实啊。

14 楼 java_fxj 2010-02-26  

fantasy 写道

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

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

13 楼 specsence 2010-02-26  

labchy 写道

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


赞一个 真正做到 可以省去好多的事儿

我也认同这点

12 楼 mercyblitz 2010-02-26  

labchy 写道

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


赞一个 真正做到 可以省去好多的事儿

确实会化繁为简～

11 楼 mercyblitz 2010-02-26  

computer3 写道

我个人的理解，在项目中开发经理和架构师大部分情况下都是一个人，就是一在系统不出岔子的前提下，想尽一切办法提高团队生产力的工头。

1.技术选型：其实可以考虑新的技术 和  设计，毕竟开发对于大部分人来说是一体力活，没点新东西很快就会让人厌烦，整点所谓的高级货也可以适当转移开发人员对于其他事情（比如：高强度劳动and低廉的薪水）的注意力。但 一定一定 要在成本和风险可控的范围之内，说白了，你架构师自己心里得有谱，别玩过了。

2.开发规范 和 开发框架 最好要稳定，整一脚手架，起码在代码的组织结构上要清晰，大框架要统一。

3.和开发人员定好接口，然后整理成合适的文档。这得考验你的技术功底和个人魅力了，不同人员之间的接口制定，相当于变相的安排他们各自的工作量，恩，这个是个麻烦活。

4.代码检查，就是看单元测试做了没，覆盖率如何，一般要求在接口一级，让调用接口的人来写。

5.与客户 还有 公司内部（尤其是天杀的考核部门）的PK....

一般来说，架构师和项目经理不是一个人。

项目经理是负责行政的，架构师是负责策划的。

10 楼 computer3 2010-02-26  

我个人的理解，在项目中开发经理和架构师大部分情况下都是一个人，就是一在系统不出岔子的前提下，想尽一切办法提高团队生产力的工头。

1.技术选型：其实可以考虑新的技术 和  设计，毕竟开发对于大部分人来说是一体力活，没点新东西很快就会让人厌烦，整点所谓的高级货也可以适当转移开发人员对于其他事情（比如：高强度劳动and低廉的薪水）的注意力。但 一定一定 要在成本和风险可控的范围之内，说白了，你架构师自己心里得有谱，别玩过了。

2.开发规范 和 开发框架 最好要稳定，整一脚手架，起码在代码的组织结构上要清晰，大框架要统一。

3.和开发人员定好接口，然后整理成合适的文档。这得考验你的技术功底和个人魅力了，不同人员之间的接口制定，相当于变相的安排他们各自的工作量，恩，这个是个麻烦活。

4.代码检查，就是看单元测试做了没，覆盖率如何，一般要求在接口一级，让调用接口的人来写。

5.与客户 还有 公司内部（尤其是天杀的考核部门）的PK....

9 楼 cuixuxucui 2010-02-26  

作为一个初级开发者，很想加入好的开发团队，也很不易

8 楼 labchy 2010-02-26  

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


赞一个 真正做到 可以省去好多的事儿

7 楼 yangwen13 2010-02-25  

你认识很到位，
我现在 出来工作了一段时间了，感觉到 真的不知道是否该继续下去，感觉自己做的工作毫无意义，（我是在一家金融IT公司，做的工作 更多的是实施工作）不会考虑太多软件设计和架构的方面，感觉自己很迷茫，
不知道自己的路究竟该如何。

6 楼 Sunny_kaka 2010-02-24  

嗯..对楼主说的论题很感兴趣..
特别是处理与客户的关系方面.
有时候用户提出了很多需求,合理与不合理的都有.
感觉要说服客户不是很容易

5 楼 fantasy 2010-02-24  

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

4 楼 java_fxj 2010-02-24  

现在，有点感觉了。
渴望一个好的团队！

3 楼 derta2009 2010-02-24  

写的非常好，感同身受！！

2 楼 andsofish 2010-02-24  

感同身受啊

1 楼 zhxing 2010-02-23  

lz说的很实在。。作为一个初级的开发者，也能意识到这个。