这是一个创建于 1650 天前的主题，其中的信息可能已经有所发展或是发生改变。
代码, 是把人的思维传递给计算机的工具, 所有的编程语言, 在设计时, 从没认真考虑过如何把一个人的思维传递给另一个人或者 2 个月后的编写者本人。
我们程序员不得不用一个工具, 强行去解决该工具设计时从没考虑到的问题, 这就是痛苦的根源。
编程是管理复杂度的工作, 复杂度分为问题本身需要的和工具本身带来的, 95%的编程工作, 后者的复杂度远远超过甚至碾压前者。
 |
1
zcbenz 2020-05-10 16:20:21 +08:00  6
我觉得更痛苦的是，别人乱改自己的代码
|
 |
2
ruby0906 2020-05-10 16:44:00 +08:00 3
所以，文档就显得越发重要。 但并没有引起人们的足够重视。
|
 |
3
xiaket 2020-05-10 16:46:33 +08:00
所以选一个好懂的编程语言很重要.
|
 |
4
viator42 2020-05-10 16:51:22 +08:00 32
看到烂代码就骂哪个傻叉写的，最后一查是自己写的
|
 |
5
jdgui 2020-05-10 16:52:36 +08:00
安卓程序员的优越性，基本上代码都是我一个人写的。
然后 3 月那段时间 996 写出来的代码，我现在都不忍直视，骂又没地方可以骂。哈哈 |
 |
6
hoyixi 2020-05-10 16:54:25 +08:00
所以要有文档和流程方法论，不过我们不需要，因为勤劳吃苦奋斗的中国人可以加班
|
 |
7
xuanwu 2020-05-10 16:55:17 +08:00
|
 |
8
loading 2020-05-10 16:58:35 +08:00 via Android 3
写代码更大的痛苦, 在于理解自己以前的代码。
|
 |
9
MajestySolor 2020-05-10 17:09:51 +08:00
不说让别人理解了，光自己看都够呛
最好的方法就是自己每隔半年就重构一次 🐶 |
 |
10
whisky221 2020-05-10 17:18:49 +08:00
确实，读代码很累，但是理解了会有提升。
自己写很爽，但是提升细微（打字速度） |
 |
11
turi 2020-05-10 17:19:17 +08:00
我写代码喜欢 短小、紧凑的片段组合。
我同事，你为什么不写一个函数里面，也就一个功能，也不可能复用的，然后最后一句：几千行还好吧。 |
 |
12
hyy1995 2020-05-10 17:23:33 +08:00
如果业务复杂的话，自己的代码过了一段时间都看不懂了
|
 |
13
Nich0la5 2020-05-10 18:25:05 +08:00 via Android
写注释啊老铁们
|
 |
14
zhuawadao 2020-05-10 18:51:42 +08:00 1
程序员看代码--自己刚刚写的代码，啧啧啧，真是精妙；
别人的代码--这是什么垃圾代码； 看三个月之前自己写的代码--这是我写的吗，肯定谁改了，要不不可能这么垃圾。 |
 |
15
Xbluer 2020-05-10 19:00:35 +08:00
痛苦的根源就是楼主的第一句话。
如果大家把代码当作给另一个程序员传递思想的工具，那么就不会有这个烦扰了。 有句话：代码是给人看的，顺便能在计算机上运行而已。 |
 |
16
kaiki 2020-05-10 19:02:32 +08:00 2
写代码不加注释的都是耍流氓。
我自己写的代码不加注释第二天我都看不懂，所以我能注释都注释。 |
 |
17
jay0726 2020-05-10 19:23:34 +08:00
刚看的微博热搜，北京同仁医院眼科主任魏文斌：质检合格的电子产品都已过滤有害的短波蓝光。日常生活中，使用正规厂家生产的电子产品，没必要加装防蓝光的设备。
|
|
18
jay0726 2020-05-10 19:24:04 +08:00
抱歉发错了
|
 |
19
weizhiyao008 2020-05-10 19:31:54 +08:00
更痛苦的是别人乱改自己的代码后出了 BUG 还要自己查
|
 |
20
justin2018 2020-05-10 19:33:13 +08:00 2
修改别人的代码 ： 谁写的代码 太稀烂了
别人修改自己的代码：谁写的代码 太稀烂了 😅 |
 |
21
JerryCha 2020-05-10 20:08:59 +08:00
说得好
让我再写一千行三目运算套三目运算套++a++再说 |
 |
