优秀的程序员都应当知道的11个警句.docx

优秀的程序员都应当知道的11个警句1. 技术只是解决问题的选择，而不是解决问题的根本我们可以因为掌握了必威体育精装版的 JavaScript 框架 ahem、Angular 的 IoC 容器技术或者某些编程语言甚至操作系统而欢欣雀跃，但是这些东西并不是作为程序员的我们用来解决问题的根本——它们只是用于帮助我们解决问题的简单工具。我们必须非常谨慎，不要对某项正好喜欢或者正好很火的特定技术走火入魔。否则，我们将进入这样的思维怪圈：把掌握的那项技术比做是锤子，在思考问题时，会自然的把所有的问题都想象成是锤子可以解决的钉子。2. 聪明是代码清晰的敌人当编写代码时，我们应当努力做到代码清晰易理解。虽然这句话并不总是正确的，但在一般情况下，聪明确实是代码清晰的敌人。事实证明，当我们写一段自认为非常了不起的代码的时候，这些代码在别人眼里可能会是一头雾水。所以当你在编写某段聪明高效的代码的时候牢牢记住这个原则是很有必要的。如果你对如何编写整洁清晰的代码很感兴趣的话，我强烈推荐你看罗伯特·C·马丁的书《The Clean Coder: A Code of Conduct for Professional Programmers》。3. 写尽可能少的代码这句话看起来有一些矛盾。程序员的工作不就是编写代码么?嗯，是的但也不是。我们的工作需要我们编写代码，但是我们在尝试解决问题的时候应当做到尽量编写更少的代码。这并不意味着我们需要尽量把代码写得更紧凑或者把所有的变量都使用单个字母。它的意思是我们应当尝试用更精简的算法来实现所需要实现的功能。通常情况下，我们在代码中所添加的各种很酷的特性是非常诱人的，这还能让我们的代码看起来更“健壮”和“灵活”，能够处理各种不同类型的情况。但是，在更多的时候，我们尝试更多可能有用的特性或者预防可能在未来存在的问题的做法是错误的。这些额外的代码可能不具备任何的价值，但是却可能造成更多的伤害。因为代码越多，出现未知错误的机会就越多，代码的维护也更加的麻烦。优秀的软件工程师写尽可能少的代码。伟大的软件工程师删除尽可能多的代码。4. 注释是代码表述的最后选择鲍勃·马丁曾经说过：“当你在为一段代码写注释的时候，你应当对自己糟糕的表达能力而反思。”这并不意味着我们以后就不要写注释了。但在大多数情况下这种情况是可以避免的，你可以选择用更好的命名方式来取代它。只有在使用命名都无法表述清楚某个方法或者变量的目的时，注释才是最后的选择。事实上，表达无法轻易在代码表达的东西才是注释的真正作用。举个例子，注释可以告诉你在代码中的那些奇怪的操作命令并不是一个错误，而是故意的，那是因为在底层操作系统存在着某个 bug。虽然在一般情况下，许多注释还是非常有用的，但是却存在着误导的风险。在其它代码更新后，与某些更新前代码相关的注释常常会得不到同样的更新，这就导致了某些注释会变得非常的危险，它们很可能会把你引导到一个错误的方向。你检查过与代码密切相关的每一段注释么?是否确保代码都是在按照注释所说的那样做?如果你都照着这样做了，那么注释的意义又何在呢?如果你没有这样做，你又怎么知道注释说的都是真的?所以，注释的作用并不象所宣扬的那么好，这种东西切勿滥用。5. 在编写代码之前你应当清楚你的代码要做什么这看起来是理所当然的，但实际情况却不是。现实工作中你有多少次是在没有经过充分了解到你的代码要干些什么就开始着手编程的?反正对于我来说，是不计其数了，所以我把这条记录下来用来随时提醒我。测试驱动开发(TDD)的实践在这里可以帮助你，因为你需要在编写代码之前了解这些代码将要用于什么地方，虽然这仍然不能阻止你创建错误的东西，但是它仍然非常重要。所以当你完完全全了解需要构建的需求和功能时，再动手编程。6. 提交完成代码之前先自行测试不要在完成编程工作后，就把代码扔给 QA，然后就坐等消息了。这样会浪费每一个参加处理不必要 Bug 和问题的人的时间。你应当在报告编程工作完成之前，花费几分钟时间运行测试场景进行自我检测。当然，在你把代码提交给 QA 之前不一定会发现每一个 Bug，但至少你可以杜绝一些我们每个人都可能犯下的愚蠢低级错误。很多的软件开发人员认为测试代码只是 QA 人员的工作。这是不对的。保持质量是我们每个人的责任。7. 每天都要学一些新东西有句名言“刀不磨要生锈，人不学要落后。”这句话是很有道理的，因为无论是否获取到新的知识，你每天都会遗忘掉一些以前的东西。每天学些一些新东西并不会花费掉你很多的时间。试着每天用 15 分钟时间去读书，然后你就会发现每天你都会有一点点的进步，在未来的某个时候，你会发现这种进步是巨大的。因此，为了在今后获得丰厚回报你必须从现在开始就进行投资。另外，今天的技术发展日新月异，如果你不改善自己的技巧，学习新的东西，你很快就会被甩开。8. 写代码