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

[jzyff]

[Nicoco]

@ZSpirytus 看来是老工程师了！

[m1ch3ng]

牛逼，学习了

[EmotionV]

即使两个界面布局类似也要分开写，不要复用，你永远不知道产品经理的脑子里在想什么

当然小组件可以抽离出来

[VintageZ]

写业务代码最难得点是：如何在无设计与过度设计之间取得平衡

[leafShimple]

别怂 系统是自己负责项目所有代码都走读过后,业务已经清楚的业务场景.如果历史包袱太重影响到后续迭代,直接冲冲冲,改就完了.然后申请测试资源充分测试.不重要的就写点注释或者包一层不看见就不烦了.改完代码一定不要盲目自信不经过测试,即使有单元测试,多测试,多测试.但是也不要追求场景 100%覆盖(因为这做不到)
找准系统的核心.财务系统还是尽量少变动,不要相信跑了很久就没有问题.日志和代码才不会骗人.财务系统多加操作记录.
业务系统是在不同的背景下开发的,有点什么坑也别喷.鬼知道这个项目是不是每天晚上 1 点开发出来的.

[dilu]

@Nicoco 奇怪 最近很多人艾特我，我都收不到消息，难道我被降权了？

[MrWhite]

@dilu 5 老哥意思是例如一个新功能。尽快把功能先做完。然后又 bug 可以先不修复么。。等被发现在修复？ 可以理解为：做没做完是一回事,做完了有 bug 又是一回事吧。。

[dilu]

@MrWhite 意思是，不要觉得技术可以凌驾业务之上。技术就是工具，产品怎么说就怎么做，不要觉得`这样做出来更优雅，扩展性更强`。一定要严格按照需求文档进行开发。同时，如果线上有个小问题，例如原本 info 日志打成了 error 造成的报警，同时手上有个需求快要提测，一定要先忙后者。尤其是在微服务团队内，一个人延期就会造成整个项目的延期。

[taowen]

https://github.com/taowen/modularization-examples

[securityCoding]

不要瞎几把抽象及时抽出公共代码 , 不要瞎几把过度设计 ,做好业务领域建模 ,写好业务流程注释和文档

233 有个天天奇思妙想的技术老大真的很烦

[shellic]

接到需求先不要动手写代码，先把流程理清，表结构规划好，等你做完这些需求就又变了

[wisunny]

完全是语法糖和体力活，真是用到算法的少之又少。。。

[glfpes]

日志一定要精心设计，尽可能少打。

[matrix67]

@glfpes #73 为啥是少打

[AsunaQAQ]

做东西不求快 但求稳

[SunFarrell]

这个话题，相见恨晚，坑都经历过了

[watzds]

老代码能不动就不动，该动还是要动，怎么动不出故障也是门学问

[a719031256]

有现成的代码绝对不要去写新的代码，费时费力不说，效果可能还没现有的好

[sweat89]

好贴

[CoderGeek]

大部分是如何不趟坑 ，还有在一堆复杂代码里提出来的东西
比如一个复杂业务扩展和工具集之类的： https://github.com/codeyung/service-support 没啥人看