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

[calmzhu]

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

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

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

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

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

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

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

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

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

[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]

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