想讨论一下工程能力，比如写大型项目与脚本的思路差别。

[calmzhu]

自己本身做运维的，主要工作是开发...最初写代码都是脚本工具居多。
现在开始用 springboot/django + vue/react 等轮子搭建平台。
但是感觉还是按脚本的思路写的。想理清一下软件工程需要注意的点。

在代码 /算法等等之外，还有哪些好的实践需要注意的呢，有三个问题

脚本代码思路问题： 拿到需求，简单理下思路，就直接写代码了。

• 维护时，日志，异常处理都很随意，估计就自己有耐心维护了
• 代码没有整体规划。需要返工乃至重来。Django mvc 定义 model 时，发现数据对应关系不通，推到重来

软件工程项目： 拿到一个需求，在开始写代码之前，大家会做哪些准备？

有些简单通用的大家已经成为潜意识，或者在框架里面自带的不用操心的也算。之前看提过关系原型设计，是指什么

一个好的软件工程需要包括哪些实践呢？

下么列举的这些算不算，还包括哪些

• ？代码注释
• ？文档
• ？自动化部署
• ？测试
• ？日志监控
• ？异常处理

[heiheidewo]

个人觉得这几点最重要：
1. 设计文档，数据流程（各模块职责划分）
2. 代码质量 /代码规范、代码注释
3. 单元测试、自动化测试
4. 日志上报、异常监控

[calmzhu]

@heiheidewo
谢谢回复～两点问题
**设计文档**
一直没注意过，我查一下实践

**单元测试**
听说推荐先写单元测试,用单元测试理清隔逻辑分支后再回来写文档？

[ybw]

从不写设计文档, 不喜欢过早设计。

[heiheidewo]

@calmzhu
简单点理解：
“设计文档”就是写代码前想下这个系统可能有哪几个模块，每个模块是干嘛的，模块之间是怎么交互数据的，等等，最好是写成文档，方便自己或者别人后续维护。
“单元测试” ，当然是先写代码，再写单元测试呀，针对各个独立模块尽可能覆盖所有路径的测试样例，比如你写一个 Map 类，是不是要测试基本功能：增删改查，每次修改代码都跑一遍单元测试，可以尽量保证你的代码不会引入 bug

[calmzhu]

@ybw
谢谢回复～

暂时倾向于一种流程是， 需求实现思路 --(丰富细节)-->大纲 --(丰富细节)-->代码

设计文档应该是大纲的形式之一。如果不用设计文档的话，那么写代码之前用什么方式理清框架，以避免比如 djangp model 关系写到一半感觉不对，最后返工这种问题。

个人理思路是用思维导图的形式，但是到代码产品这一块感觉不是很适合

[calmzhu]

@heiheidewo
谢谢回复～（原来回复不是 markdown 语法）

“单元测试”的没问题了。
“设计文档” 明白什么意思了。仍有一个疑问，写成完整文档的成本是不低的。在设计基本完成之前可能有变动的情况下。有哪些办法可以让自己跟别人审阅所说的模块划分，数据交互这些呢。目前只知道的 UML 一种，想学习一下各位都是怎么做的

[NeinChn]

大型项目首先肯定是理清需求,分析依赖,总结文档

比如你的需求中需要依赖 a,b,c,d,e 这几个外部 /内部服务的输出

写脚本 /做策略很多同学真的就直接串行调用这 5 个服务了,反正速度和效率不是考量范围

实际上根据具体需求和场景,是可以将这些依赖并行处理,更有效率的处理的

做工程是需要考虑一下超时 /吞吐 /性能 /扩展性的.

对于每个流程都要做 bench mark,知道大概每个处理流程的时间消耗,对资源消耗有明确的范围预估

当然如果没有什么请求量,没有 timeout 限制(或者 1s 以上),那请随意,实现功能为主.

[CoderGeek]

1.产品需求
2.ER 图（数据结构）
3.项目架构
4.流程设计
5.接口返回值定义
最少要上面
1.2.4.5

[netty]

抛点想法：

1.点和面
1 ）一个需求
一个需求只是一个点，解决某个具体的问题。
2 ）项目
一个项目是面，包括了许多需求点，要解决非常多的问题，而且问题之间可能还有关联性。

2.需求分析
1 ）一个需求
通常来说，需求已经是明确的，或者说是明显的。
比如说，监控某个进程是否存在。这个需求很明确，当然实现方式有许多种。
2 ）一个项目
对于一个大项目来说，通常刚开始需求是相对模糊的，只有一个比较泛的目标。
比如说，要做一个自动化发布系统，能让用户自助配置，自助发布，支持回滚。
这个时候，千万别急着动手。
你以为很简单，写几个脚本，安装到系统变成几个命令，支持动态项目路径、启动关闭等参数。结果被需求方喷都 0202 年了你们这么 low。。。
你以为很复杂，了解了 BAT 的发布系统功能非常强大，自动化强度非常高，我也搞一个。结果一个月过去了，设计才搞定。结果被需求方喷一个月过去了，连个界面都没有。。。

需求方具体要的是什么？要多沟通，需求文档化，流程化。经过多次沟通迭代，最终形成一致的需求文档。

3.设计、实现
1 ）一个需求
基本不需求考虑设计的问题，简单的梳理一下思路就可以 coding 了。
2 ）项目
需要考虑系统的整体架构，包含哪些功能模板，涉及哪些系统，系统的部署方案等。
需要考虑开发与维护成本，涉及到技术选型，自己开发还是使用第三方，后续改造维护是否方便等。
需要考虑用户体验，傻瓜一点用户才肯用才会用。

[heiheidewo]

@calmzhu 对，是需要花时间，可以先写大纲，写代码过程中补充细节，这个看团队的风格了，当然大部分团队是不写文档的。
PS: 写文档？想啥呢，老板的需求下周上线，赶紧写代码。

[calmzhu]

@NeinChn
谢谢回复。

- 超时
- 吞吐
- 性能
- 扩展性

这几点都没怎么遇见过的。偶尔出现处理方式都很粗暴
比如
- 脚本偶尔出点超时问题，直接无视，重来
- 性能不够直接把源数据拆几份多跑几遍

学到了。

[abcbuzhiming]

软件工程的重点是“与人协作”。不需要与人协作的话，你几乎不需要软件工程，只要你隔几个月回来看代码时（那时等于未来的你和过去的你协作）不被翔山熏死就行

[calmzhu]

@CoderGeek
谢谢回复～

1.2.3 基本明白了。4.5. 暂时没有概念。我先了解一下。

[orzorzorzorz]

既然是做运维的，那不妨在这个层面上深想一些。比如记日志是为了看什么的，工具是为了解决什么问题的，这些常用的日志 / 工具我是不是能独立出来方便管理，核心思想是为了避开坑以及方便。

工程核心思想大部分也是为了这俩。比如楼上说的发布功能，你做计划的时候就得想想，这东西受众是谁？如果只是自己，那随便做；如果是面向全国人民的，那就得考虑必须考虑如果避免被 12306 一样刷爆。这里就有个分支，我该减少经过服务器的流量还是给服务器压力顺着流量来。这里又会多出两个分支，前者的做法会不会影响产品的营销，如果可以...，如果不可以...；后者的话，可行性方案是什么样的。这里草草结束了最开始设立的分支，继续下一个分支。

什么时候开始写代码？你得对上面这些选择题里的解决方案的实施有了十分的把握，那才开始写真正的代码。如果没把握，就得不停地写 demo 以测试可行性。到真正实施的时候，代码写得什么样其实无所谓了，什么算法啊结构啊都不太重要，因为你架子已经有了，再差也有架子的下限。

你以为到这就结束了？设计里你还得把人际考虑进去，谁谁谁算法强一些，那划出来重算法的模块给他；谁谁谁...然后你还得考虑这个人我能不能借到，借不到还得去跟别的组扯皮...

你妈的，我要去知乎里答一下“我为什么从 xxx 离职”了。

[calmzhu]

@netty
谢谢回复～

点跟面的视角独特又犀利。从点跟面角度看，我是这么理解的，面里面的每个点都是确定的，但是整个面要哪些点不要哪些点却是不确定的。点是一维定向策略。面是多为模糊策略。

就像软件工程是什么没有一个公信答案，因为这是一个面。但是我想如果把这个面里的每个点都找出来。那么可以做一个“软件工程可以是什么”的回答

又收获了几个点。软件工程的外延已经成功拓展到软件之外了。
- 成本
- 技术选型
- 用户体验

最后好奇，你这个项目最终咋样了。

[calmzhu]

@heiheidewo

哈哈。是的。不仅会排出写文档，后面问为啥没有文档可能还是同一拨人。。。

[clf]

公司里的大致流程：
1.讨论需求（业务逻辑先理清楚）
2.原型设计（把前端界面的原型和交互逻辑定下来，这些会影响后续接口的逻辑）
3.数据结构设计（考虑数据的拓展性和向下兼容性）
4.接口设计（一般用 mockjs 的语法设计，mockjs 能部署虚拟的 mock 服务器，方便前后端分离开发）
5.前后端分离开发（按照先前设计的接口进行开发，避免前端等后端的情况）
6.逻辑性和功能性测试（单元测试，一般与业务流程关系不大）
7.验证网部署测试（业务流程测试，期间产生的 BUG 通过 issue 指派给相应人）
8.测试完成，合并到 release 分支进行部署

[calmzhu]

@abcbuzhiming
谢谢回复
其实最初是觉工程什么的太花里胡哨的了，不想多费时间。。不过在被自己的几个项目熏吐了之后，就开始重视了解这方面的了。网上断续获取到的信息很零散。所以过来发帖请教看看能不能凑出一张相对不那么局限的地图。

[plko345]

和 lz 情况相似，在用 flask

[otakustay]

我厂的软件工程标准（服务器端部分）

https://i.loli.net/2020/02/16/nBIJKoTuHXpcqgl.png