最近笔者参加了极客时间的21天打卡行动,从年初开始到年末,21天无间断完成了打卡行动。虽然打卡行动已经结束,但还是不想因此就懈怠了,人一尝点甜头就容易忘乎所以,所以我想继续保持学习的习惯。
上周学习完了《软件工程之美》中的需求分析篇,这周会学习系统设计篇,以下是这周的总结
这节课很有指导意义,软件工程的存在的目的和意义就是为了解决改善软件项目管理过程中的问题,需求变更就是我们程序员深恶痛绝的问题。 为什么软件项目需求会经常变更? 原因有以下两点:
如何解决需求变更问题?
这三种不同解决方案,不仅仅只是对工程师提出要求,对项目经理、产品经理等不同角色都提出了要求。只有每个角色都能意识到需求变更给项目带来的后果,提高对需求的理解能力,提高协作效率,减少无用功,提升工作的满意度,不至于疲于应对需求变更。
说起架构设计,大部分普通程序员偏向于代码实现,很少有机会站在全局的视野去进行架构设计,这也是我想去加强的地方。 软件项目的复杂性有两个特点:
架构设计的好处在于:
什么是架构设计?
如何做好架构设计?
通过良好的架构设计,可以有效降低开发难道和成本,让普通程序员也能实现复杂系统。
技术选型这个话题跟工程师就很相关了,我们日常工作总会遇到要引入新的技术框架,这个时候技术选型就派上用场了。 宝玉老师提到技术选型就是项目决策,受限于以下几个方面:
常见的坑
如何做好技术选型?
作为一个有追求的程序员本就不应该守着自己的一亩三分地,努力学习架构设计,站在更全局的视野思考业务问题,通过良好是技术来帮助业务成功。 架构师思维:
如何成为好的架构师?
技术债务: 软件项目中对架构质量和代码质量的透支。 技术债务产生的原因:
如何管理技术债务:
处理策略(主要取决于投入产出比哪个更好):
预防才是最好的方法
课后思考: 我们项目中的技术债务有很多,举个例子,App最开始采用的动态化技术是React Native,但随着技术的演变RN的弊端逐渐暴露出来,比如问题定位困难,需要联动前端,后面Flutter出来之后,老大又想趁着这次技术更新将动态化切成Flutter,但这不是个简单的工作,需要评估好成本,然后去逐步验证。对我来说项目中采用的旧技术方案就是技术债务,承载了很多业务需求。我这边打算采用的策略是重构,新旧交替,分期付款。在过渡期间做好降级策略,避免引入新技术导致线上问题,能够降级继续使用RN。等到Flutter技术应用稳定之后,才把旧的一套完全废除不再维护。
这周完成的学习目标是软件工程中的系统设计篇,从这周开始就不强求一定要打卡完7天,对我来说习惯的养成比强制性的执行要来的更有效,所以我允许自己有空隙,因为总会有其他更重要的事情可能会打断你。本周的学习最大的收获是,更清晰认识到架构的作用和成为架构师需要培养的思维模式。下周继续学习软件工程中开发编码篇,感谢你的阅读。