软件开发：项目设计思路（流程、功能方法和数据结构） 保险金信托方案设计思路怎么写

软件设计有三个要素：流程、功能方法和数据结构 一 设计流程要点

功能方法考虑性能，流程方法考虑设计模式。

1. 愿景

你需要做个什么东西，要做到什么水平。

2. 边界

你需要干什么，什么你不用干，什么你不能干。

3. 需求

客户给的需求，老板给的需求是功能需求；自己给的需求，代码给的需求是非功能需求。功能需求简单，一眼望穿。难点在于非功能需求。

4. 明确

明确非功能需求（实际上是扯淡）。你只能凭经验明确一部分，大多数还是实践的时候遇到坑反馈给你，你才能明确。所以这里需要明确的是非功能需求的功能方法。

5. 定方案

提炼重点、难点、核心功能。

6. 尝试

有些功能需要调研，写demo，不要一开始写，写出坑，改的时间都没有。

7. 切割

垂直的（分不用模块），前边工作做好了，就开始做划分（子系统、子模块）。 没有关联的能分开就分开，可能分开的是一个子系统，也可能是一个子模块，很多时候是一个文件一个类。

8. 切割

水平的（同一模块分不同层次），就是把一个模块分层。 把一个类分成base sub，一层一层的关联下来。减少改动，提高复用性，容易检查和修改，也容易理解。

[补充一下切割，切割有三要素：数据结构、功能和流程] 1）数据结构关键是思路核心，这个看经验 2）功能简单粗暴，粒度越小越好，单一，不该管的事一律不管 3）流程所谓逻辑，原则是流程就是call call call（调用），流程里一定不要做功能，会很乱，拆不开合不 上，难以重构

9. 分合

就是设计里常说的耦合问题。耦合问题的原则是内聚、外解耦（官方叫 高内聚、低耦合），这里说的分合是什么时候分，什么时候合。

按照7、8部分的切割。能切开的都分，切不开的都合。另外，作为功能集的一定要分；作为框架集的一定要合（不然你写一堆接口 ，自己调着都烦）。

解耦要看实际情况，不要一昧的解耦，当然都耦合在一起，谁痛苦谁知道

10. 职责划分 11. 接口设计 12. 变

复杂一点，需要做抽象，转换，把一个问题转变为另一个问题

13. 换

换个形式，比如使用设计模式，用于改变流程，其实就是改变了代码的理解方式，换汤不换药

14. 仿

就是偷，自己做不明白就偷别人的。先用起来

15. 造

用着用着等你理解了，再去改造成自己的。先要结果，再追求提高

[补充一下仿造] 比如对于设计模式中的工厂方法模式，一开始不理解，可以先拿来在项目中简单模块中使用， 后面用的多了，理解深了就可以改造拓展

二 概念补充

这里对部分概念做一下补充（还是针对 流程、功能方法和数据结构）

1. 重构

重构和设计模式，只能用在流程上功能方法是比较单一的，除非你写的有问题，不然就那几行，没什么可重构的。

主要重构的是流程，流程复杂化、不容易理解和控制。重构就是改的简单容易理解一点，那怎么简单起来呢，应用设计模式一开始的时候，除非你很有经验，不然的话，不用考虑设计模式的问题。当你开始挠头的时候，怎么这么乱，都不想写了，这个时候开始重构，引入设计模式。

2. 数据结构

数据结构影响功能实现和性能。 功能实现基本大家都能做到，其实实现功能根本就不是程序员的追求。追求的是怎么实现好。 如果没有性能问题，不要轻易重构。数据结构在流程里是可以转变的，通过功能方法转变，所以方法设计好了，数据结构和流程是可以解耦的，不太需要关心

3. 功能方法

功能方法设计，简单 简单 简单，不要一个方法做多件事，恨不得它是万能的。相反只要这个方法能做好一件事，就是一个合格的方法， 粒度就是单一，容易拿掉、修改和重现实现，而且便于理解。

设计模式实现是非功能需求，如果想不到适用性，就不要强加，没啥用多写多看，有经验再用

下面是一个 windows项目为例的实用框架搭建 https://blog.csdn.net/qq_27096221/article/details/103645405