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

2020-10-15 11:31:58 +08:00
 jzyff
10831 次点击
所在节点    程序员
85 条回复
Jackeriss
2020-10-15 20:21:02 +08:00
@IsaacYoung 不完全赞同，该动的时候还得动（如果这块业务你要长期负责的话），但是要找到一个契机，继续往上堆总有一天会发现难以维护，或者有性能问题，趁你还能 hold 住的时候干掉它，省的之后改个需求还得考古一样的阅读别人写的代码，很多 bug 都是因为你没搞清楚别人的逻辑，自己写问题就少很多，效率也高很多。
iwh718
2020-10-15 21:23:04 +08:00
心得就是：注释很重要 。是把部分代码注释了 以后又继续用下去 🧐
PainAndLove
2020-10-15 21:57:26 +08:00
楼上都是大佬啊。。
icyalala
2020-10-15 21:59:50 +08:00
心得就是努力不要写业务代码，业务代码都是屎堆。
再一个心得就是，如果不得不写业务代码，那就不要去捅陈年屎堆。。
wangyzj
2020-10-15 22:11:32 +08:00
三种情况
一种是“写完了完全不知道是个啥”
第二种是“业务人员最后都得听我的，他们开始设计的就是错误的”
第三种是“业务人员自己设计的东西自己不记得，然后我成为业务”
iannil
2020-10-15 22:23:22 +08:00
一切操作都要有记录，给我省了不知道多少事
insert000
2020-10-15 22:46:42 +08:00
存不存什么复用不复用，客户的想法一天一个变，就算组件化，最后改着改着就成屎山了。架构的再好也抵不过天马星空的需求
dotw2x
2020-10-15 22:49:04 +08:00
无数次的血泪得出的教训:千万不要相信产品写死，一定要考虑加开关配置!!!
Saszr
2020-10-16 00:56:41 +08:00
不要过度封装
DoctorCat
2020-10-16 03:13:28 +08:00
如果是一个很复杂的逻辑 /组件，为了保证休假后回来 /长时间再回头迭代时自己不犯浑，一定要写一份设计文档 /笔记给自己…
hambman
2020-10-16 04:27:42 +08:00
大家说的业务代码是相对什么而言？如果不是业务代码，是核心组件代码，比如数据库，会有哪些不同？
pecopeco
2020-10-16 08:12:10 +08:00
已经把公司项目代码重构两次了。。就个人来说是有意义的，成功把屎山变成青山绿水
exceldream
2020-10-16 08:35:01 +08:00
没人提可测试性，以及单测覆盖吗？
exceldream
2020-10-16 08:36:07 +08:00
没人提可测试性，以及单元测试覆盖吗？
sugars
2020-10-16 09:03:21 +08:00
要有预测未来加新功能的能力，不要求写得多漂亮，但写的代码未来方便继续拓展就好
wanacry
2020-10-16 09:12:18 +08:00
@xuanbg 没看明白，看了你的代码后没有什么特别的感觉啊，现在的业务代码不都是这么写的吗？
oma1989
2020-10-16 09:17:07 +08:00
很多没用的代码并不是开发的原因，而是需求变更太频繁。。。。
oma1989
2020-10-16 09:18:58 +08:00
@pecopeco 也许换个人再来看也不是青山绿水。。。。（只要是跟自己风格不一致都不是青山绿水）
pigfly123
2020-10-16 09:21:37 +08:00
1. 产品提的需求如果实现起来很麻烦或者觉得很鸡肋的功能，尽量协商做减法
2. 代码多写注释
3. 不要求有多牛逼的设计模式，但最少不要写成一大坨
Nicoco
2020-10-16 09:41:51 +08:00
@dilu 老哥稳的很

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/715159

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX