写给新入行的同事们

最近跳槽了，老板希望我留些心得体会。我想了几天，零散总结了一点东西。如果写的莫名其妙的，还望各位不要笑话。

1

首先说下软件行业在我看来是怎么回事。软件行业是个非常年轻的行业，大概只有四五十年吧。四五十年是很短的，一个只有四五十年历史的行业是很不成熟的。成熟的行业是个什么样子的呢，我们可以看看汽车、纺织和建筑等等存在了成百上千年的行业，它们在制作工艺、产品质量、从业资质、销售模式等等方面都有非常成熟的标准，符合标准的产品基本上都不会出现明显的质量问题，也就是说这些行业的产品具有稳定可控的质量。反观软件行业，在质量控制方面还在摸索之中，没人能保证软件项目或产品一定能达到什么水平。从瀑布模型到敏捷开发，从 CMM 到 Scrum 等等工具，人们都在摸索，在这个摸索过程中，没人能保证某个组织使用过的某个成功的软件开发方式，一定能适用于其他组织或其他项目。这是第一个方面，软件行业还没找到生成可靠的产品的方式。而另一方面，随着近几年智能手机日常化，软件开始爆发式的侵入人们的生活，每天都有新的应用出现——急剧扩张的势头也是年轻行业的一个典型特征。第三个方面，软件行业内部的职位也在不断变化，前端工程师在十年前大概还不存在，随着职位划分越来越多，全栈工程师的概念也被提出来探讨。最后，新的技术不断的出现并受到热烈追捧，比如大数据和云平台，它们甚至已经成了软件业中的一个小产业。总之，只要你关注下行业动态，就会发现这个行业每天都在变。这正是其年轻的象征。

2

研究如何让一个软件团队产生高质量的软件，这样的学问叫软件工程。软件工程是团队运作的基础，是公司运作的基础，更是整个行业运作的基础。不像技术那样日新月异的更新，这种基础性的东西发展是很慢的。三十多年前的《人月神话》每年都再版，到现在仍然是程序员的必读启蒙书。还有一本《人件》也是必读，前者告诉你软件开发是什么，后者告诉你程序员是什么。它们跟《Thinking in Java》的区别在于后者是初中生都能看懂的纯技术书，而前者只有成年人能看懂，它们是关于人的书。

3

有本书上说，最好的程序员要比最差的程序员强 28 倍。而实际上，最好的程序员薪水也拿不到是最差的程序员的 28 倍那么高，所以老板喜欢好的程序员——效率高，单位薪水却相对低。好的程序员好在哪里？可能存在很多方面，但我觉得最重要的一点是：手段多。在这世上，不管哪个问题，解决的手段肯定都不止一种。解决问题的手段越多，遇到问题的时候就越得心应手，游刃有余，知道哪种手段最适合解决当前的问题。比方说，用什么数据库？唰的手一挥，各种数据库摆在面前来挑；用什么处理 JSON？jackson，gson，fastjson 都摆在你面前让你挑。怎么读 Excel？jxl，POI，随你挑。用户属性多变怎么办？横表，竖表，随你挑。是吧，镇定自若,临危不惧，指点江山，游刃有余，这个小小的程序员挥手言语间就不经意的透露出一种王者霸气。

嗯嗯，那么怎么积累这些手段？一方面是实际的工作经验，但这远远不够，更重要的是自己去找，凡是能帮助自己解决将来可能遇到的问题的框架，工具，类库，都去用下熟悉下，那么到了遇到问题的时候，就知道拿什么工具去处理了。关注业界的动态，你会看到每天都有很多新的工具出现。其中有的可以用来代替原有的工具，因为它们更好用，效率更高。

4

软件工程是跟人有关的学问，但软件开发本身还是跟电脑打交道的。不是每个人都适合跟电脑打交道，要跟它好好打交道的话，你得是一个冷静客观诚实的人，至少培养自己的这方面品质。

比方说冷静，有的人不冷静，不冷静的人遇到问题就是慌的，脑子里只想着一件事：

怎么会这样怎么会这样别这样别这样……

