这是一个创建于 1872 天前的主题，其中的信息可能已经有所发展或是生改变。
 | 1 chimingphang 2020-10-15 11:33:25 +08:00 +1 |
 | 2 IsaacYoung 2020-10-15 11:35:48 +08:00  28 心得就是老代码能不动就不动 |
 | 3 akagishigeru 2020-10-15 11:37:12 +08:00 1 @IsaacYoung 同感！尤其别人写的，尽量别动，重写都别动 |
 | 4 fatigue 2020-10-15 11:44:22 +08:00 21 心得是，有需求可以先不着急写，先等等看，整理下思路，最主要是可能产品经理马上就又修改需求了 |
 | 5 someonedeng 2020-10-15 11:44:59 +08:00 4 "又不是不能用" |
 | 6 silenzio 2020-10-15 11:46:50 +08:00 5 不要过度设计 满足当下以及未来一段时间(比如半年)的需求就可以了 |
 | 8 dilu 2020-10-15 11:57:52 +08:00 22 1. 先理清思路，画好流程图，做好表结构设计，如果多系统画好泳道图或者时序图。然后在动手编码。(前端 /客户端等方向类似，总得来说就是先设计，落实到文档再开发，一来思路清晰，二来产品可能第二天就变需求了) 2. 不要删以前的老代码，哪怕没有地方调用，因为你永远不知道哪里会有用到的地方。例子：以前有个方法没有调用，后来发现是 n 年前的公众号的接口，差点删了。 3. 不要用任何的骚操作，用最简单，最直接的方法写。变量名方法名能做到`顾名思义`。 4. 不要过早优化，不要过度设计。 5. 技术远远比不上业务重要，延期远远比线上较小事故严重。 6. 简单代码能复制的就复制，效率比你自己写的高。 |
 | 9 labulaka521 2020-10-15 12:09:21 +08:00 via iPhone 山堆 |
 | 10 Kirsk 2020-10-15 12:21:33 +08:00 via Android 看来重构已经没有市场 直接重写一堆屎山 还有 kpi 真香 从一座屎山到另一座 |
 | 11 opengps 2020-10-15 12:25:05 +08:00 4 在业务真的足够强大之前，不要过度去在代码上浪费太多细节时间 |
 | 12 woahishui 2020-10-15 12:28:00 +08:00 via Android 越写越有心得。 |
 | 13 godblessumilk 2020-10-15 12:47:16 +08:00 via Android 心得就是我和血汗工厂的工人没差，离职的时候把代码写得只有我自己看懂报复下乱改需求的 |
 | 14 6ugman 2020-10-15 13:11:49 +08:00 现成的框架 /设计不要用，自己随便写，KPI++ 顺便恶心别人 |
 | 15 stephenxiaxy 2020-10-15 13:37:43 +08:00 这写的是个啥啊 |
 | 16 xuanbg 2020-10-15 13:46:43 +08:00 1 @dilu 补充一点：代码尽量写成相同的结构，相同的结构复制粘贴才方便。大到项目可以整体复制粘贴，小到代码片段可以复制粘贴。 |
 | 17 simple2025 2020-10-15 13:49:54 +08:00 via Android @xuanbg 这个什么意思？ |
 | 18 ZSpirytus 2020-10-15 13:55:39 +08:00 via Android 7 1. 高成本低收益的需求能推掉就推掉，或者降低优先级，浪费时间浪费精力； 2. 拍脑袋需求可以优先级放低，没准哪天产品想清楚了就不做了； 3. 一切都可以追溯，不要口口相传，哪怕是聊天记录也好； 4. 写代码要按照代码规范来写； 5. 代码尽量简单，这样查问题的时候一目了然，而不是还要重新读和理解一遍。 |
| 19 xuanbg 2020-10-15 13:56:35 +08:00 @chenqh 八股文知道吧？只不过把写文章变成写代码，你看到的每个方法只是名称和参数不一样，代码都差不多样子。扩大到每个类也是如此，再推广到模块级别甚至服务级别，都是这个套路。具体的看我的代码就知道了。https://github.com/xuanbg/insight_funds_account |
 | 20 8Cangtou 2020-10-15 14:12:36 +08:00 1 代码只能加，不能删～～～ |
 | 21 YAR 2020-10-15 14:35:47 +08:00 对业务有疑问, 一定要和产品反复沟通和确认, 不然后面有你改的 |
 | 22 leafre 2020-10-15 14:53:08 +08:00 不要过度抽象，越是好的代码越是简单明了，别人一看就明了 |
 | 23 kaiki 2020-10-15 15:02:26 +08:00 想到哪写到哪，宁愿新增也不改旧代码 |
 | 24 charlie21 2020-10-15 15:07:48 +08:00 1 定期做业务系统分析 业务系统全貌分析 业务系统全貌研究，在你的代码查看权限允许的范围之内 把所有代码搞懂 |
 | 25 Justin13 2020-10-15 15:30:23 +08:00 via Android 小车不倒只管推 |
 | 28 Rimifon 2020-10-15 16:22:39 +08:00 1 尽量不要在 if 中套 if，及时 return，使逻辑越来越清晰。 |
