我是一个倾向于生活在规则下的人。 现在，这些规则大部分是我本人为自己设立的-但它们依然是规则。 我发现为自己创建规则可以让我过得更好，因为这样做可以提前决定一些事情，而不是要在匆忙中做出所有的决定。 我今天早上应该去健身房吗？ 我的规则告诉我说我要在周三前往健身房，今天是周三，因此我要去健身房，就这么办了！ 这周，当我正在思考那些对我施加有影响的规则时，我想到了去制定一系列软件开发者都应该遵守的规则，我认为这可能是一个好主意。 现在，我承认，这里面的大多数规则比那些“指导方针”要求的要多，它们是： 1: 技术是用来让你获取解决方案的，但它本身并不是解决方案
我们带来了最新的JavaScript框架-ahem，Angular—IoC 容器，编程语言或者甚至是操作系统，但是所有这些并没有实际解决我们作为一个尝试解决问题的程序员的问题，取而代之的是更简单的工具帮助我们解决问题。 我们对于特定的技术必须非常谨慎不要太疯狂，不是我们碰巧喜欢或者碰巧现在很流行，而是要考虑运行他们所带来的风险，要思考这个问题是不是就是那个钉子，而我们是不是碰巧拿着锤子，那么我们就要学习它。 2: 对代码而言，“聪明”是“清晰”的敌人
在写代码的时候，我们应努力保持书写的代码清晰易懂。 可以明确（Clear）表明自身意图的代码，永远要比那些晦涩的代码更有价值-无论那些晦涩的代码被构建得多么聪明（Clever）。 虽然情况并不总是这样，但一般来说，“聪明”是“清晰”的敌人。 一种经常出现的情况是，当我们写出一段“聪明”的代码时，这段代码并不是特别的“清晰”。 这条规则非常重要，尤其是当我们思考我们要做一些特别“聪明”的事情时。 有时候我们写出了“聪明”的代码，它们同时也是清晰的，但是其他情况也会时有发生。 如果你对写出简洁的代码感兴趣，我高度推荐你用下面这本书上描写的规则来检验：Robert C. Martin的《干净的编码者：专业程序员的行为守则》（The Clean Coder: A Code of Conduct for Professional Programmers） 3: 只在逼不得已的情况下才写代码这条可能会有些争议，毕竟，作为程序员，我们的工作不就是写代码吗？ 嗯。。。这个看你怎么说了。 写代码的确是我们工作的一部分，但是，我们要尽可能努力的去用最少的代码来解决问题。 所谓“最少的代码”并不是说我们只能用一个字母的变量名或者其它方式来压缩我们的代码。“最少的代码”指的是我们应该只写为了实现功能而必不可少的代码。 我们常常添加一些“酷”的功能，来让代码“健壮”和“灵活”，让代码能够处理“所有”可能的使用情况。我们企图猜测那些可能会被用到的功能。总之，我们常常花费时间去解决一些头脑中臆想出来的可能的情况。 我们这么做，是错的。 不能否认，这些多余的代码能会带来些好处。然而，这些代码同样的会有很多危害。我们写得代码越多，就越有可能引入错误；我们写得代码越多，将来的维护工作就越繁杂。 好的软件工程师只写绝对需要的代码。 伟大的软件工程师会把没用的代码统统都删掉。 4: 注释是魔鬼
我并不是很热衷于写注释。当我跟Bob Martin在一起时，他说： “你写的每个注释，都代表着你表达能力的欠缺“ 这并不是说一点注释也不写，但通常我们可以通过一种更好的方式——命名来避免。 注释仅在命名不能有效表示变量或方法的意图时才真正需要。此时的注释表达了不能用代码表达的真实意图。 例如，注释能够告诉你在代码中某些奇怪的操作顺序并不是错误的，它是由于底层系统的某一bug而有意为之的。 但通常，注释不仅没有必要，有时它们还会"撒谎". 注释没有随着代码更新的倾向，而这是很危险的，因为它们会将你带入歧途。 你会查检每条注释和与之对应的代码，确保代码是在做注释说的事么？如果是的话，写注释还有什么用？如果不是，你怎么相信注释说的是对的？ 真他妈麻烦，所以最好还是尽量别写注释了。 OK，喷子们，在下面的评论区里留下你们的“口水”吧，但我会无视你们的。 5: 永远要在你开始写代码前考虑好它是做什么的
|