22
charlieputon 2020-05-10 20:14:17 +08:00 via Android
@jdgui 在一个几十个安卓开发的团队待过，你肯定想象不到那种感觉。。
|
 |
24
fortunezhang 2020-05-10 20:57:37 +08:00
以前觉得自己写的还 ok，自从接了一个维护项目以后，就开始写备注了。jetbrains 软件生成的 params 还是挺好看的。
|
 |
25
maomaomao001 2020-05-10 21:20:44 +08:00
@ruby0906 我实际体验过程中发现的一个问题，文档确实挺好， 但是在项目实际快速迭代过程中 ， 文档 和最版本代码一致性比较难以做到，你有没有方法优化这一类问题 ？
|
 |
26
kop1989 2020-05-10 21:29:30 +08:00
@maomaomao001 api 可以实现自动生成文档，但是逻辑和业务的备忘就无能为力了，要么自觉直接写注释，要么纪律上要求。比如 check in 的时候备注必须描述自己新增、修改的逻辑，或者必须附带文档一起 check in 。
也希望大佬共通赐教。 |
 |
27
dioxide 2020-05-10 22:12:07 +08:00
所以才有了代码规范、范式、“军规”..
|
 |
28
blless 2020-05-10 22:13:28 +08:00 via Android
go 程序员扬眉吐气
|
 |
29
liliumss 2020-05-10 22:26:52 +08:00
所以代码 review 非常重要，如果每个程序员写的代码都遵循 《 clean code 》，那代码读起来就不会那么费劲了
|
 |
30
feelcodex 2020-05-11 01:21:43 +08:00 via iPhone
最惨的是：别人写的代码出了 BUG，然后让你去修。。。
|
 |
31
dayeye2006199 2020-05-11 02:22:48 +08:00 1
我觉得更痛苦的，是三个月之后看自己的代码。。这 TM 什么玩意儿。。
|
 |
32
ijrou 2020-05-11 02:48:16 +08:00
我觉得最痛苦的莫过于别人挖坑挖到自己的家里来了。。。。。
|
 |
33
icylogic 2020-05-11 03:11:32 +08:00 1
30 楼了居然都没有提到测试二字，保证一定覆盖率的有意义的测试才是理解代码，快速接手 legacy code （包括自己写的）的最佳方式。
从时效性看，文档（包括自动生成的）很难保持和代码的同步，注释稍微好一点，但也极度依赖于每个人自觉，只有能通过的测试才是永不过时的。所以文档适合描述比较稳定的公开接口。测试有和代码同步的时效性，而且粒度可以远比文档细，又不像注释那样难以规范和保证覆盖。 注释，代码风格 /规范，命名，review，linter，这些都是有效的辅助手段，但是我认为对于 maintainability 来说，最重要的就是测试。 有本书叫 working effectively with legacy code 可以看看。 |
 |
34
PlanZ 2020-05-11 05:10:15 +08:00
持续优化自己的代码，就不会忘了，还能发掘潜能。
|
 |
35
kinghly 2020-05-11 08:23:15 +08:00 via Android
代码可以阅读性很重要
|
 |
36
qloog 2020-05-11 09:04:24 +08:00
所以 代码风格 /规范，命名，review，linter 对于一个团队很重要，再加上单元测试就基本可以保证功能的稳定性。
|
 |
37
fancy111 2020-05-11 09:07:25 +08:00
你搞错了吧，任何人写的代码包括你自己，过段时间去看也是难看懂的。
但是只要你精通这门语言，花点时间就看懂了，这并不是什么障碍。 如果你还觉得困难，那是你技术水平还不够。 |
 |
38
ultimate 2020-05-11 09:14:46 +08:00
写代码最大的痛苦之一，命名
|
 |
40
22yune 2020-05-11 09:26:21 +08:00
@zcbenz 我觉得更痛苦的是，别人乱改自己的设计。为抢功改一些他以为‘’没关系’的点，然后他还是领导，要你按他的设计实现。
|
 |
41
Techzero 2020-05-11 09:35:26 +08:00 via Android
命名不规范+没注释。。
|
 |
42
jinliming2 2020-05-11 09:38:18 +08:00 via iPhone
所以，你为什么不写注释 doc ？
|
 |
43
aaronhua 2020-05-11 09:42:10 +08:00
注释+文档很重要，毕竟你看的代码很多都是自己以前的代码
|
 |
44
sagaxu 2020-05-11 09:46:27 +08:00 via Android
最近半年我在把几万行反编译出来的代码移植到别的平台，因为是专业软件，功能都不懂，要从反编译代码倒推出功能，再正向重写出来。翻译了几千行之后，我已经很习惯读到处 goto 的代码了。
|
 |
