~

http://www.cnblogs.com/wx1306/p/4831950.html

在这篇博客中，我提出来一些关于软件工程的问题，但随着这一个学期的即将结束，以及我对软件开发的了解的深入，我对这些问题的看法也发生了变化。

 首先回顾一下当时所提出的5个问题：

　　  1.书中认为软件开发最好的状态是不耽误程序员正常的家庭生活，这样的状态需要如何实现，目前有哪些企业成功做到了这点？

　　  2.书中的内容是否有助于读者编程能力而非工程能力的提高？

　　  3.在具体的Teamwork中，该如何具体乃至量化各个成员的分工，以保证效率的最高？

　　  4.如何避免在产品开发后期不断有重大修改，导致其他模块的连锁反应？

　　  5.在程序开发中，如果需要实现比较艰难和底层的任务，能不能在短周期的迭代中得到实现？

对于问题一

经过这段时间的工作以及对部分公司情况的查阅，我觉得如果把软件开发作为自己的工作，那么工作同样变成了生活的一部分，偶尔的加班熬夜是难免的。

因为无论是什么工作，都可能出现短期内亟需解决的紧急问题，这时候就需要额外的工作时间。如果想有所成长有所进步，那么这种情况在任何行业均不能避免。

不过偶尔的加班，和经常加班是截然不同的。如果把这种高强度的疲惫状态作为工作的常态，对于一个正常人来说是绝对吃不消的，无论是精神还是身体都会出现问题，对健康不利。

要想实现避免这种不正常的状态，首当其冲的是要求程序员不断提高自己的能力，如果能力足够优秀，那么将毫无疑问提高工作效率，从而节约工作时间，避免很多加班。

其次，提高团队协作能力，因为软件开发并非一己之力能完成的任务。一个团队在合作的过程中协作紧密、有力配合，这样势必将有力地推进项目的进展速度。

最后，则需要选择一个好的公司。不同的企业有着不同的企业文化，有的企业以加班，刻苦工作作为自己的准则，碰上这样的公司那真是神人也没办法。

因此，我想如果能实现以上三个方面，那么实现“软件开发的最好状态”应该是极有希望的。

在这方面做得出名的好的，众所周知的Google。然后MSRA好像也是挺不错的，看过里面的环境，感觉还是很惬意的。

除此之外，其他不出名的公司其实也是很多的，比如一些散落在祖国各地的小公司。

之前在知乎看到的一个青岛的公司，BOSS好像是从阿里辞职然后自己创业。公司每天下午5点下班，然后BOSS带着下属们要么去喝酒，要么开黑打DOTA，这酸爽。

国外在这方面做得出名的不好的，亚马逊，三天两头的人事变动，然后经常抽疯一样加班。你想来一场说走就走的旅行，它给你一场说来就来的加班hhh

国内的大公司在这方面做得其实也普遍不好。BAT的程序猿都挺辛苦的，另外有一次去360参观的时候，我问了一个攻城狮他们通常几点回家，他告诉我，一两点。

下午一两点？？想什么呢，当然是凌晨一两点啦hhh地铁都停运了还回毛线家啊，直接住公司了，“公司是第二个家”大概就是这种感觉

上个月在宣武门那边有一个小的互联网企业的编辑见面会，公司规模很小，产品走的是低调文艺范儿，颇受我这种中二青年的喜爱，遂去。

刨去颜值超高的主编，以及各种喜闻乐见的抽奖，留给我印象最深的就是公司里的程序猿们。

为了开发新的版本的APP，他们已经三个月没回家了，吃住在公司。这种生活真是可怕。

在北上广的很多小公司艰难地生存着，他们的情形大抵如此，以博得在大城市的一席之地。

如果想实现“软件开发的最好状态”，类似这种工作不要命的公司真是坚决不能去，就算主编颜值超高也不行。

对于问题二

先放个结论：我觉得是有帮助的。

何为代码能力？通常的定义是指程序猿或其他对代码的应用、读写、调试等一系列的能力。主要决定于对代码的熟悉程度以及将算法或思路快速转换为代码的能力。

但我觉得这种定义太过于抽象，并且难以量化界定。因此我更喜欢另一个例子引出的定义。

看过一篇文章，是上交毕业生戴文渊写的《真正的ACMer》，里面提到了他当时参加ACM时的队友Comars。

Comars曾经给代码能力作过这样的描述：2004年暑假时，Comars认为150行以内的题目，他的1Y率非常高，并且保持稳定；

而当代码长度超过150行以后，1Y率就开始急速下降了。如果我们画出一条1Y率的曲线的话，150行就是一个转折点。

所以我们不妨认为，150行就是Comars当时的代码能力。这样的定义我觉得更加清晰明了，同时便于界定能力的强弱。

软件工程这门课中，其中的一些方法，一些理论，是为了让我们对工程有一个好的规划，好的设计。

由此避免一些不必要的问题，进而减少不必要的bug和错误，提高效率和准确性。

这种对问题进行分析，并且对解决手段先设计然后再编写代码的方法，毫无疑问有助于提高代码的一遍通过率，即1Y率。

同一个人，通过有效的分析和设计后再编写的代码，以及直接编写的代码，我认为1Y率的差别是十分显著的。

因此，我认为书中的内容有助于读者编程能力的提高。

对于问题三

在团队的分工中，项目经理需要完成各个成员的任务优化分配。所谓成员的任务优化配置，就是用人要用其长，避其短。

如果一个人擅长写前端，那么就应该尽可能多地让他去敲前端。

如果一个人擅长自学各种新技术，那么就应该去让他攻坚项目中的困难点。

