写代码最大的痛苦, 在于理解别人的代码

[ybw]

代码, 是把人的思维传递给计算机的工具, 所有的编程语言, 在设计时, 从没认真考虑过如何把一个人的思维传递给另一个人或者 2 个月后的编写者本人。

我们程序员不得不用一个工具, 强行去解决该工具设计时从没考虑到的问题, 这就是痛苦的根源。

编程是管理复杂度的工作, 复杂度分为问题本身需要的和工具本身带来的, 95%的编程工作, 后者的复杂度远远超过甚至碾压前者。

[JerryCha]

说得好
让我再写一千行三目运算套三目运算套++a++再说

[charlieputon]

@jdgui 在一个几十个安卓开发的团队待过，你肯定想象不到那种感觉。。

[dwzfuck]

@xuanwu 刚准备 @ /狗头

[fortunezhang]

以前觉得自己写的还 ok，自从接了一个维护项目以后，就开始写备注了。jetbrains 软件生成的 params 还是挺好看的。

[maomaomao001]

@ruby0906 我实际体验过程中发现的一个问题，文档确实挺好， 但是在项目实际快速迭代过程中 ， 文档 和最版本代码一致性比较难以做到，你有没有方法优化这一类问题 ？

[kop1989]

@maomaomao001 api 可以实现自动生成文档，但是逻辑和业务的备忘就无能为力了，要么自觉直接写注释，要么纪律上要求。比如 check in 的时候备注必须描述自己新增、修改的逻辑，或者必须附带文档一起 check in 。

也希望大佬共通赐教。

[dioxide]

所以才有了代码规范、范式、“军规”..

[blless]

go 程序员扬眉吐气

[liliumss]

所以代码 review 非常重要，如果每个程序员写的代码都遵循 《 clean code 》，那代码读起来就不会那么费劲了

[feelcodex]

最惨的是：别人写的代码出了 BUG，然后让你去修。。。

[dayeye2006199]

我觉得更痛苦的，是三个月之后看自己的代码。。这 TM 什么玩意儿。。

[ijrou]

我觉得最痛苦的莫过于别人挖坑挖到自己的家里来了。。。。。

[icylogic]

30 楼了居然都没有提到测试二字，保证一定覆盖率的有意义的测试才是理解代码，快速接手 legacy code （包括自己写的）的最佳方式。

从时效性看，文档（包括自动生成的）很难保持和代码的同步，注释稍微好一点，但也极度依赖于每个人自觉，只有能通过的测试才是永不过时的。所以文档适合描述比较稳定的公开接口。测试有和代码同步的时效性，而且粒度可以远比文档细，又不像注释那样难以规范和保证覆盖。

注释，代码风格 /规范，命名，review，linter，这些都是有效的辅助手段，但是我认为对于 maintainability 来说，最重要的就是测试。

有本书叫 working effectively with legacy code 可以看看。

[PlanZ]

持续优化自己的代码，就不会忘了，还能发掘潜能。

[kinghly]

代码可以阅读性很重要

[qloog]

所以 代码风格 /规范，命名，review，linter 对于一个团队很重要，再加上单元测试就基本可以保证功能的稳定性。

[fancy111]

你搞错了吧，任何人写的代码包括你自己，过段时间去看也是难看懂的。
但是只要你精通这门语言，花点时间就看懂了，这并不是什么障碍。
如果你还觉得困难，那是你技术水平还不够。

[ultimate]

写代码最大的痛苦之一，命名

[michaelso]

@Xbluer 不能同意更多了

[22yune]

@zcbenz 我觉得更痛苦的是，别人乱改自己的设计。为抢功改一些他以为‘’没关系’的点，然后他还是领导，要你按他的设计实现。