如何搭建轻量级架构-敏捷开发普及篇

搭建轻量级的架构，没有轻量级的开发原则是不行的。

传统的软件工程理论是统一软件过程，统一软件过程说的简单点就是沟通，建模，开发，维护。

大家注意，这是一个一次性的过程，也就是每个阶段必须要力求详细，确认功能的务必完善，然后一次性搞定。

所以按照传统的工程理论，开发反而是一个可控性最高的阶段，根据前期“超级完善”的模型，程序员完全是流水线工人，俗称码农！

如果按照这种工程理论去开发软件，双方在前期要耗费巨大的精力去建模，而且也不能保证在真正开发时，不会超出建模的范围。所以项目成功的几率微乎其微！

软件统一过程，根本目的是要控制项目的风险。它的理论基础是严格隔离开发过程中的每个阶段，确保每个阶段的风险都可控，这样项目本身就成功了。

但是软件的过程是基于人的过程，例如沟通环节涉及业务人员和需求人员，建模需要设计人员等等。软件统一过程就要求所有的参与人员都极具专业化，在过程中，不犯任何错误，确保每个环节都正确。

在真实的情况下，这根本是不可能的！！请回忆一下你们公司的产品狗，前前后后修改需求的次数！！

所以很多人吐槽：软件统一过程，它不是想要生产成功的项目，而是要成产完美的文档！哈哈！

大江东去，浪淘沙，多少软件公司，唯剩文档！

基于统一软件过程的不靠谱，出现了一种软件工程理论：敏捷开发。很熟悉对不对，但我保证你并不了解它。让我们慢慢道来。

敏捷开发是一种软件工程理论，并没有实际的方法。现在支持敏捷开发的方法有很多，最有名的是【迭代开发（Scrum）】和【极限开发（XP）】。

极限开发（XP）就是你久闻的两个程序员手牵手开发，一个写代码，一个看着写代码！！这尼玛在我大天朝根本不靠谱，大天朝的开发人员有些还兼任前台的，很忙好不好。

迭代开发（Scrum）倒是很流行，可能很多开发人员不知道这个词，但是已经在用这种方法论了。

我推崇的就是迭代开发，至于迭代开发的理论自行去百度，我不喜欢讲百度百科的东西。老方法，用简单的话来说说迭代开发吧。

功能很大怎么办

按迭代开发的理论来讲，就是功能粒度最小化。比如上期说的导入导出，就做一个xls，迅速增量更新给用户，看用户的反馈来决定下一步的开发。

需求没完全确定怎么办

同样需求粒度最小化，然后进行开发，而不是坐等需求彻底完善。

比如开发一个BI功能，有一个基础的需求，那就动手开始做，一次一次的迭代增量开发，最终形成完善的BI功能。而不是直接花费几个月做完！做完后，产品狗跟你说，不是这样的.....

迭代开发也就这两个重点吧，至于其他的站立会议，都是确保方法论能够实行下去的手段而已。

我认为迭代开发很符合现代开发的思想，有如下的优点：

1.可以以最小成本兼容“烂需求”

你肯定遇到过产品狗，昨天还在说需要某某功能，今天尼玛就完全变了！！

2. 最快出现软件雏形，让客户产生软件认知

大多数需求，都是客户看到雏形才知道下一步的需求。很多人埋怨公司的老板对软件一手遮天，说什么就是什么，我倒认为，如果开发人员快速的通过软件雏形进行有效化的引导，情况可能会不一样！

3. 程序员地位提高了

我一直的观点是，程序员其实是最前线的！ 每次迭代都是程序员来直接面对用户...

而且任何功能的第一个版本，基本上不会删了重做。你做的什么样子，客户就认为这个功能该是什么样子。比产品狗的权利可大多了！

当然，迭代开发也有缺点，如果开发人员把握不住迭代的重点，那么每次迭代都有可能成为“烂需求”！！

所以软件统一过程就黑敏捷开发：你们是在给客户做玩具，不是做软件！！黑出翔，有木有.....

本章到此结束，下一章，我们讲讲述真正在开发中，涉及的代码组织，以及单元测试等问题，敬请期待。

如果您对我的文章有兴趣，请关注我的微信公众号，谢谢。

版权声明：本文为博主原创文章，未经博主允许不得转载。