这是一个创建于 1965 天前的主题，其中的信息可能已经有所发展或是发生改变。
写代码有时候会很烦躁，主要出现的情况有几个方面：
1，反复修改需求
2，花了很大精力去写，却没有写出来
3，以为自己想了一个很巧妙的解决方法，却在查资料的时候浪费了大量时间
4，以为自己写了一个很巧妙的算法，结果却并没有多大用(如：用冒泡排序排 3 个数字大小)
5，花了很长时间完成的项目，后面说不要了
以前会硬着头皮继续干，有的是因为时间赶，有的是直接闷头继续做，当然效果很差，有厌烦的情绪。
后面发现，如果需求不是特别急，隔一两天再去思考需求会更高效，也就是没有那么大的厌烦情绪。
这种方法也适合遇到难题，最好让自己注意力放到其他地方，隔天再看会有意想不到的效果。
还有说一点，听音乐的话，听一些工作的轻音乐，不要流行音乐，否则有时候会扰乱心思，当然一般我写代码都是两耳不闻窗外事，沉浸在代码里。
大家有什么对写代码好的经验可以分享下，特别是对厌烦情绪的发泄。
1，反复修改需求
2，花了很大精力去写，却没有写出来
3，以为自己想了一个很巧妙的解决方法，却在查资料的时候浪费了大量时间
4，以为自己写了一个很巧妙的算法，结果却并没有多大用(如：用冒泡排序排 3 个数字大小)
5，花了很长时间完成的项目，后面说不要了
以前会硬着头皮继续干，有的是因为时间赶，有的是直接闷头继续做，当然效果很差，有厌烦的情绪。
后面发现，如果需求不是特别急，隔一两天再去思考需求会更高效，也就是没有那么大的厌烦情绪。
这种方法也适合遇到难题，最好让自己注意力放到其他地方，隔天再看会有意想不到的效果。
还有说一点，听音乐的话，听一些工作的轻音乐，不要流行音乐，否则有时候会扰乱心思，当然一般我写代码都是两耳不闻窗外事，沉浸在代码里。
大家有什么对写代码好的经验可以分享下，特别是对厌烦情绪的发泄。
 |
1
javaWeber 2019-08-13 10:20:52 +08:00
写代码其实还好。。读代码就感觉有点心累。
有时真的不知道之前的老哥为什么要那样实现。 又不敢随意重构，出了问题要背锅，只能修剪一些边角。 |
 |
2
yamasa 2019-08-13 10:30:25 +08:00  1
曾经想写一个 mini RDBMS 却没有能执行下去，对 2 深有体会。
对于 3 和 4，不觉得是浪费时间或者吃亏。尤其是 4，有些时候以为自己考虑出了一个精妙优雅的算法或者解决模式，最终却发现早几年甚至十年别人的轮子里就实现了，还远比你实现得健壮。个人认为这其实是很不错的学习过程，也是能理解部分源码最深的方法之一---自己去踩踩坑才知道别人为什么要套那几层模式，非得要写的这么绕。 |
 |
3
iPhoneXI 2019-08-13 10:34:42 +08:00 via Android
1 5 是项目流程问题，产品经理的锅，可以定个规章，某个阶段之后不允许改需求，不然造成的 bug 延期由对方背锅
2 3 4 还是输入不够多，多看开源项目啥的挺有效 |
 |
4
henices 2019-08-13 10:36:16 +08:00 2
我这么多年的经验是：
1. 一定要想清楚再开始写代码 2. 基本结构稳定后，就不要大改，每次修改都要有充分的理由 3. 遇到新想法先记下来，知道后面真的觉得可行在改代码 4. 不要自造伪需求，多分析 总而言之，慢即时快，少修改，少返工。 |
 |
5
Caballarii 2019-08-13 10:37:12 +08:00 1
改需求这种事太正常了，琢磨琢磨怎么把系统结构组织好能应付大部分变动还是挺有意思的
|
 |
6
jydeng 2019-08-13 10:40:52 +08:00 1
一点点经验：
1、尽量选择时下热门的技术或者框架库 2、先明确需求，多分析、设计，不要着急开始编码 3、不要过度设计，以及过早重构，但要预留一定的空间 |
 |
7
polebug 2019-08-13 11:02:33 +08:00
|
 |
8
wysnylc 2019-08-13 12:29:57 +08:00 1
先做设计画图,弄清楚逻辑,写好要点防止遗忘
多谢注释多思考,剩下的就是每次优化自己的逻辑和思路 |
 |
9
www5070504 2019-08-13 12:42:24 +08:00
代码垃圾非我意,自己动手分田地
你若气死谁如意,谈笑风生活长命 写了两年 现在改需求这种事我都已经有点习惯了 刚开始的时候气得要死 |
|
10
www5070504 2019-08-13 12:43:16 +08:00
以前生气是因为想好怎么写 或者 写一半了说要改 就很气
现在是因为所有需求我都先拖一下 看看他 PM 到底要不要改 如果大概确定不改或者改动不大再写 |
 |
11
AndroidEngineer 2019-08-13 12:55:45 +08:00
坑踩的多了，就没有坑了
|
 |
12
good1uck 2019-08-13 13:02:30 +08:00
也许就是“实际工作“和”兴趣“的矛盾吧！需要平衡一下；
|
 |
