标签：ar 使用 sp for on 问题 代码 bs 工作
结合这几周来的团队、个人项目经验，主要针对阅读材料的第一篇《No Silver Bullet: Essence and Accidents of Software Engineering》（下文中简称《No Silver》）谈谈自己的理解和心得。
个人项目的工作量还不足以算得上是开发一个软件的工作量，在个人项目中单独进行开发难度还不算很高，当然这种开发模式在短时间内所能开发得到的软件一般功能上也不能满足大多数用户的要求，因此价值是不大的。
而在团队项目中，很多软件开发中的实际问题立马就暴露了出来，从接到项目的一开始团队就遇到了各种各样的问题，这里面有一部分是跟《No Silver》里面提到的一些问题相类似的，也有一些其他的。
由于我们团队选择的是代码移植的项目，首先必须读懂已经写好的网页端代码，这其实跟软件维护所要做的工作是一样的。在这个过程中我们发现学长写好的代码里其实存在着很多的问题，也就是说代码本身的功能是有错误的，这给我们移植无疑带来了很大的问题，我们必须先纠正好原来代码里存在的问题，才能开始我们真正要做的工作——移植。不仅如此，我们发现代码里很多比较关键的功能其实还不完善，或者有的功能根本还没实现，感觉代码的开发者把精力都花在了一些无关要紧的地方，这在软件开发里是很忌讳的一件事，因为用户在使用软件的过程中就会很直观地发现软件的功能问题。这个问题在我们的团队开发里应注意避免。
其次，在《No Silver》里提到了软件开发中的一个困难来自于配合性（conformity），这在团队开发里也是很容易遇到的。由于团队的各个个体负责不同的部分，在最后工程整合的时候必然会遇到配合性的问题。各个人负责的部分对接的时候，如果接口不一致，各种各样的问题会导致错误百出，最后整个项目查错起来工作量是巨大的。因此我们团队决定尽量坚持沿用代码原来的各个接口，以保证一致性，配合性。关于配合性，在《worse is better》里也提到了相似的一致性问题，可知这个问题的重要程度不可小觑。
最后，在开发中每个人或多或少都会有一些自己的想法，这就导致我们的移植项目可能最终有一些小地方和原来的代码会有差异，这跟《No Silver》里面所提到的易变性相似。在软件的使用过程中，由于环境和人主观意识的改变，软件的各个小地方可能都会需要进行修改。对于这种某个地方所做的修改，可能会牵扯到其他各个地方的一致性问题，这就需要团队之间建立良好的沟通渠道，修改的地方需要确认其他牵连代码也一并进行了修改，从而保持一致性。
软件工程进行到目前的阶段，以上就是我对软件开发的一点体会。
标签：ar 使用 sp for on 问题 代码 bs 工作
原文地址：http://www.cnblogs.com/brendy/p/4090894.html
