软件设计与实现
分析和设计有许多方法,比如以文字为主的文档、以图形为主的模型、用数学语言描述、注释加代码等。
图形建模和分析方法
思维导图Mind Map
思维导图形式灵活,适用于很多鼓励探索、发散思维的场合,但是它的图形元素缺乏严格的语法和语义。
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232312824-106539908.png)
实体关系图Entity Relationship Diagram
着重表达实体之间的联系时可以用实体关系图,例如:
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232340851-484745867.png)
我们可以将各种词汇来与ERD图中的元素对应起来:
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232402681-1255170814.png)
用例也有图形化的表示,也就是Use Case Diagram,UCD。用例图主要有下列几种元素:参与者、系统、用例和信息传递线。
表达数据的流动Data Flow Diagram
关注数据在不同实体之间的流动时,可以用该图表述,以图书管理系统为例:
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232427117-1507878707.png)
每个数据的操作还可以进一步细化,形成一个更低层次的DFD。
表达控制流Flow Chart
也就是基本的流程图,此外还有有限状态自动机(Finite State Machine,FSM),它是由一组状态、一个起始状态、输入、将输入与现在状态转化为下一个状态的转换函数所构成。
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232457120-204153581.jpg)
统一表达方式UML
全称是Unified Modeling Language,UML使用了统一的表达方式来完成图形建模,是一个非常成熟的理论,但是对于它能否清楚的表达还有待争论。
从Spec到实现
一个开发人员拿到设计文档后,他会做下面几件事情:
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232527956-454914337.png)
将开发人员的标准工作流程用图来表示:
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232552788-1722293011.png)
开发阶段的日常管理
闭门造车Leave Me Alone
有很多开发人员在工作中会出现忙了很久,却发现真正用在开发上的时间很少的情况,此时应该面对不同的任务或邮件,分优先级处理,分批查看和解决。
另外,不要主动查看测试人员发现了什么bug,而是经过会诊之后正式提交到你手上再行动,防止做无用功。这是因为开发人员在开发阶段最重要的任务就是完成规定的功能(有时在项目初期,可以不用等到集体会诊结束,开发和测试人员可以直接处理bug)
每日构建Daily Build
编译时要产生debug版(调试版本,包含调试信息,不包括优化)和release版(发布版本,进行了各种优化,让用户更好的使用)。
构建时如果出现失败,就要分析构建失败的原因,然后对症下药,让做事不仔细的人慢下来,对于导致构建失败的成员,可以授予构建大师Build Master称号,他负责管理构件服务器,负责找错和调试,而且把该称号传递给下一个导致构建失败的成员,也可以进行罚款,设置一个构建基金。
宽严问题
有时在修改完代码然后提交到服务器后,发现有人签入了与我的代码有关的新修改,导致版本冲突,如果再次本地编译并测试又会浪费大量时间,而且还有可能遭遇新的版本冲突,此时应该怎么办?
如果在签出一个文件时,加上一个防止别人签出的锁,就可以防止冲突。但是这样的锁多了可能又会导致死锁现象。因此面临这种问题时,团队一般有两种选择:
1、严格的规则和流程控制,这样做个人签入成功率很高,但是团队的进展会受到限制
2、宽松的规则和流程,每个人都可以随时签入签出,但是签入的成功率不高
此时要根据团队目前的情况来选择应对策略,选择时要注意,当团队成员的行为只是影响到个人时,就尽量放松,当其行为影响到整个团队时,就尽量严格。我们也可以公开固定的构建时间。下表就是构建宽严表:
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232615712-1858701225.png)
以某公司的具体开发流程为例,时间安排至关重要:
![](https://img2020.cnblogs.com/blog/1742600/202003/1742600-20200326232638953-2028307058.png)
小强地狱Bug Hell
随着项目进展,开发人员手上的bug数会越来越多,有些开发人员喜欢新功能全部实现后再修复bug,但是某些bug久久不修复可能导致的后果很严重,可能会重写一些功能,导致设计变更需求,也就是DCR。因此有这样一种方法可以避免这种情况,这就是小强地狱Bug Hell。
如果开发人员手中的bug达到某一规定值,那么这个人就被送入小强地狱,在地狱中,他唯一能做的就是修复bug,直到bug数低于此阈值,这个值通常由团队根据实际情况确定,注意开发人员同时入狱的人数最好不要超过50%,且阈值不宜频繁调整,可以在每天早上例会时宣布入狱和出狱名单。