1.编程最可怕的不是语法难，而是逻辑乱
复杂化的业务，带来各种各样的逻辑问题，可能由于一个小数点，就会导致很严重的线上事故。当语法已经成为了一种过去式，那么逻辑正确则是代码的必备技能了。在逻辑的基础上，更有可能需要兼顾并发，性能和容错等问题，会将代码的逻辑的复杂程度成几何倍的上升。这样的结果会导致问题，会让你在你原有的基础代码上打补丁，最终造成整个代码臃肿且效率低下的情况。因此，在开始设计代码思路的时候，就应该有一个人来把控这样的大局观，来考虑这些方方面面的问题。
2.请永远对线上代码保持敬畏
代码的好坏并不是通过自己的主观判断来决定的，看似很傻逼的一段代码，可能是因为当时的环境造成程序员迫不得已这样去实现这段逻辑，而且这段代码可能在线上已经运行了很久，随意的更改可能会导致线上问题的产生，而且由于历史原因，对这段代码重构的成本将大大超出预期。如果你读不懂这段代码，请对它保持敬畏，说不定在某个地方起着关键性的作用。
3.最优解的追求并不是最佳选择
每一个程序眼里都有一个最优解，而因此诞生了算法这一产物。但是，最优解的本质，并不一定适合现代的业务开发，最优解的实践往往是精简且特立独行的思维方式，而在“敏捷开发”的实践中，快速更替迭代，才是最有效的开发方式。花费大量的时间去理解代码本身，则是一件非常不友好的方式。虽然最优解确实能够带来性能的提升，但是实际中从各方面的成本核算来看，并不能起到关键性的作用，尤其在现在硬件性能以及极为强悍的今天，快速实现业务功能，才是最有效的考量。
4.没有以用户体验为目标
做一个应用，一定要以用户的角度来看待问题。如果只是以自己实现的逻辑的角度，将不一定有一个用户友好功能。要做专业的开发者，站在最终用户的角度看问题。专业的开发者要考虑这个特定功能的用户需要什么、怎样使用，要想方设法使得这个功能容易让用户发现和使用，而不是想方设法在应用中用最便捷添加这个功能，毫不考虑这个功能的可发现性和可用性。
5.要学会自己造轮子
关于某种固定的任务，可能会用到特定的逻辑，当多次进行实践的情况下，特定的逻辑就可以抽象为一个特定的工具。这样的实现会大大增加你的开发效率。一些程序员明显只是针对每一次任务的完成而完成，并不会思考自己为什么要这样完成，为什么要用这样的方法，而在下一次相似的业务逻辑下，则又一次的重复相同的逻辑开发。这样的开发不仅仅对自己的提升有限，且对业务逻辑的处理不友好。
6.不要重复的造轮子
这是一件很恐怖的事情，这里承接上面这一点，造轮子是为了提高自己的编程效率，而重复的造轮子则是浪费资源的一种行为。在开源软件的大前提下，很多的轮子是开源免费的。因此，使用别人的轮子，并不是否定自己的过程，而你要做的，是花时间在轮子的改造上下功夫。这里有个需要注意的点在于，千万不要因为一个轮子，而引入大部分的代码，这样本身的逻辑将会因此而臃肿不堪。
7.要让自己的代码有迹可循
代码一旦上线，就很难进行调试，往往线上一旦出现bug，能依靠的只有自己的日志。而这些日志，则会成为你寻找bug的唯一线索。因此，在合适的地方打日志，将会是你职业生涯中必备的能力。为了让自己的代码有迹可循，每一个分支逻辑都需要日志进行记录，且每一个函数的入口也要有固定的参数。只有这样，才能在遇到线上问题的情况下，让你不会无计可施。
8.版本控制
业务逻辑必然需要版本控制，没有任何的例外。没错，我这里说的这个控制工具就是GIT。源码控制并不仅仅是你把你的更改推送给别人，让他们在此之上接着开发，除此之外还有更重要的。源码控制是和清晰的历史相关的。源码会被质疑，代码的历史进程能够辅助回答这些困难的质疑。这就是为什么我们如此关注提交信息的原因。它们还是又一种交流实现的通道，使用提交信息能够帮助将来的维护者弄清代码为什么会发展到目前的状态。
更多信息，请关注【计算机俱乐部】