为什么我看不懂你的代码
“我到底在想什么？！？”
凌晨1:30分，我正盯着不到一个月前我写的一段代码。当时它看起来像是件艺术品，全部是可理解的，优雅、简单、让人叹为观止。这一切都不再了，明 天是我的最后期限，数小时前我发现了一个bug。当时看起来的简单和逻辑再也说不通了。可以肯定的是，如果我写代码，我应该足以聪明到理解代码？
经过了多次这种经历以后，我开始认真思考，为什么我的代码在我编写的时候很清楚、而当我数周或数月后回头看的时候，它们却那么费解。
问题1，过度复杂的逻辑模型
为了理解当你间隔一段时间返回到你的代码、却发现代码难以理解的第一步，就是理解我们如何从心智上建立问题模型。你写的几乎所有代码都是尽量解决现实世界的问题。在你写代码之前，你需要理解你正试图解决的问题。这常常是编程里最难的一步。
为了解决现实世界的问题，我们首先需要形成该问题的心智模型【注1】，以此作为编程意图。接下来你需要形成实现编程意图的方案模型，我们姑且称为语 义模型（semantic model）。从来不要混淆你的编程意图和此意图的方案。我们倾向于主要考虑方案方面的东东，而常常忽略意图的模型。
你接下来的步骤是形成可能最简单的语义模型。这是容易搞错的第二步。如果你不花时间去真正理解你正试图解决的问题，你将在写代码时被绊倒在模型上。另一方面，如果你真正考虑了你正尽量做的事情，你经常得到一个非常简单的模型，这足以让你掌握最初的意图。
如果你想容易地维护简单的代码，就尽可能多些地消除意外的复杂性。我们正试图解决的问题是足够复杂的。如果你不必那么做，就不要把意外的复杂性增加进来。
问题2，笨拙的把思想转化成代码
一旦你尽全力形成了最好的语义模型，那么就到了把它转化为代码的时候了。我们称之为句法模型（syntactic model）。你正试图把你的语义模型的意义转化为计算机能够理解的句法。
如果你有非常不错的语义模型、而在转化为代码时搞砸了，那么在你需要在以后某个阶段回头修改代码时，你将比较痛苦。当你脑子里还有语义模型时，把你 代码映射到语义模型是容易的。回忆起变量“x”实际上代表一条记录被创建的日期、而“y”代码记录被删除的日期，这是不难的。当你3个月后再回来看代码， 你的脑子里将没有这个语义模型了，因此无法理解同样的变量名字。
把语义模型转化为句法的任务就是尽量多地留下线索，让你在今后返回时，能够重建当初的语义模型。
好了，你该怎么做呢？
类结构和命名
如果你在使用面向对象语义，请尽量让你的类结构和命名靠近语义模型。领域驱动设计（Domain Driven Design）【注2】是在这种练习上投入了相当重要性的一种运动。即使你没有相信完全的DDD方法，你也应当非常小心地考虑类结构和命名。每个类都是你 留给自己和其他人的线索，它帮助你在将来返回的时候重建你的心智模型。
变量、参数和方法命名
尽量避免普通的变量和方法命名。不要把方法命名为“Process”，因为“PaySalesCommision”更有意义。不要把变量命名为 “x”，因为它应当是“currentContract”。不要把参数命名为“input”，因为“outstandingInvoices“更好。
单一功能原则（Single responsibility principle，简称SRP）
SRP【注3】是面对对象设计原则的核心之一，关联着好的类和变量命名。它认为，任何类或方法都应该完成一个单一的功能，只能是一个单一的功能。如 果你想为类和方法给出有意义的名字，那么它们需要有一个唯一的较好定义的目的。如果一个单一类从数据库读和写、计算营业税、通知交易客户并生成账单，那么 你就可能无法给出合适的名字。我常常停留在重构类上，因为我总是努力取一个足够短的名字，以描述它做的每个功能。为了更多地讨论SRP和其它面向对象原 则，可以参考我的博文《》。
适当的注释
如果因为某种原因，你不能让代码变得清晰，你同情将来的自己，需要不得不做些事情，那就留下注释来说明你为什么不得不那样做。注释倾向于快速地变得陈旧，因此我宁愿尽可能让代码自描述，注释用来说明为什么你不得不那样做，而不是它如何做。
问题3，没有足够的组块
心理学上的组块被定义是，把信息组块定位为单一的实体。那么这该如何应用到编程上呢？作为一名开发者，在你积累经验时，你开始发现你解决方案里反复 出现的模式。极具影响的设计模式：《可重用的面向对象软件》是第一本整理和解释一些模式的书。尽管如此，组块不仅仅用在设计模式和面向对象。在函数式编程 （FP）里，存在大量的著名标准函数具备这同样的目的。算法是组块的另一种形式（后续会更多）。
当你合理地使用组块（设计模式、算法和标准函数）时，它让你停下来思考，你编写的代码是如何运行的、而不是考虑它做了什么。这缩短了你的语义模型（你的代码）和句法模型（你脑子里的模型）的距离。这个距离越短，你就越容易重建你的心智模型。
如果你有兴趣了解更多FP里的函数，请移步到。
问题4，费解的用法
目前，我们主要讨论了如何结构化你的类、方法和变量命名。心智模型的另一个重要部分是理解这些方法应该怎样被使用。再次强调，当你最初形成心智模型 时，这是相当清晰的。当你后来返回时，就非常难以重建你的类和方法的、所有有意图的用法了。通常这是因为不同的用法散布在你的程序其它地方。有时候甚至出 现在很多不同的项目中。
我就是在这种情况下发现测试用例是非常有用的。除了相应地知道一个修改是否破坏了代码的明显好处，测试为你的代码提供了一整套的用例。你不必搜遍100个文件，只需看测试就能得到引用的全景。
注意为了达到这个目的，你需要有一整套完整的测试用例。如果你的测试仅仅覆盖了一部分、而你认为测试是完整的，那么你后来将陷入困境。
问题5，不同的模型之间没有清晰的途径
你的代码从技术角度看，常常是优秀的、非常优雅，但是从程序意图到语义模型、再到代码存在非常不自然的跳跃。考虑你选择的一堆模型的透明性是重要 的。从程序意图到语义模型、再到代码的过程需要尽可能平滑。你应当能够看透对应到问题的每个模型的所有方面。多数情况下，最好选择特定类结构或算法不是为 了它在隔离方面的优雅，而是可以连接各种模型，为你重建的目的而留下 一条自然的途径。当你从抽象的编程意图走到具体的代码时，你做的选择应该受到 你能够表现更为抽象模型 的清晰度驱使。
问题6，发明算法
作为程序员，我们经常认为，我们在为了解决问题而发明着算法。事实很难是这样的。几乎所有情况下，已经有现成的算法可以被组合在一起解决你的问题 了。像最短路径搜索法、字符串相似度算法、粒子群算法等。大部分编程是以正确的组合、选择现存算法来解决你的问题。如果你正在发明新算法，那么，要么你不 知道合适的算法、要么你正忙于你的博士论文。
最后总结：作为一名程序员，你的目标是建立能够解决你问题的、尽可能简单的语义模型。把语义模型尽可能靠近地转化为句法模型（代码），尽可能多地提供线索，便于你之后无论哪个人看你的代码，都能重建像你最初脑子里的、相同的语义模型。
设想一下，当你走过你代码的被照亮的森林时，你在身后留了面包屑。相信我，当你需要找到回去的路时，森林将充满了黑暗、朦胧和不详的预感。
听起来容易，实际做起来是很难的。
原文地址：
注1：心智模型是用于解释个体为现实世界中之某事所运作的内在认知历程。
注2：要通过创建领域模型来加速复杂的软件开发，就需要利用大量最佳实践和标准模式在开发团队中形成统一的交流语言；不仅重构代码，而且要重构代码底层的模型；同时采取反复迭代的敏捷开发方法，深入理解领域特点，促进领域专家与程序员的良好沟通。
注3：马丁把功能（职责）定义为：“改变的原因”，并且总结出一个类或者模块应该有且只有一个改变的原因。一个具体的例子就是，想象有一个用于编 辑和打印报表的模块。这样的一个模块存在两个改变的原因。第一，报表的内容可以改变（编辑）。第二，报表的格式可以改变（打印）。这两方面会的改变因为完 全不同的起因而发生：一个是本质的修改，一个是表面的修改。单一功能原则认为这两方面的问题事实上是两个分离的功能，因此他们应该分离在不同的类或者模块 里。把有不同的改变原因的事物耦合在一起的设计是糟糕的。
原文出处：
转载请注明：文章转载自 开源中国社区
本文标题：为什么我看不懂你的代码
本文地址：
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 引用来自“BarneyWang”的评论如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼引用来自“so伍”的评论行了，别秀下限了，你能代表谁？你资料写的是IBM，就是说你不知道其他公司如何运作，你还装作专家呢？你知道我们实际情况什么样？你知道我们公司项目如何管理？嗯？说说看，这位大神，说不出就指手画脚？是谁教你的？你们公司的哪位？我去拜访一下 引用来自“BarneyWang”的评论对不起 我们这边的项目经理都不是你这种半吊子没人要求傻逼一样的注释硬性要求并且引以为傲的也就是干啥啥不行 吃啥啥没够的 在一个小地方欺负几个刚毕业的大学生的人会有这种要求引用来自“so伍”的评论好的，你来给个解决办法，新人入公司，你们IBM没有制度吗？没有代码约束？知道注释代表什么吗？后期维护的成本会降低，新人也会养成良好的编码习惯，这都是边缘收益，当然，你不会考虑组织利益，看得出来你很自我；不过不要想当然，你遇到过的项目太少，乱说话可以原谅。引用来自“BarneyWang”的评论你乱BB了一大篇 又来跟我扯项目太少对不起 我们公司没有4分之一注释的傻逼规则自己发明个傻逼规则 还BB个没完美其名曰 考虑组织利益自己傻逼了还要连累公司傻逼 可以看得出你很傻逼 而且死不认错引用来自“so伍”的评论你们公司人都不写注释吗？底层代码注释少于25%？你看过底层代码吧？引用来自“BarneyWang”的评论别BB了成吗？写注释和傻逼的硬性要求注释25%是两个概念你赶紧回炉重造吧还死不认错哦？那你带过新人吗？新人不写注释，不做程序说明的时候，你有什么办法？大神来教教。
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 引用来自“BarneyWang”的评论如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼引用来自“so伍”的评论行了，别秀下限了，你能代表谁？你资料写的是IBM，就是说你不知道其他公司如何运作，你还装作专家呢？你知道我们实际情况什么样？你知道我们公司项目如何管理？嗯？说说看，这位大神，说不出就指手画脚？是谁教你的？你们公司的哪位？我去拜访一下 引用来自“BarneyWang”的评论对不起 我们这边的项目经理都不是你这种半吊子没人要求傻逼一样的注释硬性要求并且引以为傲的也就是干啥啥不行 吃啥啥没够的 在一个小地方欺负几个刚毕业的大学生的人会有这种要求引用来自“so伍”的评论好的，你来给个解决办法，新人入公司，你们IBM没有制度吗？没有代码约束？知道注释代表什么吗？后期维护的成本会降低，新人也会养成良好的编码习惯，这都是边缘收益，当然，你不会考虑组织利益，看得出来你很自我；不过不要想当然，你遇到过的项目太少，乱说话可以原谅。引用来自“BarneyWang”的评论你乱BB了一大篇 又来跟我扯项目太少对不起 我们公司没有4分之一注释的傻逼规则自己发明个傻逼规则 还BB个没完美其名曰 考虑组织利益自己傻逼了还要连累公司傻逼 可以看得出你很傻逼 而且死不认错引用来自“so伍”的评论你们公司人都不写注释吗？底层代码注释少于25%？你看过底层代码吧？别BB了成吗？写注释和傻逼的硬性要求注释25%是两个概念你赶紧回炉重造吧还死不认错
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 引用来自“BarneyWang”的评论如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼引用来自“so伍”的评论行了，别秀下限了，你能代表谁？你资料写的是IBM，就是说你不知道其他公司如何运作，你还装作专家呢？你知道我们实际情况什么样？你知道我们公司项目如何管理？嗯？说说看，这位大神，说不出就指手画脚？是谁教你的？你们公司的哪位？我去拜访一下 引用来自“BarneyWang”的评论对不起 我们这边的项目经理都不是你这种半吊子没人要求傻逼一样的注释硬性要求并且引以为傲的也就是干啥啥不行 吃啥啥没够的 在一个小地方欺负几个刚毕业的大学生的人会有这种要求引用来自“so伍”的评论好的，你来给个解决办法，新人入公司，你们IBM没有制度吗？没有代码约束？知道注释代表什么吗？后期维护的成本会降低，新人也会养成良好的编码习惯，这都是边缘收益，当然，你不会考虑组织利益，看得出来你很自我；不过不要想当然，你遇到过的项目太少，乱说话可以原谅。引用来自“BarneyWang”的评论你乱BB了一大篇 又来跟我扯项目太少对不起 我们公司没有4分之一注释的傻逼规则自己发明个傻逼规则 还BB个没完美其名曰 考虑组织利益自己傻逼了还要连累公司傻逼 可以看得出你很傻逼 而且死不认错你们公司人都不写注释吗？底层代码注释少于25%？你看过底层代码吧？
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 引用来自“BarneyWang”的评论如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼引用来自“so伍”的评论行了，别秀下限了，你能代表谁？你资料写的是IBM，就是说你不知道其他公司如何运作，你还装作专家呢？你知道我们实际情况什么样？你知道我们公司项目如何管理？嗯？说说看，这位大神，说不出就指手画脚？是谁教你的？你们公司的哪位？我去拜访一下 引用来自“BarneyWang”的评论对不起 我们这边的项目经理都不是你这种半吊子没人要求傻逼一样的注释硬性要求并且引以为傲的也就是干啥啥不行 吃啥啥没够的 在一个小地方欺负几个刚毕业的大学生的人会有这种要求引用来自“so伍”的评论好的，你来给个解决办法，新人入公司，你们IBM没有制度吗？没有代码约束？知道注释代表什么吗？后期维护的成本会降低，新人也会养成良好的编码习惯，这都是边缘收益，当然，你不会考虑组织利益，看得出来你很自我；不过不要想当然，你遇到过的项目太少，乱说话可以原谅。你乱BB了一大篇 又来跟我扯项目太少对不起 我们公司没有4分之一注释的傻逼规则自己发明个傻逼规则 还BB个没完美其名曰 考虑组织利益自己傻逼了还要连累公司傻逼 可以看得出你很傻逼 而且死不认错
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 引用来自“BarneyWang”的评论如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼引用来自“so伍”的评论行了，别秀下限了，你能代表谁？你资料写的是IBM，就是说你不知道其他公司如何运作，你还装作专家呢？你知道我们实际情况什么样？你知道我们公司项目如何管理？嗯？说说看，这位大神，说不出就指手画脚？是谁教你的？你们公司的哪位？我去拜访一下 引用来自“BarneyWang”的评论对不起 我们这边的项目经理都不是你这种半吊子没人要求傻逼一样的注释硬性要求并且引以为傲的也就是干啥啥不行 吃啥啥没够的 在一个小地方欺负几个刚毕业的大学生的人会有这种要求好的，你来给个解决办法，新人入公司，你们IBM没有制度吗？没有代码约束？知道注释代表什么吗？后期维护的成本会降低，新人也会养成良好的编码习惯，这都是边缘收益，当然，你不会考虑组织利益，看得出来你很自我；不过不要想当然，你遇到过的项目太少，乱说话可以原谅。
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 引用来自“BarneyWang”的评论如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼引用来自“so伍”的评论行了，别秀下限了，你能代表谁？你资料写的是IBM，就是说你不知道其他公司如何运作，你还装作专家呢？你知道我们实际情况什么样？你知道我们公司项目如何管理？嗯？说说看，这位大神，说不出就指手画脚？是谁教你的？你们公司的哪位？我去拜访一下 对不起 我们这边的项目经理都不是你这种半吊子没人要求傻逼一样的注释硬性要求并且引以为傲的也就是干啥啥不行 吃啥啥没够的 在一个小地方欺负几个刚毕业的大学生的人会有这种要求
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 引用来自“BarneyWang”的评论如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼行了，别秀下限了，你能代表谁？你资料写的是IBM，就是说你不知道其他公司如何运作，你还装作专家呢？你知道我们实际情况什么样？你知道我们公司项目如何管理？嗯？说说看，这位大神，说不出就指手画脚？是谁教你的？你们公司的哪位？我去拜访一下
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼引用来自“so伍”的评论嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。 如果我不骂你 你就会害更多的人我今天就是要替那些被你这种傻逼欺负的程序员讨回公道比起我的骂人 你这种带有侮辱性质的检查代码更会对人造成心里创伤所以 傻逼你还是收起你那傻逼的面孔好好学习技术吧不要在装自己是一个懂技术的PM了因为PM说自己懂技术都是傻逼
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。引用来自“BarneyWang”的评论呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼嗯，行了，闭嘴吧。你看看你给别人的回复，果然是你人生的缩影。除了脏话就是侮辱性的言辞，很难想象你家人和老师都是怎么教导的。够了，没教养的废物。
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧引用来自“so伍”的评论文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。呵呵 转PM就代表你只不过是一个不学无术的二笔，技术混不下去了也就能骗骗刚毕业的小孩吧，还有 你算个毛师父，典型的眼高手低大爷心态，看你到写的代码四分之一为注释我就断定你是个傻逼半吊子程序员，开发就怕你这种2B，好好提高自己的技术吧臭傻逼
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 引用来自“BarneyWang”的评论你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧文明上网，理性发言，首先，我曾是技术人员出身，资历经验比大部分项目组组员丰富的多，没资格吗？你的师父转为项目管理人员之后还没资格检查你代码了？这本身逻辑就不对，请理清逻辑再占用OSC的硬盘。
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论也是无奈之举，现在毕业生直接进项目组，让他们自己学会判断的话，时间成本是很恐怖的，而且无法确定他们会不会真的去领悟，大部分三年之内的员工只知道多写几行代码，不知道做些有边缘效益的事情 你是个JB 还PM 有JB毛资本看程序员的代码 也就看看注释吧
引用来自“Greatim”的评论这肯定是个讨骂的要求吧。一个是，四分之一，这标准没办法衡量，各人估算不同。另外要求有注释，注释对不对是个问题，过时的注释，或者无用的注释不如没有。变量名和函数名其实很好检查，还有常数名。可以提出规范，常数必须声明在哪里，方便检查。这样比要求多少注释好多了，在别人眼里，你随便一个要求，别人去做，跟你跟他们一起去完成协定，两种感觉是不同的。我觉得定期地挑一些代码出来，小组详细地review一遍，评价代码的优缺点，合理和不合理之处，说出自己的想法，这样典型性地分析一遍，比这种所谓硬性规定要好很多
引用来自“Greatim”的评论这肯定是个讨骂的要求吧。一个是，四分之一，这标准没办法衡量，各人估算不同。另外要求有注释，注释对不对是个问题，过时的注释，或者无用的注释不如没有。变量名和函数名其实很好检查，还有常数名。可以提出规范，常数必须声明在哪里，方便检查。这样比要求多少注释好多了，在别人眼里，你随便一个要求，别人去做，跟你跟他们一起去完成协定，两种感觉是不同的。同意
引用来自“欣儿”的评论一个月后都不知道自己写的神马？ 引用来自“淡定的wo”的评论一点问题都没有。通过方法、变量名分析上下文，直接可以知道了。至少我是这样。最长半年的线上业务没动，需要改动时，也不会有问题。引用来自“古城痴人”的评论拿我现在遇到的问题来说，写代码的人早已经离职了，很多地方根本不知道为什么要这么写代码，每次看到一个方法，都要逆向从代码反推，如果有注释来提示的话，想必效率会提高很多。阅读代码不是一件轻松的事情，阅读别人的代码更加困难，对于新员工阅读别人的代码那简直可以用痛苦来形容。当然这跟我遇到的情况有关：没有什么文档。但是工作这么多年，真没见有哪家公司的业务文档描述的特别详细。接手别人的代码确实头疼，注释？别想。代码自解释？更加不可能。只能说从自己开始为逐步梳理一点代码脉络出来。工作多年，没见过真正意义上的文档。仅仅见过“笔记”类的东西。对老板来说，花钱花时间做这个，他们觉得没有直接获得利益，就不想做。口头禅是：“业务要大变动，等以后稳定了再说！”。哎！！！
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论这个其实也要分产品属于什么行业领域，我所在的是银行金融，业务逻辑全部都由子程序实现，底层代码只实现框架支撑，子程序的业务逻辑描述至关重要 引用来自“古城痴人”的评论理解，没掉过坑怎么能理解到这些呢？引用来自“淡定的wo”的评论代码中业务逻辑也仅仅需要关键的注释，而不是到处都是注释。更加复杂的逻辑解释，应该使用单独的文档归纳。不建议放到代码中。赞同
引用来自“欣儿”的评论一个月后都不知道自己写的神马？ 引用来自“淡定的wo”的评论一点问题都没有。通过方法、变量名分析上下文，直接可以知道了。至少我是这样。最长半年的线上业务没动，需要改动时，也不会有问题。拿我现在遇到的问题来说，写代码的人早已经离职了，很多地方根本不知道为什么要这么写代码，每次看到一个方法，都要逆向从代码反推，如果有注释来提示的话，想必效率会提高很多。阅读代码不是一件轻松的事情，阅读别人的代码更加困难，对于新员工阅读别人的代码那简直可以用痛苦来形容。当然这跟我遇到的情况有关：没有什么文档。但是工作这么多年，真没见有哪家公司的业务文档描述的特别详细。
引用来自“BaiYang”的评论同意，注释确实很重要。我写的代码注释率基本在 35% - 45% 之间，底层平台高些（45% 左右）。上层产品低些（35% - 40%）。但是注释率不能直接成为硬性标准：乱写的或无脑的注释还不如没有注释。我们的注释率如此高的原因是详细设计文档都以注释的形式存在。引用来自“so伍”的评论这个其实也要分产品属于什么行业领域，我所在的是银行金融，业务逻辑全部都由子程序实现，底层代码只实现框架支撑，子程序的业务逻辑描述至关重要 引用来自“古城痴人”的评论理解，没掉过坑怎么能理解到这些呢？代码中业务逻辑也仅仅需要关键的注释，而不是到处都是注释。更加复杂的逻辑解释，应该使用单独的文档归纳。不建议放到代码中。}