29 lifesimple 2020-10-15 16:25:33 +08:00 2 能跑就行，等我有空再优化 |
 | 30 bzluu 2020-10-15 16:25:35 +08:00 收藏一下，刚工作一个半月的菜鸟，学习学习前辈们的心得。 |
 | 31 jones2000 2020-10-15 16:27:18 +08:00 快速实现功能就可以， 反正产品那边经常变动，大概率之前写的业务代码都用不了的。 |
 | 32 Yotako 2020-10-15 16:31:52 +08:00 @IsaacYoung 要动就删了重做 |
 | 33 beidounanxizi 2020-10-15 16:57:36 +08:00 别动别人的代码 可以复制黏贴在此技术上修改。。。但是就是不能改别人的代码 |
| 34 beidounanxizi 2020-10-15 16:58:41 +08:00 1 方法不要写得太长 提倡组合大于继承，别秀无畏的操作 clear is more wisdom than clever |
 | 35 dddd1919 2020-10-15 17:34:38 +08:00 学会起名，效率翻翻 |
 | 36 Jooooooooo 2020-10-15 17:38:15 +08:00 2 不要过度设计 遵守三板斧规范 可监控 可降级 可回滚 |
 | 37 MagnifierSun 2020-10-15 17:59:50 +08:00 1 保证函数功能的单一性, 尽量写无副作用的函数. 不要在看起来是纯函数里改变类成员变量! |
 | 38 yang137162692 2020-10-15 18:22:12 +08:00 马克 一波 |
 | 39 ruoxie 2020-10-15 20:05:16 +08:00 宁愿多复制粘贴几次，也不要写难以维护的“复用”代码。最近临时帮别的项目组赶需求，5 种场景、增改查的弹窗代码全部怼一起，1600 多行代码，真是一坨屎山。 |
 | 40 s5s5 2020-10-15 20:15:32 +08:00 项目内配置好统一代码自动格式化工具 |
 | 41 Jackeriss 2020-10-15 20:21:02 +08:00 via iPhone @IsaacYoung 不完全赞同，该动的时候还得动（如果这块业务你要长期负责的话），但是要找到一个契机，继续往上堆总有一天会发现难以维护，或者有性能问题，趁你还能 hold 住的时候干掉它，省的之后改个需求还得考古一样的阅读别人写的代码，很多 bug 都是因为你没搞清楚别人的逻辑，自己写问题就少很多，效率也高很多。 |
 | 42 iwh718 2020-10-15 21:23:04 +08:00 via iPhone 心得就是：注释很重要 。是把部分代码注释了 以后又继续用下去 |
 | 43 Lanayaaa 2020-10-15 21:57:26 +08:00 楼上都是大佬啊。。 |
 | 44 icyalala 2020-10-15 21:59:50 +08:00 心得就是努力不要写业务代码，业务代码都是屎堆。 再一个心得就是，如果不得不写业务代码，那就不要去捅陈年屎堆。。 |
 | 45 wangyzj 2020-10-15 22:11:32 +08:00 1 三种情况 一种是“写完了完全不知道是个啥” 第二种是“业务人员最后都得听我的，他们开始设计的就是错误的” 第三种是“业务人员自己设计的东西自己不记得，然后我成为业务” |
 | 46 iannil 2020-10-15 22:23:22 +08:00 一切操作都要有记录，给我省了不知道多少事 |
 | 47 insert000 2020-10-15 22:46:42 +08:00 存不存什么复用不复用，客户的想法一天一个变，就算组件化，最后改着改着就成屎山了。架构的再好也抵不过天马星空的需求 |
 | 48 dotw2x 2020-10-15 22:49:04 +08:00 via Android 2 无数次的血泪得出的教训:千万不要相信产品写死，一定要考虑加开关配置!!! |
 | 49 Saszr 2020-10-16 00:56:41 +08:00 不要过度封装 |
 | 50 DoctorCat 2020-10-16 03:13:28 +08:00 如果是一个很复杂的逻辑 /组件，为了保证休假后回来 /长时间再回头迭代时自己不犯浑，一定要写一份设计文档 /笔记给自己… |
 | 51 hambman 2020-10-16 04:27:42 +08:00 大家说的业务代码是相对什么而言？如果不是业务代码，是核心组件代码，比如数据库，会有哪些不同？ |
 | 52 pecopeco 2020-10-16 08:12:10 +08:00 via Android 已经把公司项目代码重构两次了。。就个人来说是有意义的，成功把屎山变成青山绿水 |
 | 53 exceldream 2020-10-16 08:35:01 +08:00 via Android 没人提可测试性，以及单测覆盖吗？ |
