`

对软件开发一点体会

阅读更多

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


做开发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 写道
渴望有个好的团队 不如创造一个好的团队

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

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

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

相关推荐

    软件开发人员实习心得体会.doc

    软件开发人员实习心得体会 作为一名软件开发人员,实习对我来说是一个难忘的体验,让我不论做人还是做事都改变了很多。在实习期间,我积累了许多感悟,以下是我所分享的一些心得体会。 一、编程规范的重要性 在...

    软件开发实习周记10篇.pdf

    本文档是软件开发实习生的周记,记录了作者在实习期间的经历和体会。作者认为,在实习中,自己不仅仅学习了技术知识,还学会了团队合作和自学的能力。 首先,作者强调了实习的重要性,认为实习是从学校到社会的大...

    2021年网站开发心得体会.docx

    ### 2021年网站开发心得体会 #### 一、项目背景与心得概述 在2021年的网站开发过程中,作者通过亲身实践积累了一系列宝贵经验。这些经验不仅包括技术层面的学习,还有团队协作和项目管理等方面的重要启示。本文将...

    软件开发实习总结.pdf

    在软件开发实习过程中,我深深体会到了作为一个合格的程序员应该具备的基本素质。团队精神和协作能力是程序员应该具备的基本素质,这一点在最近的工作中让我深深休会到了。良好的文档是正规研发流程中非常重要的环节...

    关于软件测试的一点体会

    关于软件测试的一点体会软件测试有一些心得,零零散散,记录下来,与大家交流。一,软件测试员的目标是尽可能早地找出软件缺陷,并确保其得以关闭。仔细思考后,我觉得此目标包含三个含义。1.软件测试员的基本目标是...

    keil 软件集成开发工具

    Keil C51是美国Keil Software公司出品的51系列兼容单片机C语言软件开发系统,与汇编相比,C语言在功能上、结构性、可读性、可维护性上有明显的优势,因而易学易用。用过汇编语言后再使用C来开发,体会更加深刻。 ...

    keil单片机开发工具

    Keil C51是美国Keil Software公司出品的51系列兼容单片机C语言软件开发系统,与汇编相比,C语言在功能上、结构性、可读性、可维护性上有明显的优势,因而易学易用。用过汇编语言后再使用C来开发,体会更加深刻。  ...

    软件测试中测试用例编写一点小体会

    软件测试中测试用例编写一点小体会Usecase是一种在开发新系统或者软件改造时捕获潜在需求的技术。 每个用例提供了一个或多个场景,该场景揭示了系统是如何同最终用户或其它系统交互的,从而获得一个明确的业务目标...

    软件工程实训心得体会精选.docx

    这学期的软件工程实训,以"物联网物流仓储管理系统"为例,让我深刻体验了软件开发的全过程,包括问题定义、可行性研究、需求分析、设计和实施等多个阶段。 首先,行业背景说明是项目启动的第一步,它为后续的系统...

    中国软件开发工程师之痛

    在这篇文章中我从软件开发工程师的角度以“痛点  在近期的一次会议上,有高层谈到之前在中国觉得自己做得很牛,但与美国同行接触后却发现与人家存在很大的差距,这一点我在外企工作时也有过同样的体会。真正与外国...

    工程实训的心得体会(通用6篇).pdf

    3. 软件开发实训的经验教训:软件开发实训让我们明白了工作中需要能力、素质、知识之外,更重要的是学会了如何去完成一个任务,懂得了享受工作的乐趣。我们需要学会冷静、想办法一点一点的排除障碍,并且学会与人的...

    软件系统开发实习工作总结.pdf

    软件系统开发实习工作总结.pdf 该资源总结了软件系统开发实习工作的经验教训,涵盖了教师信息管理系统的开发过程、技术考虑、系统功能、开发经验和收获。 一、计划的实施情况及工作的详细进程 在开发教师信息管理...

    KEIL 7.0版 完全版带中文补丁

    Keil C51是美国Keil Software公司出品的51系列兼容单片机C语言软件开发系统,与汇编相比,C语言在功能上、结构性、可读性、可维护性上有明显的优势,因而易学易用。用过汇编语言后再使用C来开发,体会更加深刻。  ...

    精彩编程与编程技巧-在VB应用程序中使用INI文件的一点体会...

    在软件开发中,尤其是在使用Visual Basic(简称VB)进行程序设计时,对于配置文件的管理是必不可少的一部分。配置文件可以帮助程序存储并读取用户设置或其他非数据库信息。其中,INI文件是一种常用的文本格式配置...

    keilc51教程————51单片机的入门资料

    Keil C51是美国Keil Software公司出品的51系列兼容单片机C语言软件开发系统,与汇编相比,C语言在功能上、结构性、可读性、可维护性上有明显的优势,因而易学易用。用过汇编语言后再使用C来开发,体会更加深刻。 ...

    keil c51 教程

    Keil C51是美国Keil Software公司出品的51系列兼容单片机C语言软件开发系统,与汇编相比,C语言在功能上、结构性、可读性、可维护性上有明显的优势,因而易学易用。用过汇编语言后再使用C来开发,体会更加深刻。  ...

Global site tag (gtag.js) - Google Analytics