今天晚上第一次参见sife南开的会议，持续了两个多小时，自己的感触还是不少的。

1）“先入为主”

对于一个组织，加入的越早，往往越有地位，越能成为“主”。

2）专业决定职务

在队长分配各自的职务的时候，我由衷的感到深深的悲哀。类似项目管理、市场营销之类的中高级职位的安排，以计算机软件见长的我们只能靠边站。当然，在分配职务的时候，这是一方面的因素，但有是很重要的因素。

3）向强者学习

分析和解剖成功的案例，找出他们成功的关键因素，然后再选择项目的时候，往这些标准上靠，往往更容易成功。

4）表现自己

就算你是块金子，你也要擦亮自己。尤其对于后来人，要想混的好，必须脱光衣服。

总述

　　今天晚上，在“南开大学软件学院首届编程大赛现场展评暨颁奖典礼“上，八只队伍经过一番展示之后，最终我们的作品“Mine－－便携式源代码管理工具“获得了“最佳设计奖“。“最佳作品奖“由飞飞团队（李飞、董飞）获得，因为没有得到最高的肯定，心情还是有点失落的。

教训

　　对于为什么没有获得最好的结果，我思考了好一阵。总结出来如下几条：

　　1）软件的需求做的不够全面。比如说我们设计的时候，就没有考虑到源代码的安全性；还比如说，我们分析题目的时候，就没有拿CVS先来进行详细的“解剖“，导致最后，我们没有想到类似比较文件内容的功能。

　　2）一些细小的地方没有处理好。比如说，今天我进行操作演示的时候，出现了一个小失误：我竟然把“ctrl＋v“给按成了“ctrl＋s“，结果，文件倒是消失了，但“粘贴“不出来。后来幸亏经jj提示，我在回收站里面找到了。汗，当时可是吓了我一跳！还比如说，回答问题的时候，我感到自己的随机应变能力还有待加强。还有，感觉飞飞团队演示的时候，要比我们有亲和力的多。

学到的东西

　　今天，通过展评，从和我们一起展示的同学那里也学到了很多东西。如下：

　　1）要学会“拿来主义“。开发应用软件，不一定要什么东西都自己开发，自己一行行的把所有代码敲打出来。比如说飞飞团队，他们就使用了很多已有的组件和技术，然后有效的组合在了一起（当然他们肯定自己也写了很多东西），最后形成了一个很不错的软件。

　　2）凡是“预则立，不预则废“，无论是从自身，还是从一起比赛的同学的身上，无论是从正面，还是反面，这一点，是今天对我感触很深的一点。

额外的思索

　　今天进行到最后的时候，黄院长的总结，让我想到很多其它的东西。

　　1）我觉得Boss就是Boss，只要他开口讲话，看问题的角度和分析问题的高度就是不一样。我这里没有丝毫恭维Boss的意思（估计他也看不到这篇文章，呵呵），他看待问题的时候，总着眼于软件学院的发展，字里行间不时就透漏出那种身为一院之长的责任感。这一点，很令人敬重。

　　2）我觉得Boss还是一个更愿意面对问题的人。这次编程大赛报名的时候有40个参赛队伍，最后提交作品的只有8只队伍。我们其实就是通过自然淘汰，从而进入到今天的展评的。从这一点上可以说，这次比赛的规模还有点小，虽然我们可以把原因解释为这是“首届“。所以说，南开的“软件事业“，还需要包括我们在内的所有软件人一起努力。明年在南开大学举办的全国第十届挑战杯，对我们南开软件人来说，是机会，更是挑战……

　　第一次看到《没有银弹》（作者：Fred Brooks）这个题目，感到有点奇怪；在弄懂了作者要表达什么观点――没有任何技术或管理上的进展，能够独立的允诺十年内使生产率、可靠性或简洁性获得数量级上的进步――之后，作为一个习惯叛逆的青年人，我的第一反应就是作者的观点有点偏激，有点悲观。

　　我首先习惯性的从唯物的、辩证的角度来看待这个问题。软件开发是人们认识世界、改造世界的一项活动。而任何事物、任何运动都有其可以遵循的普遍的规律性。人类的生产活动，无论是单纯的通过机器来进行大规模流水线作业的制造工业，还是像软件开发这种通过人类的思考来解决问题的活动，都是人类通过一定的手段来解决客观存在的问题。任何客观问题，都拥有其复杂性，也同时拥有其内在规律性。所以，当人类对现实世界认识到一定水平的时候，相应的问题都将会慢慢的有很好的解决方法的，包括软件开发。我们不要忘记，软件开发、程序员，这些名词，才出现了不过几十年吧。

