![](https://img-blog.csdnimg.cn/20201014180756754.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
软件工程
文章平均质量分 77
天黑了g
这个作者很懒,什么都没留下…
展开
-
测试阶段的思考
很多公司的研发用测试出的缺陷数量来衡量测试人员和开发人员的绩效,测试出的缺陷多那么测试人员的绩效好,而开发人员所负责的模块缺陷数量多则绩效差,目标产生了冲突,因此会让两者产生对立。原创 2024-04-19 17:21:43 · 372 阅读 · 0 评论 -
开发文档分析
传统的瀑布模型的开发过程中的文档过重,需要大量时间编写各种文档,比如软件需求规格说明书, 概要设计,详细设计等等。现在的普遍采用的敏捷开发模式,而敏捷宣言中有工作软件胜过全面的文档,意图是最好把更多的注意力放在软件上,而不是把时间花在过于详细的前期文档上。因此,文档应该尽可能轻量化,只写必要的。原创 2024-08-15 10:44:46 · 227 阅读 · 0 评论 -
编码阶段的思考
设计完成后,开发人员就开始编码了,测试人员写详细的测试用例 或基于 API 接口的自动化测试。编码涉及到 git 分支如何控制,是否要先写单元测试,是从上到下,还是从下到上的编码,如何前后端联调,代码是否要检视,如何检视,如何尽可能早地测试。原创 2024-04-19 17:19:54 · 1351 阅读 · 0 评论 -
设计阶段的思考
概要设计时不仅仅关心的是否能很好的实现本次精华后的需求,更多的还要关注是否领域模型的划分,设计的模块是否高内聚低耦合,保存足够的灵活性,是否已有部分需要重构,原先部分是否可以复用,技术选型是否项目总体的选型, 这样才能防止整个项目腐蚀,及时归还技术债务。敏捷式设计主要是原有的重构和当下的设计,这样所做的工作都是有效的,虽然敏捷设计会让原有的代码模块重构,但通过自动化测试,使得编码级的变更成本显著降低,再加上不断地重构优化代码结构,使得模块之间耦合足够低,代码保持整洁,这样也会使得重构成本不会增高。原创 2024-04-19 17:15:02 · 476 阅读 · 0 评论 -
需求分析的思考
需求评审过程中,如果出现大的争议,并且现场很难确定,并且影响后续大量的需求细节,可以先暂停会议,等这些问题解决了后再继续会议,一般的非关键性问题,现场也解决不了的,可以先记录下来,会后解决后再通知给大家。需求评审时,谨防临时添加更多的需求功能点,最好等这些必要基本功能上线后,根据用户的反馈再来完善,否则,不仅很容易白做,而且还引起返工。但这种用户故事列表,缺乏需求全局信息,在创建用户故事列表前,最好有一个总体需求分析,了解需求背景,要实现商业核心目标,参与的主要角色,使用的主要场景,核心的业务逻辑等等。原创 2024-04-19 17:05:08 · 429 阅读 · 0 评论 -
敏捷开发的思考
例如,我们要规划盖一个 100 层的摩天大楼,敏捷开发就是,先搭一层的基地盖一层楼交付给客户,根据客户的反馈,这一层楼再做哪些调整,要不要继续盖第二层,如果要盖第二层,开发团队先要做的是调整基地结构,使其能支持后续几层楼修建,然后再继续加盖。在实际当中,这些架构设计上的调整,已有功能的重构优化,客户和市场都不怎么愿意,毕竟不能直接产生业务上的价值,程序员也不愿意,因为眼下能运行就好,多一事不如少一事,但对项目开发又是至关重要的,否则,简单地堆砌代码,导致越来越臃肿,难以维护,最后会浑然倒塌。原创 2024-04-19 16:47:29 · 272 阅读 · 0 评论