个人阅读作业+总结

银弹

我认为是没有银弹的。No silver bullet 感觉有点像机器学习中的No free lunch theorem,就是说没有一种算法对所有问题是都适用的,我们需要具体问题具体看待。在软件工程中,我也认为没有silver bullet可以去解决所有的问题,包括高级程序设计语言,包括面向对象建模方法,还有各种设计模式,都只能解决一部分问题,因为软件构建过程过于复杂,很多情况都不能很周全地考虑到。或许将来通过人工智能可以造出一个银弹,但目前来说,我们可能还是需要更多的“铜弹”。

大泥球

大泥球的出现是因为代码没有规范,随意编写,缺乏整体的设计,导致难以维护的代码产生。更深层次的原因是成本、时间等的限制。这导致软件开发中的不断迭代难以进行。

我们的项目中,上届留下的代码中有部分泥球。有些代码已经不再使用,但还留存着。

解决大泥球的方法就是前期尽量做好周全的设计,严格执行代码的规范。

大教堂和集市

大教堂:代码是开源的,但是每个版本的开发工作只能由一组开发人员来完成。

集市:源代码公之于众,所有人都可以提交自己的代码。

我们组的开发方式是大教堂,我们的项目在github上开源,但是只有我们组内的成员有权限去修改代码。
我们没有出现过迷失的情况,可能是因为我们构建的软件并不是非常复杂。

Worse?Better?

为了以后更好地维护软件,我们需要维持良好的代码质量,但这需要时间。如果说我们需要快速地完成一个软件,只要它能给出正确的结果,那代码的质量差一点是可以接受的,这里是有一个tradeoff。但是问题在于,如果后续的开发工作也是要求快速上线一些功能,worse is better的开发方式可能会导致代码质量问题越积越多。需要有一个时间节点去提高代码的质量。

瀑布模型

瀑布模型把软件开发的流程划分成几个固定的阶段。每完成一个阶段,就只用关注后续的阶段就行了。但瀑布模型只有在开发的后期才能看到开发的结果,周期比较长,并且不能快速地应对需求的变化。

敏捷

你的团队在开发中用了那些敏捷的思想和做法?

我们会构建一个简单的demo,然后在此基础上不断改进。

关于敏捷死没死的问题,我认为敏捷本身是非常好的开发方法,它极大地提高了软件开发的效率。但是问题在于,很多人使用敏捷作为自己的标签。
它已经成为一个营销术语,成为改善销售方式(如“生态”、“自然”)等的新成员

但实际上可能并没有什么敏捷。假的敏捷已经死了,但真正被实践的敏捷还活着。

方法论

当有人在某个领域做了很多工作,富有经验的时候,可能就会提出某种可以解决问题的方法论。软件工程的方法论也是一样。它们都是从实际的工作中总结出来的。对于我这样初入软件开发的萌新来说,这种方法论是有很大用处的,至少我们不用从零开始摸索出一个有效的开发方法。当有了更多自己的经验时,我们可以对方法论做出一些调整,而不是完全教条的遵照。

posted on 2018-01-14 13:52  Damocles  阅读(142)  评论(0编辑  收藏  举报

导航