最近，在办公室老大与大家闲聊。问：如果你有解决不了的Bug，是先放着，还是……
有同事说，出去上个厕所，回来，可能就有答案了，哈哈~
原来大家都有这样的经历，哈哈哈哈~
###下面分享日常工作中经常使用的“点子”
####1.
将大块代码拆分成函数。
####2.
下班的时候还有问题没解决，请关上电脑，明天再看。
####3.
YAGNI 原则（你不会需要它）： 只写别人要求你写的功能。 不要预测未来，只需要尽可能快地完成开发。 只编码解决当前问题最必要的部分。
####4.
你不需要什么都懂，也不需要了解所有框架。 最棒的事情莫过于打好基础。 在开始使用一个框架前先深入了解这门语言，学习基础的事项（如 SOLID 原则），或者如何写出干净的代码。
####5.
KISS 原则：KISS（保持简单和愚蠢）原则表明，大多数系统保持简洁而非复杂化，就可以运行得很好。尽管这很符合逻辑，但有时候却很难做到。
####6.
不要想太多。
####7.
如果你和一个问题或 bug 斗争了太长时间，先离开一会儿，等下再回来。 通常，在离开办公室去往卫生间的路上，解决方案就会出现在脑海里。 当你对客户或同事生气时，也建议你暂时离开去走走，如果你还想保住工作的话……
####8.
学习写有用的测试，学着用 TDD（测试驱动开发）。 TDD 是一种软件开发流程，它是对如下简短开发周期的重复： 写测试； 运行所有测试，查看新的测试是否运行； 写代码； 运行测试； 重构代码； 重复。
####9.
先解决问题再写代码。
不要在一筹莫展的时候开始编程。
####10.
不要记代码，而是理解逻辑。
####11.
如果你复制粘贴 Stack Overflow 中的解决方案，请确保自己首先理解它。 学习用恰当的方式使用 Stack Overflow。
####12.
想学习，先实践。创建示例，并使其运行，因为只通过阅读来学习远远不够。
####13.
研究他人的代码，也时不时让别人研究你的代码。 结对编程并进行代码 review 是不错的想法。
####14.
不要重复造轮子!!!
####15.
代码是最好的文档。
####16.
了解如何搜索。你需要有经验，大量阅读，了解需要找什么。
####17.
你写的代码以后会由自己或别人进行维护，因此写的时候想着读者，不要把自己当做最聪明的人。 写代码要像写故事一样。
####18.
用谷歌解决错误的最佳方式是复制粘贴。
####19.
不要放弃，问题总能得到解决的。糟糕的时刻总会过去。
####20.
好好休息。解决问题的最佳方式是先让大脑得到充分休息。
####21.
学习使用软件设计模式。 设计模式是软件设计常见问题的解决方案。 每个模式就像一个蓝图，你可以依据它进行自定义，进而解决自己代码中的常见设计问题 （记住，不要重复造轮子）。
####22.
尽可能地使用集成工具和自动化方式。
####23.
练习编码套路（code kata）：编码套路是一种编程练习，可以帮助程序员通过重复实践来提升技能。
####24.
编程并达到接口水平，而不是实现水准。依赖注入是必要的，参见 SOLID 原则。
####25.
重构——测试 - 重构。 重构即对现有代码进行重建、改动，在不改变其内部行为的前提下提升内部结构。
####26.
必要的时候寻求帮助，不要浪费时间。
####27.
多实践，熟能生巧。
####28.
尽管有时候注释可以帮到你，但不要在这上面花费太多注意力。注释可能是过时的。
####29.
了解自己的开发环境，并建设足够强大的开发环境，如 IntelliJ。
####30.
重用组件。
####31.
在开发 web 应用时，思考移动端及其相关的电量和带宽限制。
####32.
不要过早地优化或重构代码。尽快做出最小可行性产品比较重要。
####33.
不要为了节约几分钟，而选择低效的捷径。每次写代码，都要竭尽全力。
####34.
遵循文档标准。
####35.
用户不是技术人才。开发 UI 时时刻想着这一点。
####36.
经常使用 GitHub 或 bitbucket 等源代码控制系统，并频繁进行小的提交更新操作。
####37.
使用 log 要比代码 debug 更好。将所有关键部分记录下来。
####38.
写代码时要保持连贯性。 如果你使用一种风格，请一以贯之。 如果你和多人合作的话，请和整个团队使用同样的风格。
####39.
不要停止学习，不止是学新语言或新框架，还要关注软件开发基础知识。
####40.
最后，保持耐心，保持热爱。
