大家写业务代码有什么心得吗？

[jzyff]

[chimingphang]

+1

[IsaacYoung]

心得就是老代码能不动就不动

[JaguarJack]

@IsaacYoung 同感！尤其别人写的，尽量别动，重写都别动

[fatigue]

心得是，有需求可以先不着急写，先等等看，整理下思路，最主要是可能产品经理马上就又修改需求了

[someonedeng]

"又不是不能用"

[silenzio]

不要过度设计
满足当下以及未来一段时间(比如半年)的需求就可以了

[jzyff]

@fatigue 让需求飞一会？

[dilu]

1. 先理清思路，画好流程图，做好表结构设计，如果多系统画好泳道图或者时序图。然后在动手编码。(前端 /客户端等方向类似，总得来说就是先设计，落实到文档再开发，一来思路清晰，二来产品可能第二天就变需求了)
2. 不要删以前的老代码，哪怕没有地方调用，因为你永远不知道哪里会有用到的地方。例子：以前有个方法没有调用，后来发现是 n 年前的公众号的接口，差点删了。
3. 不要用任何的骚操作，用最简单，最直接的方法写。变量名方法名能做到`顾名思义`。
4. 不要过早优化，不要过度设计。
5. 技术远远比不上业务重要，延期远远比线上较小事故严重。
6. 简单代码能复制的就复制，效率比你自己写的高。

[labulaka521]

💩山堆💩

[Kirsk]

看来重构已经没有市场 直接重写一堆屎山 还有 kpi 真香 从一座屎山到另一座

[opengps]

在业务真的足够强大之前，不要过度去在代码上浪费太多细节时间

[woahishui]

越写越有心得。

[godblessumilk]

心得就是我和血汗工厂的工人没差，离职的时候把代码写得只有我自己看懂报复下乱改需求的

[6ugman]

现成的框架 /设计不要用，自己随便写，KPI++ 顺便恶心别人

[stephenxiaxy]

这写的是个啥啊

[xuanbg]

@dilu 补充一点：代码尽量写成相同的结构，相同的结构复制粘贴才方便。大到项目可以整体复制粘贴，小到代码片段可以复制粘贴。

[chenqh]

@xuanbg 这个什么意思？

[ZSpirytus]

1. 高成本低收益的需求能推掉就推掉，或者降低优先级，浪费时间浪费精力；
2. 拍脑袋需求可以优先级放低，没准哪天产品想清楚了就不做了；
3. 一切都可以追溯，不要口口相传，哪怕是聊天记录也好；
4. 写代码要按照代码规范来写；
5. 代码尽量简单，这样查问题的时候一目了然，而不是还要重新读和理解一遍。

[xuanbg]

@chenqh 八股文知道吧？只不过把写文章变成写代码，你看到的每个方法只是名称和参数不一样，代码都差不多样子。扩大到每个类也是如此，再推广到模块级别甚至服务级别，都是这个套路。具体的看我的代码就知道了。https://github.com/xuanbg/insight_funds_account

[8Cangtou]

代码只能加，不能删～～～