14
HuHui 2019-08-13 13:03:45 +08:00 via Android
这个就是广度还是深度的问题了
|
|
15
good1uck 2019-08-13 13:03:48 +08:00
探索的过程是充满了不可谓外人道也的乐趣的，不过要说到”实际价值“，就不是一件私人的事了。
|
 |
16
xiaotuzi OP @yamasa 所谓考虑兼容吧，考虑了兼容，就会多写，然后就…写了一大堆…最后项目没过一年 GG 了🌚
|
 |
17
q8164305 2019-08-13 13:06:14 +08:00 via Android 1
各位先思考再写代码是认真的么？大部分项目生命周期都很短的啊，没必要写那么好，我的原则永远都是先完成功能，有时候再重构，没时间就烂在那吧
|
|
18
xiaotuzi OP @iPhoneXI 总觉得别的封装的多余…比如你要写个第三方平台登录，网上别人的都是封装，文件太多而且散，本来一个文件能解决的硬是给他分成几个文件…所以看别人的源码有点煎熬…🌚
|
|
19
xiaotuzi OP @henices 我也这么做过，但是一个大项目并不是你是思考一两天能想明白的，我觉得应该把主支先写出来，然后再扩展，类似父类是主干，子类是分支，其他功能。很多赶的项目，不会有太多的时间给你思考，一步步做反而可以有很多时间给你，因为可以客户看效果…🌚
|
|
20
xiaotuzi OP @Caballarii 是的，这个很考验一个人写代码的能力，兼容性
|
|
24
xiaotuzi OP @www5070504 有经验🌚就不怕项目时间不够吗？
|
|
25
xiaotuzi OP @AndroidEngineer 有需求就有坑，要恰饭就要干活
|
 |
27
Baymaxbowen 2019-08-13 13:17:52 +08:00
@q8164305 #17 因为这是提高自己的过程，难道你一辈子都搬砖吗
|
|
29
xiaotuzi OP @q8164305 对的，我也反驳他们了，明显他们没有做过外包…唉，一下感觉程序员真不平等！！！😖
|
 |
30
ChenStyle 2019-08-13 13:57:57 +08:00
不怕改啊，只要有时间。别整那么快，摆烂就完事儿了。
做需求先想好解决方案，如果接了需求没有解决方案，难点在哪里跟产品讨论下其实可以商量的…… 总之其乐融融就完事儿了，打工而已。 我虽然干了三年，但已经油滑的不行了。 |
 |
31
redford42 2019-08-13 13:59:30 +08:00
我发现最重要的是莫生气...
|
 |
32
lizhenda 2019-08-13 13:59:41 +08:00
千万不要提前优化，对于喜欢重构，隔一周就觉得自己写的代码是垃圾的人来说很重要。
|
|
33
lizhenda 2019-08-13 14:01:10 +08:00 1
每个方法函数或者复制逻辑的地方写详细注释，因为你会发现年纪越大，记忆越差，过了十天半个月你自己回去看自己写的都不知道是啥意思了
|
 |
40
0x11901 2019-08-13 18:11:16 +08:00
我一般也不分析直接上手……但是我写的代码都是严格按照我能理解的设计模式写的，经常会被人说你干嘛写的这么复杂，但是我只要写好了，bug 少，改的快……我也不知道为什么，但是我学设计模式的时候老师说设计模式就是前人踩了无数坑之后告诉我们这么写就对了，雷少。
|
 |
41
way2create 2019-08-13 18:18:49 +08:00
我觉得，公司的业务代码写的时候遵守规范就好了，自己私下的代码哪怕 js 我看不顺眼也会重构。。。我是后端，至于需求乱改之类的生气什么的...我已经麻木了
|
|
43
xiaotuzi OP @way2create 到了任人欺负的中年人了吗？🌚
|
|
44
way2create 2019-08-13 19:30:16 +08:00
@xiaotuzi 20 好几算中年人吗？欺负倒没有的 懒得跟傻逼一般见识而已
|
 |
45
enaxm 2019-08-13 19:32:05 +08:00
写了才两年你说啥。。。
|
 |
46
jameskuk 2019-08-13 20:10:15 +08:00
1、5：运营相关，你只需要知道你自己是拿钱写代码的就行了。项目没上不会扣你钱，项目成功了也不会分你钱，摆正自己心态就可以了。
2、3、4：能力和经验问题，慢慢会好的，如果有良好的学习习惯的话会更快。另一方面，代码最优解往往是解法、阅读性、维护性等互相权衡的结果，没必要一味追求高大上的解法，不要像有些人满嘴算法，却连一个增删改查都写不好。 |
 |
47
c090817 2019-08-14 00:58:35 +08:00
以前很在乎你这些问题，不过现在已经想开了
1、他修改需求我就给他做，反正算我工作量的，我做了你给我钱公平合理 2、处理的时候先想好怎么写要达成什么效果，然后觉得可行再写，想不到解决办法就问问其他人，实在难做跟产品说这个不好做要加时间 34、想好办法是有效的，这个没什么，不过做之前也要想一下时间限制，如果有最快的办法或者现成代码直接用，看看时间是否充足，如果不足就简单粗暴的解决完成任务 5、我给你干活你不用就不算我干了？ |
 |
48
waruqi 2019-08-14 07:24:03 +08:00 via Android
淡定点 如果是公司项目 就无所谓了 如果是个人项目，哪怕躺坑了 也是享受
|
Select Language