“计算机科学中只有两件难事：缓存失效和命名事物。”—PhilKarlton计算机科学中只有两件难事：缓存失效和命名对象命名。这真的不是开玩笑。写代码相对容易，但是看别人的代码就因人而异了。好的工程师写出来的代码可读性很强，比如我之前公司的同事徐某。普通工程师写的代码就像一堆狗屎，比如之前的一些同事。所以我会经常格式化他们的代码。如果不幸的是轮到你继续开发狗屎代码，那就是狗屎上的狗屎。我为你感到难过。当然，有时候时间紧，自己也会写一些狗屁代码，但每次提交，我都有强烈的负罪感。我希望这些代码最多能存活一个月，在被人踩到之前消失。狗屁代码是怎么来的？如果要说怎么写狗屁代码，我很擅长这个。以下是一些常见的生成垃圾代码的方式：代码大段重复的函数参数超过100的未注释幻数函数一堆未注释的if-else嵌套业务过多耦合：支付订单和下单订单可以耦合在一起吗？谁重构谁，苦于代码和文档分离：几年前，业务还不知道是什么东西……可惜，在大多数人的项目中，这些常见的狗屁代码生成方式随处可见。毕竟，成百上千的人写狗屎代码就像成百上千的人在堆砌积木。这堆东西歪歪扭扭，乱七八糟。里面的积木一定不能拔出来，拔出一块可能会倒塌。只能看到自己觉得不靠谱的地方，一直往那里填块。只要不翻倒就没事。这也是大多数程序员的追求。要想解决代码耦合度高的狗屁问题，就需要有更好的顶层解耦设计，明确各个服务的边界。如果你一直只是一个代码搬运工，一个传奇的cv工程师，那么此时你还有一些内功需要修炼。但是良好的命名规范确实是每个人都可以做到的。不同的语言有自己的规范。如果大家能够正确理解那些规范并严格遵守，同时强制使用ci检查，就能保证代码的美观。这里以Go语言的命名规范为例，谈谈如何写出大家想闻的代码。gofmt可以统一不同人的编码标准，但是没办法格式化好名字。然而，在Go社区中一直存在一些成文或不成文的命名规则。例如，一个名字在包外是否可见取决于它的第一个字符是否是大写字母。使用驼峰式大小写而不是下划线。个别方法接口的名称应该是InterfaceName=MethodName+erGetter方法的命名不需要包含Get，比如cat.Owner()方法不需要命名为cat.GetOwner()首字母缩写应该保持原来的格式：userID应该使用而不是userId，你应该使用userAPI而不是userApi变量名称需要尽可能简单但具有描述性......总之，有规则。只是很多程序员选择直接无视而已。比如前五个。还有一些规则被过度滥用。比如第6条，很多同事使用老式的命名方式，在一个struct中使用大量的单字符变量或者任意缩写。这样的代码是完全无法阅读的。所谓有抱负的程序员，还是要追求代码的味道。悲观地说，即使你这样做了，也只是你的代码优雅，但你怎么保证每个人都有这个追求呢？作为个人，除了提建议，其实没有多少有效的办法。我们怎样才能治愈那堆狗屎上的狗屎？要根治这个问题，光靠一个程序员一直保持优雅的代码是没有用的。你写了10句优雅的代码，其他10个同事每人写10句狗屎代码。这样一来，优雅代码的比例最多只有十分之一。一个团队要想彻底解决常年狗屎堆的问题，需要实现以下两个方法：招募高素质的程序员：代码感很重要，每个程序员都需要了解奥卡姆剃刀原理：除非必要，否则不要增加实体。管理需要有一个长期的愿景，而不仅仅是短期目标。深度悲观地说，这两种方法在实际实施时也是非常难实施的，基本不可能完成。不管是在互联网行业还是在互联网行业，高质量都意味着昂贵，但是有多少公司能请得起这么多昂贵的程序员呢？而长期的目标在资本的压力下一文不值。与“明天上线”的顺序相比，代码规范提升10%的重要性也低如尘埃。然后日复一日，明天又是明天，规范最终消失了，狗屎山越来越高。说到底，这些都是钱的问题，也是最无解的问题。终于有一天，屎山崩塌，一切又回到了原点。最后，我斗胆猜测一下，昨天的谷歌服务崩溃也是因为狗屎太多造成的。记得给我点赞哦！对计算机各个方向的视频课程和电子书，从入门、进阶、实用进行了认真梳理，并按照目录进行合理分类。你总能找到你需要的学习资料。你在等什么？立即关注并下载！！！念念不忘，必有回响，朋友们，请点个赞，万分感谢。我是职场亮哥，四年工作经验的YY高级软件工程师，拒绝当领导的斜杠程序员。听我说，我进步很大。如果有幸帮到你，请给我一个【点赞】，给我一个关注，如能评论鼓励，将不胜感激。职场凉阁文章列表：更多文章我的所有文章和回答均与版权保护平台合作，版权归职场凉阁所有。未经授权转载必究！
