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

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

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

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

假设依照这样的project理论去开发软件，两方在前期要耗费巨大的精力去建模。并且也不能保证在真正开发时。不会超出建模的范围。所以项目成功的几率微乎其微！

软件统一过程，根本目的是要控制项目的风险。

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

可是软件的过程是基于人的过程，比如沟通环节涉及业务人员和需求人员，建模须要设计人员等等。

软件统一过程就要求全部的參与人员都极具专业化，在过程中，不犯不论什么错误。确保每一个环节都正确。

在真实的情况下。这根本是不可能的。！

请回顾一下你们公司的产品狗，前前后后改动需求的次数！

！

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

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

基于统一软件过程的不靠谱。出现了一种软件project理论：敏捷开发。非常熟悉对不正确，但我保证你并不了解它。

让我们慢慢道来。

敏捷开发是一种软件project理论，并没有实际的方法。如今支持敏捷开发的方法有非常多，最有名的是【迭代开发（Scrum）】和【极限开发（XP）】。

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

迭代开发（Scrum）倒是非常流行，可能非常多开发者不知道这个词。可是已经在用这样的方法论了。

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

功能非常大怎么办

按迭代开发的理论来讲。就是功能粒度最小化。

比方上期说的导入导出。就做一个xls，迅速增量更新给用户，看用户的反馈来决定下一步的开发。

需求没全然确定怎么办

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

比方开发一个BI功能，有一个基础的需求，那就动手開始做。一次一次的迭代增量开发，终于形成完好的BI功能。

而不是直接花费几个月做完！做完后，产品狗跟你说。不是这种.....

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

我觉得迭代开发非常符合现代开发的思想，有例如以下的长处：

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

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

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

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

3. 程序猿地位提高了

我一直的观点是，程序猿事实上是最前线的！

每次迭代都是程序猿来直接面对用户...

并且不论什么功能的第一个版本号，基本上不会删了重做。

你做的什么样子，客户就觉得这个功能该是什么样子。比产品狗的权利可大多了！

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

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

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

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