| 54 exceldream 2020-10-16 08:36:07 +08:00 via Android 没人提可测试性，以及单元测试覆盖吗？ |
 | 55 sugars PRO 要有预测未来加新功能的能力，不要求写得多漂亮，但写的代码未来方便继续拓展就好 |
 | 57 oma1989 2020-10-16 09:17:07 +08:00 很多没用的代码并不是开发的原因，而是需求变更太频繁。。。。 |
 | 59 pigfly123 2020-10-16 09:21:37 +08:00 1. 产品提的需求如果实现起来很麻烦或者觉得很鸡肋的功能，尽量协商做减法 2. 代码多写注释 3. 不要求有多牛逼的设计模式，但最少不要写成一大坨 |
 | 62 m1ch3ng 2020-10-16 09:47:26 +08:00 牛逼，学习了 |
 | 63 EmotionV 2020-10-16 09:57:56 +08:00 即使两个界面布局类似也要分开写，不要复用，你永远不知道产品经理的脑子里在想什么 当然小组件可以抽离出来 |
 | 64 VintageZ 2020-10-16 10:15:03 +08:00 写业务代码最难得点是：如何在无设计与过度设计之间取得平衡 |
 | 65 leafShimple 2020-10-16 10:15:18 +08:00 别怂 系统是自己负责项目所有代码都走读过后,业务已经清楚的业务场景.如果历史包袱太重影响到后续迭代,直接冲冲冲,改就完了.然后申请测试资源充分测试.不重要的就写点注释或者包一层不看见就不烦了.改完代码一定不要盲目自信不经过测试,即使有单元测试,多测试,多测试.但是也不要追求场景 100%覆盖(因为这做不到) 找准系统的核心.财务系统还是尽量少变动,不要相信跑了很久就没有问题.日志和代码才不会骗人.财务系统多加操作记录. 业务系统是在不同的背景下开发的,有点什么坑也别喷.鬼知道这个项目是不是每天晚上 1 点开发出来的. |
 | 67 MrWhite 2020-10-16 11:00:49 +08:00 @dilu 5 老哥意思是例如一个新功能。尽快把功能先做完。然后又 bug 可以先不修复么。。等被发现在修复？ 可以理解为：做没做完是一回事,做完了有 bug 又是一回事吧。。 |
| 68 dilu 2020-10-16 11:08:27 +08:00 @MrWhite 意思是，不要觉得技术可以凌驾业务之上。技术就是工具，产品怎么说就怎么做，不要觉得`这样做出来更优雅，扩展性更强`。一定要严格按照需求文档进行开发。同时，如果线上有个小问题，例如原本 info 日志打成了 error 造成的报警，同时手上有个需求快要提测，一定要先忙后者。尤其是在微服务团队内，一个人延期就会造成整个项目的延期。 |
 | 69 taowen 2020-10-16 11:13:55 +08:00 |
 | 70 securityCoding 2020-10-16 11:15:47 +08:00 不要瞎几把抽象及时抽出公共代码 , 不要瞎几把过度设计 ,做好业务领域建模 ,写好业务流程注释和文档 233 有个天天奇思妙想的技术老大真的很烦 |
 | 71 shellic 2020-10-16 11:22:14 +08:00 接到需求先不要动手写代码，先把流程理清，表结构规划好，等你做完这些需求就又变了 |
 | 72 wisunny 2020-10-16 11:23:35 +08:00 via Android 完全是语法糖和体力活，真是用到算法的少之又少。。。 |
 | 73 glfpes 2020-10-16 11:32:01 +08:00 日志一定要精心设计，尽可能少打。 |
 | 75 AsunaQAQ 2020-10-16 14:28:14 +08:00 做东西不求快 但求稳 |
 | 76 SunFarrell 2020-10-16 15:01:57 +08:00 这个话题，相见恨晚，坑都经历过了 |
 | 77 watzds 2020-10-16 15:14:21 +08:00 via Android 老代码能不动就不动，该动还是要动，怎么动不出故障也是门学问 |
 | 78 a719031256 2020-10-16 15:23:44 +08:00 有现成的代码绝对不要去写新的代码，费时费力不说，效果可能还没现有的好 |
 | 79 sweat89 2020-10-16 15:41:27 +08:00 好贴 |
 | 80 CoderGeek 2020-10-16 15:44:47 +08:00 大部分是如何不趟坑 ，还有在一堆复杂代码里提出来的东西 比如一个复杂业务扩展和工具集之类的： https://github.com/codeyung/service-support 没啥人看 |
 | 81 gengzi 2020-10-16 16:56:13 +08:00 入参出参影响业务流程的日志写好，防止因为业务问题出错，都不好找问题。 |
 | 82 jimliang 2020-10-16 16:58:02 +08:00 要学会控制自己的情绪 |
 | 84 raaaaaar 2020-10-17 15:18:17 +08:00 有些坑不得不踩，比如过度设计和完全不设计这两个极端，还是要踩的，不然不可能找得到平衡点，还是要经验堆出来。但是有这个念头比较重要，当你什么都想设计的时候，要想想自己是不是有点过度了，这样有必要吗？ 但是有些坑就最好别踩，比如业务和技术的平衡问题，一踩就是大问题。。 |
 | 85 vone 2020-10-17 16:41:25 +08:00 写业务代码容易抑郁。 |
Select Language