他们甚至希望时间能帮他们解决问题。说实话，在生活当中，确实不少问题靠时间就能解决——晾在一边即可。但在软件行业行不通，电脑的耐性绝对比你强。所以遇到问题第一个反应就是要找原因，冷静（下来）与其说是一个动作，不如说是在整个解决问题的过程中都要始终保持的一种状态。

第二个客观是什么意思呢？在电脑看来，所有的运行结果都是正常的，不存在对错之分。如果你编写的代码行为与你的预期不一致，那么有两种可能：要么你写了错误的语句（比方该加的时候减），要么出现了你没有预料到的状况（比如参与计算的某个条件是空的）。软件运行的时候会遇到各种各样的状况，对计算机来说没有差别，成功和失败都是正常的结果。而对某种状况是否处理，决定权在你手里，你会根据自己的喜好来决定。

第三个诚实。计算机是最诚实的，这点本该毫无疑问，但不知道为什么我总看到有人怀疑计算机。当计算机报告一个错误发生时，他不相信，他不去看错误信息，而是尝试从别的地方找原因，到处找原因，就是不看错误信息。直到所有的尝试都徒劳无功，他才会看下到底哪里错了。我完全没办法理解这种人心里是怎么想的。

5

代码是什么，代码是软件开发的成果，是程序员心血的结晶。但它又是那么的捉摸不透，我敢保证，每当你写完一段代码，端起杯子喝口水的时候，你都会不由自主的思考两个问题：

1. 这段代码对吗？
2. 这段代码牛逼吗？

刚入行的程序员对“代码质量”是毫无概念的，但我还是想尝试说明一下什么是代码质量：

一段代码，你假设它是一个故事。这个故事，有头，有尾，有经过，有分支。程序员就是讲故事的人。代码质量好不好，就是故事说的好不好。有的程序员讲出来的故事，别人半天看不懂，这样的代码就是低质量的。

高质量的代码，或者说牛逼的代码有什么样的标准呢？我介绍一个简单的检查方式，就是重新阅读你的代码，看能否做到：

1. 30 秒内看完并完全理解。
2. 阅读的过程中只往下看，不会去重新看前面的内容。

不说一定要达到这个标准，也要以它为努力的方向去写代码。关于代码质量的书，推荐下面几本：

• 《重构：改善既有代码的设计》这本书主要介绍糟糕的代码到底哪里糟糕，以及如何改进；
• 《实现模式》这本书介绍代码表达能力；
• 《设计原本》这本书介绍“设计”与“构思”本身是什么样的思维活动，设计风格是怎么回事，经验在设计当中起什么作用，一个已经完成的设计又会出现什么样的演化。

最后一本书非常的抽象，非常的装逼，但你一旦理解了，就会发现它非常的有用！因为它帮助你审视自己的思考方式。一个程序员变得牛逼的过程，就是其思考方式不断进化的过程。牛逼的书是一下子看不懂的，只能每隔一段时间拿出来翻下，也许就能慢慢理解。

另外还有被称为 “设计模式六大原则” 的设计准则可以用作对代码质量的评价参考。

6

怎么用 logger 框架写日志。常用的框架有 log4j，commons-logging 和 slf4j，它们的作用就是在日志文件中记录某个业务处理过程的状态。日志是很重要的，如果日志记得好，我们就能清楚的看到业务处理怎么开始怎么结束，来龙去脉都清楚；一旦出现 BUG 或故障，光靠看日志就能得到足够的信息，定位问题出在哪里。日志记得不好，出了问题什么日志里面都看不出，只能用别的更耗时间的手段来处理了。

如何记好的日志，一个简单的原则就是：每次出现分支的时候都记一条日志，标明流程往哪个分支走了。遵守和不遵守这个原则，你会感受到天堂与地狱般的巨大的差别。

7

有两句话绝对不要相信：

1. 代码看不懂没关系，能用就行了。
2. 所有的软件都不过是增删改查。

如果开发团队中有成员坚定的抱有这样的态度，项目负责人应该尽早将这种人驱离开发团队。