45
a1562619919 2020-05-11 09:54:39 +08:00 via Android
写代码要看别人代码是指项目交接的情况吗？
如果原作者不是大佬，我一般在搞定难点重点后全部重写一遍。可能效率偏低但是开发心情好多了 |
 |
46
Tonni 2020-05-11 09:59:23 +08:00
注释 + 文档，详细记录内部逻辑细节，这样以后维护起来会方便很多。
|
 |
47
sdushn 2020-05-11 10:20:49 +08:00
前几天重构自己刚入行时写的代码，恶心了好几天
|
 |
48
no1xsyzy 2020-05-11 10:50:34 +08:00
@xuanwu #7 命名并不能解决问题，英文母语使用者拿英文也不能缓解的问题，指望中文母语使用者用中文有任何程度的缓解都是妄想。
|
 |
49
paoqi2048 2020-05-11 10:59:40 +08:00
“好的代码不需要注释”，这句话不全对，注释和文档还是不能偷懒不写
|
|
50
maomaomao001 2020-05-11 11:10:54 +08:00
@kop1989 额,api 文档是前后端沟通性文档 这个太容易同步, 因为只要不同步,前端接的时候出问题会找相关人员同步 ,
我主要面临的是,单纯的 前端程序的文档 , 或者后端系统本身的文档 , 怎么和自身的代码同步好呢 , 我暂时也没有找到好的办法 |
 |
51
MaxTan 2020-05-11 11:17:50 +08:00
其实读别人的代码挺有意思的啊
好的代码： "卧槽，流批啊。 还可以这样" 烂的代码： "哈哈，这傻屌" |
 |
52
lzihua 2020-05-11 11:27:43 +08:00
从业者平均水平高低问题。一个尖子班 老师讲题 很多就直接跳过了 略过了
|
 |
53
zshneedmoney 2020-05-11 11:36:52 +08:00
我感觉业务更苦难一些。代码难道比业务还复杂吗
|
 |
54
liveoppo 2020-05-11 12:00:18 +08:00
在写代码的时候，清晰易懂应该是重要考虑项，而不仅仅是各种精妙
|
 |
55
cabing 2020-05-11 13:09:39 +08:00
这个问题，ruby 之父考虑过，所以有了 ruby
|
 |
57
peachpeach 2020-05-11 13:43:40 +08:00
是的，尤其是 shit 一样的代码，可读性非常的烂。
每次解 bug 读到这样的代码，都让人觉得很烦躁。 尤其是代码风格很烂的，写的时候完全不在意后面是不是有人会读。 C 语言。 |
 |
58
fkdog 2020-05-11 13:53:57 +08:00
听过一个词吗？
文人相轻。 写代码同理，你认为别人写的烂，别人一样认为你写的烂。 |
 |
59
jones2000 2020-05-11 14:45:40 +08:00
读代码也是程序员的一个基本技能， 任何一个已经上线运行 1-2 年的程序的代码都有它存在的意义，就算你重写也需要看懂老代码， 重点就是看他踩过的坑，解决这些坑的代码可能就是代码里面最烂的一部分。
|
 |
60
yuxing1171 2020-05-11 15:26:16 +08:00
来，互相伤害。
|
 |
61
siteshen 2020-05-11 15:27:48 +08:00
理解别人的代码确实很困难，因为这不止取决于看代码的人，还取决于写代码的人。
但要做到以后能理解自己的代码还是能做到的： 1. 尽量用最高的标准要求自己的代码； 2. 不那么明显的工具函数会有简单的测试； 3. 不得不 HACK 的代码会用注释写明原因。 不夸张的说，我现在还能较容易地看懂我三年前写的代码。 |
 |
62
la2la 2020-05-11 16:25:11 +08:00
同感，接手一个业务比较复杂的 python 代码，也没啥高级的语法，但是上来给来了 6 个全局变量，真的吐了。还是多线程的程序，根本不知道什么时候填充，什么时候修改，只能一行行 DEBUG，多线程环境下面 DEBUG 简直吐了
|
 |
63
Orenoid 2020-05-11 16:32:07 +08:00
有时候适当读点别人的代码，有助于意识到自己的代码烂在哪。。
|
 |
64
NoKey 2020-05-11 16:46:28 +08:00
是不是你们提交 git 的时候，都不好好写 commit 的？
|
Select Language