没有对比就没有伤害，优秀的代码VS糟糕的代码

可持续开发不仅在于项目架构设计，还与代码质量密切相关，代码的整洁度和质量成正比。—— Robert C. Martin, “Clean Code”

如果你还没有发现代码质量的区别，如果你从未见过优秀的代码，或者从未见过糟糕的代码，那么本文将以直观地对比，告诉你代码质量究竟会有多大的区别。

[ 代码量 ]

我们知道代码量显示着功能的复杂程度，例如Windows XP的代码量超过2000万行，Linux内核有1500万行(2012年)。然而代码量和功能数量之间并非线性关系。

优秀的设计中，代码量和功能数的关系是这样的：

糟糕的设计中，代码量和功能数的关系是这样的：

优秀的系统往往会有优秀的结构设计：层次清晰、职责单一、模块化，方便扩展或者复用。功能的添加往往只是在现有框架中添加少量代码。

然而糟糕的设计中，层次混乱、互相耦合、难以阅读，既难以复用又不易扩展。每当被要求添加功能时，不得不几乎完整地实现整个功能的流程，并修复与原系统的所有兼容问题。

[ 注释 ]

优秀的代码中，注释是这样的：

糟糕的代码中，注释是这样的：

最愚蠢的程序员都能写出机器能读懂的代码，而优秀的程序员能写出人可以读懂的代码。

程序的注释是为了让人读得懂。多数优秀的代码中，注释几乎接近代码行数的一半，描述函数功能、解释参数配置、指出陷阱所在。而糟糕的代码中不仅不含这些注释，甚至会保留大量残余代码，可读性差又难以重构。

[ 命名 ]

优秀的代码中，命名是这样的：

糟糕的代码中，命名是这样的：

命名是为了让代码更加容易阅读，使用规范的术语不仅更加易懂，同时也是开发者知识水平和开发经验的表现。如果说以中文拼音命名显得奇怪，那么直接以a, b, c, d命名的便会显得可恨，谁记得你的a是神马东西!

看一个经典的例子，字符串替换：

稍微有点Java常识的便会想到正则表达式：

何必拷贝这一堆的代码给老板看呢?开发中确实有很多时候，直接拷贝代码既能立竿见影地完成功能，又不会影响原有功能。但这样的代码多起来之后，万一功能调整你便需要重新debug所有的副本。花一些时间学习更优雅的用法是值得的。

[ 函数 ]

保持函数的短小，使你的代码更加易读，例如：

将复杂的逻辑分步骤完成。如果写在一起将会是这样的：

相信我，一旦你写了这样的函数，它会随着时间的推移变得越来越长，直到有一天，你也忘了其中的一段代码到底是做什么的。

事实上，复杂的函数不仅可以按照步骤划分，更应按照层次来细化。不要在一个函数中进行不同层次的操作，否则它会变得非常难懂。

本文作者：佚名

来源：51CTO

看似无害的代码如何搞垮系统 编程就像魔法。最近遇到一个诡异的问题：添加一段看似无害的简单代码后，系统原有功能不可用了。 ## 复现演示 jdk 8 可使用如下演示代码复现这个问题。 `TaskCenter` 是一个任务框架，可添加多个任务，随后框架将执行这些任务。 `First` 任务是新增代码，看起来简单无害，且看不出对原有任务 `Count` 有何影响，但添加 `First` 任务后，其自身执行正常，原本正常的 `C
程序员如何克服——可怕的“职业倦怠” 程序员这个职业压力大，节奏快，任务繁重，所以很容易令人感觉倦怠，令人感觉烦躁，郁闷，疲惫不堪。程序员如何克服可怕的“职业倦怠”，方法如下： 丰盛的早餐——身处高科技产业漩涡的我们常常会熬夜到凌晨两三点，然后又因为起得晚急匆匆赶去上班，因而没时间吃任何早餐。又或者，可能你只能在路上一些脏兮兮的早餐店中买点小得可怜的熏肉三明治。我们都知道早餐是一天中最重要的一餐。而且不仅仅是要吃早饭，吃什么也很重要。要吃一些富含蛋白质的健康食品，如豆类，鳄梨和全麦面包。不要吃白面包和早餐麦片，糖分太多，会让人血糖升高而瞌睡。 准时上床睡觉——预备9个小时的睡眠时间，保证能睡到7或8个小时。有的人
没有所谓好与不好，只是能否适用和用的好 从2006年Google在业界首次提出“云计算”(Cloud Computing )的概念至今，云计算已走过了十年，现在已是“凡人饮水处，皆言云计算”。 共享、敏捷和创新是互联网时代下企业信息化建设最大的转变。
选K8S是对的，但是用不好就是你的不对了 2013年以来Docker像一股旋风席卷IT界，Docker指的是容器技术，其字面意思是集装箱，此中类比有深意。 小小的集装箱不简单，曾有人著书《集装箱改变世界》，说他改变了世界经济，围绕其中的有一大串复杂又很有趣的现象。
你写的代码，是别人的噩梦吗？ Frank，是来自阿里国际技术事业部的高级技术专家，从业十年，也是一位英语说到飞起的型男。今天他将与大家聊聊关于企业应用架构实践的话题。