坚持住啊，还在代码屎山中爬行的同事们

"There are only two hard things in Computer Science: cache invalidation and naming things."

— Phil Karlton

在计算机领域只有两件艰难的事情：缓存失效和对象命名。

这还真不是一个笑话。写代码是比较容易的事情，但是阅读别人的代码，那就因人而异了。

好的工程师写出来的代码可读性很高，比如我上家公司的同事旭总。一般的工程师写出来的代码就像是一坨屎，比如之前某某几位同事。

所以我会经常去格式化他们的代码。如果不幸轮到你继续在屎代码上面开发，那就是屎上堆屎了。心疼你。

当然有时候工期紧张，我自己也会写一些屎代码shit code，但是每次提交的时候都有一种强烈的愧疚感。希望这些代码最多存活一个月就消失，不要被人踩到了。

屎代码是怎么产生的？

要说怎么写屎代码，这个我就很拿手了。下面随便列举一些常见的屎代码产生方式：

很不幸，大多数人的项目中，这些常见的屎代码产生方式是随处可见的。

毕竟，几百个人写屎代码，就像几百个人堆积木。堆得歪歪扭扭，摇摇晃晃，乱七八糟，你千万不能抽里面的积木，指不定抽了一块就塌了。只能看见哪里觉得不牢靠不停的往那边填积木。只要不倒就好了。这也是大部分程序员的追求了。

如果想解决代码高耦合这坨屎，需要有比较好的顶层解耦设计，划分清楚各自服务的边界。

如果你一直都只是代码搬运工，传说中的cv工程师，那么到这一步还有一些内功需要你去修炼的。

但是好的命名规范确实每个人都可以做到的。不同的语言都有各自的规范，如果所有人都能正确理解那些规范，并且严格遵守，同时强制使用ci校验，就可以保证代码外表上是美观的。

这里就以Go语言的命名规范为例讲一下怎么写出人人都想闻的香代码。

go fmt可以统一不同人的编码规范，却没有办法格式化出一个好的命名。但是在Go社区中其实一直都存在着一些成文的或者不成文的命名规则，比如：

总之，规则是有的。只是很多程序员选择直接忽视。比如前面的五条。

还有一些规则是被过渡滥用了。比如第6条，很多同事的命名沿用以前的老风格，在一个struct中大量使用单字符的的变量或者随心所欲的缩写。这样的代码是完全没有办法阅读的。所谓有追求的程序员，还是得追求一下代码的品味。

悲观的说，即使做到了这些也只是你一个人的代码是优雅的，但是你怎么能保证所有人都有这样的追求呢？作为个人，除了提建议之外，其实是没有太多有效的办法的。

想根治这个问题，只靠某个程序员一直保持优雅代码是没什么用的。

你写10句优雅的代码，其他10个同事每个人都写10句屎代码。这样算起来，优雅代码的比例最多只有十分之一。

如果一个团队想要彻底解决屎上堆屎这个老大难问题，就需要贯彻执行下面两点方法：

深度悲观的说，这两个方法真正执行起来的时候也是难度重重，基本不可能完成。

高质量无论是不是在互联网行业，都意味着价格昂贵，但又有几家公司能给得雇佣的起这么多昂贵的程序员呢？

而长远的目标在资本的压力之下，也显得一文不值。代码规范提升10%的重要性和“明天上线”这个命令比起来，也是低到尘埃的的。然后日复一日，明天又将是明天，规范性最终消失殆尽，屎山越来越高。

说到底，这些都是钱的问题，也是最无解的问题，最终在某一天，屎山崩溃，一切回到原点。

最后，大胆猜测一下，昨天的Google服务崩溃也是因为屎太多了吧。

念念不忘，必有回响，小伙伴们帮我点个赞吧，非常感谢。

我是职场亮哥，YY高级软件工程师、四年工作经验，拒绝咸鱼争当龙头的斜杠程序员。

听我说，进步多，程序人生一把梭

如果有幸能帮到你，请帮我点个【赞】，给个关注，如果能顺带评论给个鼓励，将不胜感激。

职场亮哥文章列表：更多文章

本人所有文章、回答都与版权保护平台有合作，著作权归职场亮哥所有，未经授权，转载必究！