如果一个人并没什么特殊之处，那也不怕，就从最基础的任务给他分配起，然后在一点一点的学习进步中，他也终将完成更困难的任务。

队里最怕的是：

1. 大家抢着敲，以为谁敲得多，谁就是英雄；

2. 搞平均主义，每人敲同样的任务量

3. 将没有基础的人弃之不用

在以上原则的基础上，我认为工作量的分配应该是动态的，在软件开发的每个进程中，都需要根据实际不断地进行调整。

因为每个人能力虽然大体了解，但还是难以界定能力所应对应的任务量。

如果某个人的任务他只花了两天就完成了，而另一个人的花了四天仍尚未完成。那么是否应该让他们共同去攻克未完成的问题？

如果让他们共同协作，后加入的人能否及时了解前一个已经完成的工作？对于变量的含义以及与其他模块的接口能否快速了解掌握？

我觉得这些是未知数，尤其是对于一个组建不久的团队，这一定是个难题。

而具体该怎么做，我至今仍未能想清楚。

这也是在开始团队作业之后新萌发的困扰我的问题Orz.

对于问题四

为了避免在后期的修改导致的一系列连锁反应，在工程开始之际，就应该采取一定的方法。

通过这个学期的学习，以及对之前学长代码的理解，我发现在实际的开发中，常常采用模块化的方法。

也就是每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。

每当增加或者修改工程需求时，我们对不符合需求的模块进行微量的修改，即可满足条件。

对于每一个模块，除了开发人员外，其他人无需关注模块内部是如何实现的。

他们只需要了解模块的输入和输出，以及相应的功能即可。

因此在分配任务时，既要规定每个人所需要完成的任务量，还需要提前规定好对应的输入和输出。

为了实现上面的目的。一个清晰明了的技术规格说明书是十分必要的。

在团队作业的过程中，我们队伍也写了技术规格说明书。

虽然一份技术规格说明书的撰写看起来费时费力，但是其对开发的帮助是十分巨大的。

其实现在想想当时竟然会提出这个问题，感觉真是蛮蠢的=.=

对于问题五

我觉得想在短周期的迭代中实现底层或者艰难的任务，是非常困难的。

尤其是对于经验并非十分丰富的团队而言，更是难上加难。

首先，需要在短期内构思起任务的基本结构，这一步十分关键，也十分考验能力。

如果结构设置的不好，当进行到下一步的工作时，极有可能需要重新返回这部分进行重新的编写。

而如果设计的逻辑不够清晰，那么其作为底层，是不便于上层的调用和使用的。

因此通常设计的过程难以操之过急，如果实力不够，却又想短期内实现，往往会牺牲很多东西。

其次，对于设计不够完善清晰的结果而言，差错是很困难的。而且哪怕设计的很完善， 如果结构很复杂，情况同样不容乐观。

尤其是当底层出现问题，debug起来是十分困难的，我们团队在alpha阶段的时候后端出了一点问题，百思不得其解。

最后经过一天多的差错，发现原来只不过是后端数据的设置和数据库有一点细微的不匹配之处，这点小问题好几个人查了一天多。

诸如此类的问题对于一个经验不丰富的团队而言，它的每一次出现都将耗费大量的时间和经历。

而且随着工程的结构与复杂度的提高，错误的查找将会更加的困难。

幸亏有之前的学长代码提供了一些思路，让我们避免了很多弯路。

对于一些大牛的队伍，可能以他们的技术而言，实现这些困难的任务可能并不困难。

但是他们也会在一些特定情况下遇到奇奇怪怪的错误，不过大牛们的工程经验一般都是很丰富的，所以应该不担心这个问题。

希望有机会能和大牛们讨论下这个问题，请教一下他们在遇到这种需要短周期迭代的很难的任务时，是如何处理的，又是如何解决各种问题的。

回顾论文以及感想收获：

在这个学期之前，我所做过的体量最大的任务，其代码量也不过一千余行，结构也并不复杂，经过简单的构思便可以直接开始编写。

但当我接触了这门课程，发现这种模式对于一个代码行数非常高，程序结构非常复杂的工程，是行不通的。

银弹相关的理论，让我明白了软件开发并没有一劳永逸的捷径，不断提高自我实力才是王道。

而大泥球理论，真是击中了我的痛点，杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码，这就是曾经的我=.=

如果未经详细的设计规划以及设计，就很容易产生“大泥球”，甚至会造成前后的逻辑冲突，*修改已经完成的代码，从而产生大量的不必要的工作。

为了完成这么大型的任务，需要团队的成员有效管理和协作，这就凸显出项目经理的重要性。

一个合理安排分工，有效控制工程进展的项目经理，对于提高开发的效率，以及规避开发过程中的很多不必要的风险，具有十分重要的影响。

而对于开发人员来说，进行合理的分析和设计，掌握软件工程的基本方法，对于开发的效率以及可靠性也有着极大的提高作用。

软件工程的方法论看似过于理论，但对于软件开发的过程却具有着巨大影响。

它展示出了在不同的时代，软件产业对于开发过程的不同的认识，以及对于不同类型项目的理解方法。

掌握了软件工程的方法论，可以让我们在开发的过程中时刻都有良好的掌握和清醒的认识，熟悉每一个步骤的操作方法，深谙其原理，而原理，则是重中之重。

同时，它可以帮助我们建立合理的开发模式与流程，进而大大提高开发的效率，保证开发的质量。

理论与实践的相得益彰，共同提高，我想这就是我在这一个学期里的收获，也是软件工程这门课程对于我们的最大意义所在。