给新开发者的一般性思路/指导原则

这是一份面向经验不足的软件开发人员的通用指南。这些道理是我多年来慢慢领悟的，我想如果当初我刚开始学习编程的时候能看到这些，一定会对我帮助很大。

1. 你的代码应该易于阅读。为什么？这句名言会解释一切。

   事实上，阅读时间与写作时间的比例远超 10:1。我们不断地阅读旧代码，以此来编写新代码。……[因此，]让代码易于阅读，就能让编写代码变得更容易。

   • 罗伯特·C·马丁

2. 测试……有些客户/项目经理认为在测试上花钱是浪费。你不需要这种消极的想法。测试有很多好处！首先，它们可以检查你的代码是否真的能实现预期功能。其次，重构——你是否曾经尝试重构一个类，并希望每个方法都能返回和以前一样的结果？测试也是一种文档，可以帮助新团队成员理解代码的工作原理和原因。

3. 尽管代码本身不会说谎，而注释有时会说谎，但通常来说，给代码添加注释仍然是个好习惯。尽量避免使用解释复杂代码的注释（参见第一点），而是将注释用于解释业务逻辑，即这段代码为什么会执行它所执行的操作。

4. 作为开发者，你有责任照顾好你的…… 孩子代码。你认为重构已经到位了吗？去找你的客户或项目经理，向他们解释为什么重构是明智之举，而且是必要的。技术债务总是会卷土重来。

5. 有没有想过为什么开发者身边总是围绕着橡皮鸭？当你被一段代码卡住时，不妨试着跟橡皮鸭解释一下。这种方法叫做“橡皮鸭调试法”，是开发者工具箱里一件非常强大的武器。跟别人讨论你的代码，尝试解释它，可以帮助你摆脱困境，并从不同的角度思考你的代码。
   有时候，即使是橡皮鸭也帮不上忙。那就去找其他人交流，最好是其他开发者 ;)

6. 你听说过敏捷开发吗？它提倡每天开会，团队成员互相交流，分享遇到的问题或困难。不妨试试看，当每个人都清楚自己在做什么时，分享想法和寻求帮助就容易多了。

7. 文档。比测试更让人头疼。想想看，如果没有文档，你该如何使用你最喜欢的 API 或第三方服务？为了让你的团队成员和其他团队在使用它们时感到满意，请务必记录所有面向公众的内容。

8. 记住软件开发原则（DRY、KISS、SOLID和YAGNI），并尝试在日常工作中运用它们，例如，提取类或模块（DRY）将有助于保持代码的可维护性。

9. 有时候，当你通读代码时，你会发现一些奇怪的地方，或者干脆就是一段糟糕的代码。当然，它现在能运行，但如果可以轻松改进，何乐而不为呢？这就像童子军的准则——“离开营地时，要比你来时更干净”。

10. “三思而后行”——在实际开发之前，最好先思考（或写下）事情。

11. 你可能觉得意外，但你是人，人都会犯错，你也会犯错。那就坦然面对吧。我认为，犯错是工作的一部分。尽量充分利用这个机会，犯错后，尽可能从中吸取教训。

12. 不要犹豫提出问题和反对意见。问题可以引发关于为什么需要这项功能、我们应该如何实现它以及这种实现方式存在哪些风险的讨论。

13. 保持学习热情，并乐于分享知识。书籍、博客文章、RSS订阅源、会议、播客、本地用户组会议，这些都是学习新知识和交流经验的绝佳途径。

14. 时刻关注你所使用的框架/库的新版本和新库。新版本会带来令人兴奋的新功能！

15. 充分利用你的工作流程。你在用 Vim？很好。Atom？不错。Sublime？太棒了。把代码写在纸上再扫描？怎么舒服怎么来。你想知道哪个编辑器/IDE最好？最好的就是让你用起来最舒服的那个。

16. 尽量保持专业态度。不要使用“我们拭目以待”和“希望”之类的短语。如果你把车送到修车厂，修车师傅却告诉你“希望他能修好”，你会作何感想？

17. 永远不要害怕提问。如果你不知道某件事或者不确定，看在上帝的份上，一定要问。

PS：哦，别忘了把鲍尔默峰也考虑进去！ ;)