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


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

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

怎样搭建轻量级架构-敏捷开发普及篇


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

怎样搭建轻量级架构-敏捷开发普及篇


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


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

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


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

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

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

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

怎样搭建轻量级架构-敏捷开发普及篇


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


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


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

让我们慢慢道来。


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


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

怎样搭建轻量级架构-敏捷开发普及篇


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


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


功能非常大怎么办

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

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


需求没全然确定怎么办

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

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

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


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


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

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

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


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

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


3. 程序猿地位提高了

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

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

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

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


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


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

怎样搭建轻量级架构-敏捷开发普及篇


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


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


怎样搭建轻量级架构-敏捷开发普及篇





分类:

技术点:

相关文章: