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

[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

[calmzhu]

@orzorzorzorz

谢谢回复～

又收集到两点

- 可行性
- 对业务的影响，比如是否支持促销的大压力（这个和之前提到到的性能 /扩展性是不同的。得让业务知道流量到什么级别系统会崩，促销打个招呼）

人际这块现阶段无解。但是我认为软件工程会最终作为一种减少内耗的方式推广成为社会管理工程。从这个角度的话，要明确两点
- 这个项目哪些内部员工，哪些外部客户会受益
- 这个项目哪些内部员工，哪些外部客户会受损
这时候才能作出可接受的利益平衡。

作为底层搬砖工，我对脏活的定义是
假设绩效有用
1. 这件事要费不少时间，才能合格
2. 这件事做好后，我的绩效不会有任何增益
3. 这件事没做好，非常影响自己在他人严重的价值。甚至扣绩效。
这种脏活，能躲就躲。

[Cbdy]

先把核心功能 /主流程 /核心算法跑通，然后慢慢改

[sicauxeon]

比较大的工程除了项目本身实现上的困难外，也需要关注建模的难点。

首先，实现上需要注重代码质量，有没有 code review，项目是否接入单测，单测的质量，ci、cd 等基础设施。

项目的领域模型是否科学合理，这是架构师层面关注的。

互联网产品关注业务的数据，业务产生的数据如何高效接入内部的大数据平台，供数据分析和运营同学使用。是否接入了监控中心，服务是否有完善的告警及时通知到开发。

估计项目的流量，以及未来的增长，评估机器的开销。是否已经有在使用的缓存、消息队列、存储、LB 等资源，机房可供扩容的机器数量。这里可以对服务压测，监控整条链路上机器的水位，服务的平响。

然后你列举的代码注释、日志、异常处理看看其他公司的 best practice，比如阿里的那份。

[AilF]

学习下楼上各位大佬

[bxqqq]

补充一点；
你写一半发现东西 model 数据没有设计好，说明你开始没有想清楚，设计文档是让你想清楚的，但是这是手段，你如果能想清楚没有文档也没问题，同理，你想清楚了，代码也只是实现手段。 (要注意数据(结构)之间的关系，你可以想一下，它们合理的交互对工程意味着什么)。

[nightwitch]

补充一点
分割技术难点，做好调研，不要重复发明轮子或者使用不适合自己工程的轮子

[murmur]

大型项目最重要的不是设计，是需求把控，什么先做，什么能做，什么坚决不做，再牛逼的设计扛不住做一半大改需求

[arjen]

@otakustay 老哥是 EE 的吗？

[zichen]

@CoderGeek +1，我现在写设计文档这些基本都是必写的。

[zichen]

@otakustay 这里面绿的不少啊，工程能力地图分应该不低，晋升有望。

[otakustay]

@zichen
@arjen
地图本来就是我开发的，能差吗……

[zjsxwc]

天天重构，看着不爽就重构，反正就是尽量按照 solid 原则写

[LDa]

上班三年最深的感触就是
大型项目 设计优先、文档优先