这几天在网上看了电影《最好的我们》，主演是陈飞宇和何蓝逗，其中女主的表演之细把人物演活了，特别是眼睛的表演，通过眼睛和面部的表情，再加上应景的音乐，高中生的形象展现在观众面前，不经使人回想起自己的高中生活和备战高考的场景，容易产生共鸣，不管是否忠实原著，仅仅是上面的几点可以说是一部好电影。
在软件设计中同样有很多细节，好的软件和工程代码实现上，质量的好坏其实都是表现在细节上。在软件的系统设计过程中，细节可以说到处都是，如何通过细节的设计提高软件的工程质量，可以从几个方面来考虑
1、业务流程细节体现
在实际的业务流程的分析上，不能停留在客户说什么，你就实现什么，客户不是专业的计算机人员，只能在业务流程表面上给与帮助，业务流程的梳理还是需要设计人员深刻理解业务，将业务抽象出模型，通常业务流程中，特别是环节和环节间的连接很容易出现问题，需要认真对待。
另外一个细节就是环节中的异常，在实际的业务环节中是如何处理的，比如生产订单出现返工，工厂是如何处理的，业务流程可以是将此重新生成新的订单进行生产，重新排进生产计划，也可以是订单返回上一环节。
系统设计人员在进行业务流程模型化的设计过程中，最好有多个模型的设计方案，一个是留有后手，以应对业务的不可知的变化，另一个作用是为更好地找到适合的方案，是一个综合比较的过程。
2、架构中细节体现
架构中对层次的划分，层次的设计对软件架构也是很重要，层次多了软件就会变复杂，实现和维护都比较困难，层次少了，软件结构化就不是很好，容易产生粘连。同时静态的层次设计应该和软件动态设计统一起来，这样对于层次间的通讯或者是调用关系就会比较简单明了，一般的设计原则都会讲业务作为单独的一层，这一层都是动态设计，有运行任务，在业务的上一层通常是表现和UI交互，在业务层下的一般为业务支撑层次，这一层基本上是功能模块层，提供业务所需要的各项功能。
层次间尽量不要跨层次通讯或调用，如何有比较多的交互的话，中间的层次肯定设计有问题，要么是层次过高，要么就是功能没有归一化好。
同一层次中模块间的交互设计过程中尽量不要有，及时有，也要通过上面层次来交互，因为在同一层次间进行交互，容易导致调用关系的混乱，使得架构关系变得复杂。
3、功能分解的细节体现
将功能分到不同的模块中，不能有交叉的情况，比较一个规格，模块A有一部分，模块B有一部分，这种情况就是没有把规格定义好，应该是一个规格就是一个模块来实现。在实际的设计当中常常会出现规格大小定义的问题，到底一个功能要有多少个规格来组成，设计粒度大小的问题，比较考验水平。通用的做法是将规格相关性强的放到一个模块中，有点物以类聚的感觉。
4、运行关系的细节体现
大多数软件都是多任务系统，所以充分利用时序图来进行多任务的交互设计，以及任务状态迁移图对任务运行内部的设计。
时序图的设计可以最大程度描述运行的时间顺序，将不同的执行流程放到不同的任务中，这个业务设计中需要进行细致设计的地方，如何进行合理的任务划分，通常是按资源来进行，一个资源的使用尽量安排在一个任务中，可以避免引入竞争，减少复杂度。
另外在时序图中，注意调用关系，同步调用和异步调用，异步执行的流程，而且这个在实现过程中常常出现问题，系统设计人员要将此部门明确地描述出来，越详细越好，因为在编写代码的过程中，实现人员的视野聚焦点在自己的模块上，容易忽略全局的关系。
4、模块交互的细节体现
通讯的设计，多任务系统下必须有的，通常是消息的方式进行，这是典型的异步方式，所以运行时序图和任务状态迁移图就是基础，如果前面这两者设计得好，此处消息定义就非常简单，定义消息时保留些余量；
另外消息设计过程中，消息也不需要发散定义太多的消息，满足任务状态迁移即可，同时任务状态也应该尽量少，要不然状态迁移的条件也会很麻烦，容易把人搞晕；
共用信息的设计，包含结构体，类的设计，访问的设计（单任务访问还是多任务访问）
调用参数的设计，对于容易变化的参数使用数据结构的方式进行传递，保证接口的一致，扩展性也比较好。
5、调试信息的细节体现
通常是日志打印信息和状态量和统计量，往往在设计过程中被忽略，定义统一的调试信息对于软件质量也有很好地促进作用。
就先写这么多，总之细节是魔鬼，但这个魔鬼会让用户为此入迷，你的产品还能卖不出去吗？