　　上面是我简单看完文章之后的冲动的想法，显然，有点乐观主义了。在慢慢冷静下来之后，我发现，把自己的注意力放到是否有银弹这个问题上，有点没有必要。其实作者给想传达给读者的意思是：让软件开发人员一起来寻找可以（尤其从根本上）提高软件开发生产率的途径。

　　让我们一起来看一下作者是怎么分析的吧，同时也来一起探讨一下那种途径最有效。

　　他首先是把软件活动的任务划分为根本任务和次要任务，然后再分别阐述可以或者可能提高生产率的方法途径。

　　作者认为软件活动的根本任务是“打造由抽象软件实体构成的复杂的概念结构”，而次要任务是“使用编程语言表达这些抽象实体”。很显然，作者划分此的目的在于更好的寻找可以提高生产率的方法。对此，我认为，划分是必要的，但与此同时，我们应该看到，在不同的历史时期，制约软件活动的关键因素是不同的。正如作者在文中说到的那样“在1952年，甚至很难想象开发的次要问题不会占据开发工作的主要部分”。
下面来探讨一下怎么提高生产率。要谈提高生产率，显然得先弄明白什么是生产率。在《没有银弹》中，感觉作者过于注重从量上提高生产率（即单位输入对应的软件产出）了。很自然的，我们也许会想到，可以不可以从质的方面来提高生产率呢？在《再论<没有银弹>》中，作者也提到了这一点。他引用jone的观点“关注质量，生产率自然会随着提高，很多代价高昂的后续项目投入了大量的时间和精力来寻找和修复规格说明中、设计和实现上的错误”。所以，我们在考虑提高软件开发的生产率的时候，也应该把软件质量考虑到其中。不仅要争取快速的开发出想要的软件，更要开发出质量高，可扩展性好的软件。

　　关于怎样提高生产率，作者在文中列举了一些有希望成为银弹的事物：Ada和其它高级编程语言、面向对象编程、人工智能、自动编程、图形化编程、程序验证、环境和工具、工作站；同时也分析了几种颇有前途的方法，即购买和自行开发、需求精练和快速模型、增量开发和卓越的设计人员。

　　我个人认为，在重用（也就是购买和自行开发）和快速模型两个方面，最有可能找到银弹。

　　先说重用。正如作者所言，“解决软件构建根本困难的最佳方法是不进行任何开发”。我感觉重用和现实生活中的其它的生产活动很像。既然软件开发是一个最终生产出产品的活动，那么他就必定可以像生产汽车那样，通过“组装”一些零件来构造这个产品。

　　当然，重用或者说是复用，有底层的，也有高层的。底层的像设计优良的类库等；而高层像设计模式、结构框架等。底层的重用，看起来相对容易一些。而高层的重用，也许就不是很普遍的事情。我认为，就像《软件体系结构》这么学科一样，关于软件体系、架构等的研究，还处于不成熟的阶段。随着时间的推移，这方面应该会取得一些令人满意的进步的。所以，通过合理有效的通过重用来开发软件，应该能大幅度的提高软件开发的效率。

　　再说说快速模型方面。在开发软件系统的过程中，最困难的部分是确切地决定搭建什么样的系统，同时需求工作对系统的影响比其它任何一部分的事物都大。因此软件开发人员为客户所承担的最重要的智能是不断重复地抽取和细化产品的需求，但事实上，客户往往不知道他们自己需要什么样的功能。
有一个途径，就是通过开发“快速原型化系统”，来试图完整、精确、正确地抽取现代软件产品的需求。但是，我个人认为，还有一些可以尝试的方法，来解决需求方面的问题。比如说增加或者规范“公司需求分析人员”这个职位，这类人专门负责和公司交流，提取公司的需求。同时每个人都有相关行业的实际从业的背景，且具有软件描述的能力等。通过增加或者规范已有的需求人员，来提高获取需求的精确度和可预见行。
另外，随着技术的不断发展和对实际问题的不断摸索，相信会有更多、更适合的方法摆正我们的面前的。

　　最后，作者文中有一句话，“软件开发是一个创造性的过程”。这句话很值得我们思考一下，也许软件开发真的“没有银弹”，不过，我始终还是坚持自己在文章开始就提出来的观点：是问题，总有被解决的一天。

附件：《没有银弹》下载