来源于百度百科:软件生命周期(Software Life
Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段,也有将以上阶段的活动组合在内的迭代阶段,即迭代作为生命周期的阶段。
软件生命周期又称为软件生存周期或系统开发生命周期,是软件的产生直到报废的生命周期,周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、
验收与运行、维护升级到废弃等阶段,这种按时间分层的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,
以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟,软件生命周期设计方法的指导意义正在逐步减少
在 Java 工程开发过程中,常见的开发流程有以下几种:
不同的开发模型适用于不同的场景和项目,需要根据实际情况选择和适配。同时,在实际开发过程中可以结合多种开发模型,避免局限于一种模型的狭隘思维,取长补短追求卓越。
瀑布模型(Waterfall
Model)是最早出现的软件开发模型,是传统软件开发方法的代表。在软件工程中占有重要的地位,它提供了软件开发的基本框架。1970
年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到 80 年代早期,它一直是唯一被广泛采用的软件开发模型。
瀑布模型将软件生命周期划分为 制定计划、需求分析、软件设计、程序编写、软件测试和运行维护 等六个基本活动,并且规定了它们 自上而下、相互衔接的固定次序 ,如同瀑布流水,逐级下落。其 严格强调文档,
前一个阶段的输出就是下一个阶段的输入,文档是阶段衔接的唯一信息。所以很多开发人员好象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。
虽然现在瀑布模型已经不是最主流的开发模式。但是不管什么软件项目,不管采用什么开发模式,有四种活动是必不可少的,那就是需求、设计、编码和测试。而这四项活动,都是起源自瀑布模型,也是瀑布模型中核心的部分。 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度,可以方便地界定不同阶段的里程碑。
早期交付
敏捷开发的第一个好处,就是早期交付,从而大大降低成本。
降低风险
敏捷开发的第二个好处是,及时了解市场需求,降低产品不适用的风险。
由于敏捷开发可以不断试错,找出对业务最重要的功能,然后通过迭代,调整软件方向。相比传统方式,大大增加了产品成功的可能性。如果市场需求不确定,或者你对该领域不熟悉,那么敏捷开发几乎是唯一可行的应对方式。
参考链接:
1.https://www.cnblogs.com/expiator/p/12650769.html
2.https://pdai.tech/md/dev-spec/dev-agile/dev-th-agile.html
我们在开发的过程中,也会涉及到不同的开发模型,我们公司现在是属于敏捷开发模型外加运营推动开发的方式.在开发的过程中,就是以实验的方式进行开发上线,测试功能带来的效果.如果可以,就不断进行迭代.如果不行那么功能就直接干掉,因此为了节约开发成本,一个需求在第一版的时候都是力求简单效率.这里说说一个示例;
需求1: 很多平台都会为创作者生成画像,比如xx头条,B站等,创作者会有不同的等级,而不同等级就会对应不同的权益, 需要对创作者进行分等级.
代码版本1:
属于最基础的代码,使用的Switch
语句, 比使用if/else
语句稍微好管理一点
switch(user){
case level1:
// level1的权益....
break;
case level2:
// level2的权益....
break;
case level3:
// level3的权益....
break;
......
default : logger.info("查找不到用户等级");
break;
}
需求2: 针对不同等级的权益有变动, 增加一些对创作者触达的通知等. 即对需求进行迭代
代码版本2:
开始进行封装,使用策略模式对不同的等级权益进行封装,这边就简写了
// 策略接口
public interface UserLayerLevelStrategy {
/**
* 获取当前权益
* @return
*/
Integer getLevel();
}
// 不同等级的实现
@Service
public class UserLevel0 implements UserLayerLevelStrategy {
// 具体的权益实现
}
// 这边在进入Switch case语句时 就用策略类来代替了,但是还是会有很多分支
switch(user){
case level0:
// 权益
new Context(new UserLevel0()).ContextInterface();
break;
case level1:
// 权益
new Context(new UserLevel1()).ContextInterface();
break;
case level3:
// 权益
new Context(new UserLevel3()).ContextInterface();
break;
......
default : logger.info("查找不到用户等级");
break;
}
重构后:
代码可读性增强:使用设计模式可以使代码更加清晰、易于理解和阅读。设计模式具备高度的抽象性,能够使开发人员通过统一接口来实现复杂的逻辑。
代码复用性提升:设计模式的核心思想是重用,它可以使得代码模板化,并且在需要的地方调用已经存在的设计模式来完成相应的功能。
提高代码质量:设计模式强调软件工程的概念,独立于开发人员,从而确保稳定性和可靠性,并可以避免一些常见的问题,降低代码的维护成本。
代码可扩展性提高:系统架构不再刻意受到各种限制,同时根据不同的需求对代码进行合理的扩展,同时引入新的设计模式,使得整个系统变得更加健壮与高可用。
同时:
在设计编码时,需要注意避免过度设计,以免造成不必要的开销。
过度设计主要有以下两个影响:
增加复杂性:设计模式概念抽象,使用多了可能会使代码变得更加复杂难以理解,降低可维护性、可扩展性和可测试性。
延迟上线时间:由于过度设计,导致开发周期增长和部署时间加长,从而降低项目的效率。
因此:
在设计代码时,可以遵循以下原则:
化繁为简: 仅在需要的地方引入设计模式,确保它的适宜性,并尽量避免过分复杂化;
可维护性优先:在保证设计模式使用合理的前提下,也要考虑代码的可读性、可维护性、可扩展性及其它的软件工程中诸如代码审查、文档编写等整体努力;
随着需求变化调整:设计模式不是一个银弹。正如业务逻辑不断发展一样,每个解决方案都会经历不同的演化过程,可能需要针对特定情境进行随时调整。
总之,在实现过程中应当综合考虑项目特性和业务需求,合理运用设计模式来提高代码质量,同时也需要注重可读性、可维护性和可扩展性等软件质量方面达到一个最佳的平衡点,做到恰到好处。