入职半年多，被diss无数次，Guide哥含泪总结了这些原则。
入职半年多，被diss无数次，Guide哥含泪总结了这些原则。
1.修改代码要慎重
修改代码之前，一定要思考清楚，不要自以为很简单，结果改了之后出现了大问题。这个在我们写代码的时候也一样，一定要思考清楚之后再写。
就拿我自己举例子，我们一般项目上都是开发做完相关功能之后，测试随后会对你做的功能进行一系列测试。很多时候，QA 测出一些问题之后，我都自以为很简单，并没有太多思考，然后修改之后发现又出现了其他问题。
代码很多时候就是这样的，这个地方的 Bug 补上了，说不定另外一个地方的 Bug 又出现了。所以说，修改代码和写代码的时候一定要慎重，一定要思考清楚一点。
2.Code Review 很重要
代码复查或者说 Code Review 很重要！这是一项成本不大，但是做好了之后收益非常非常大的活动。
一般情况下，大部分项目定期都是要做 Code Review（一天一次最好）的 ，尽量细致到每一行代码或者每一行重要的代码。对于代码中存在的问题，不论是命名问题、潜在的 Bug 还是某部分代码有更好的写法都要当场指出。
我听到过很多人说平时工作太忙，根本没有时间 Code Review，我觉得这只是一个逃避 Code Review 的接口。孤尽大佬在他分享《Code Review 是一场苦涩但有意思的修行》 这篇文章中也说到：
“业务跑得快，代码写得快，可能写的是一堆没有营养甚至是有毒的代码。我们需要追求的是 Code Review 的效能，而不是逃避 Code Review 。Code Review 是一种修行，对于双方都是一样的收获。
3.尽量减少 TODO
TODO 描述的是那些我们应该做，但是出于某些原因暂时还没有做的事情。
随着项目的发展，你们项目的 TODO 是不是越来越多了呢？你自己写的 TODO 最后是不是到了项目结束或者上线还没有做呢？
实际上这是一个不那么好的习惯，现实工作中尽量做到记得定期查看 TODO 注释，能完成的尽量完成！不能完成的呢？emmm....留着以后接手代码的人来做吧（开个玩笑~能做还是要尽量做）！
说到这，我赶紧去看了一下我所在的上个项目的代码。
emm...，不说了，TODO 貌似有点多，打脸了。
4.不要孤立的写代码
一定不要孤立地写代码，多看看别人的代码。 这样我觉得有下面几方面的好处：
- 避免了团队的单点因素，比如某一部分的代码只有某个人懂；
- 提高了代码质量；
- 从别人的代码中或许也能学到一些东西；
- ......
另外，国外很多公司都是结对编程，这玩意好像在国内行不通啊！
“结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。
一个人孤独的编程可能是下面这样的：
如果，两个人一起 结对编程（Pair programming）的话，可能是下面这样的：
5.试着从更高的层面去了解大部分代码的功能
大型系统几乎没有一个人能够明白所有代码或者功能。除了你正在开发的功能之外，试着从更高的层面去了解大部分代码的功能，这样你就可以理解各个功能块之间是如何交互的了。 这个建议在我经历的上一个项目（学生答题类）中感受颇深。整个项目虽然不是很庞大，但是业务功能点还是比较多，初期的时候，我没有搞懂学生教材选择那块的逻辑 ，导致后面我做学生答题统计模块的时候又花了很久询问相关的同事才搞清楚。
6.选择值得投入的技术
在我大学刚学 Java 后台开发的时候，我学习过什么呢？实话实说是 JSP、Struts2....这些现在看起来老掉牙的技术，这些技术放在现在确实没有学习的理由了。
我自己当时学这些实际也是踩了坑，被一个学长忽悠了，他对我说很多公司做项目还是用这些技术。奈何他当时比我厉害，所以，我选择相信了他。
我们每个人的时间都是有限的，这个在工作之后的感触尤其明显，所以，我们一定要尽量在有限的时间去学习那些值得我们长期投入学习的技术。
一项技术是否值得长期投入学习，简单来说，我觉得主要可以下面 3 点：
- 这个技术的学习成本。
- 这个技术的发展势头如何（Google trends 能很好的反映一项技术的发展势头）。
- 看看一些业界比较权威的技术大佬对这个技术的看法。
