介绍

入行已久，中毒很深。和那些职场新人相比较，已经显得“老迈”了很多，精力、体力都已经从优势变成了劣势。但是，身为“懒惰”的程序员，如何才能可持续地保持自己的这份“自豪感”呢，毕竟这是个残酷的世界——没人会关心你的过去，只在意你是否还有战斗力！

有核心竞争力的人，才会有持续的战斗力！为了不让自己过快、过于凄惨地被淘汰，我每天都在磨练、探索自己的核心竞争力。各位看客，你的每一天都是怎么度过的呢？

•测试

一直对测试这份工作了解很少，虽然身为开发的屌丝是经常和测试MM有工作上的交集。很多情况下，我们止步于功能完成，没有报错，Bug库里没有自己的名字；但这远远不够！

对于开发人员来说，设计、编码完成后，还要做“自测”——点点页面，单元测试。我们大部分做到的是，通过界面来操作，然后查看生成的数据是否符合要求；或者只是看看页面上有没有报错。但，开发人员的自测其实还可以做的更加深入和细致。

页面、浏览器控制台、服务器日志上都不能有未预料到的异常报错，或者本来应该有异常但是又没有给出异常提示或者日志。之后，再到数据库中核实数据是否符合预期。至于单元测试嘛，大家都在喊着要做，也都认为非常地重要，但没有几个人或者团队做到了。很多情况下，他们写的程序对“测试”并不友好，在编码过程中完全没有思考该如何进行测试——因为，我们不了解测试到底应该怎么进行。

这里，我提出一个概念，先设计，再思考如何测试，最后编码。

每一个开发人员，都应该是一个非常出色的测试。功能、WebUI、性能、安全、压力测试等等，我们一个都不能少。自己写出来的东西，居然不会测试，也不知道实际的效果（性能）是什么情况，怎么好意思说这个是你做的。

写一个自动化测试平台，然后用这个平台来对自身做WebUI测试。另外，性能、安全测试都必须上。JMeter、Selenium、SoapUI都是应该下功夫搞定的。下面是我开源的自动化测试平台的项目源码，欢迎拍砖！

https://github.com/LinuxSuRen/autotest.platform

•源码

阅读源码将不再是件神秘的事情，不高深，也不值得吹嘘，我们必须每天看、经常看。因为，我们已经到了必须尽快地掌握技巧，就和高中的语文阅读理解一样，抓重点、弄明白中心思想；提高阅读过程中的脑容量——有层次，看结构，挑刺，要无耻地把别人的东西统统变成自己的，哈哈！是不是很邪恶。

打算走技术路线的人，一定是要保持在最前线，读码、编码、调码一个都不能少。

•审查

说到代码审查、重构，有些人不屑一顾，认为这是每个程序员的自我欺骗。而我要说的是，有这种想法的人，是因为你做的不够专业——至少是没有专业精神，没有工匠精神。当然，如果你是在给“别人”写代码，环境不容许你有重构、审查代码的时间，是情有可原的；但，你为什么不给“自己”写点代码呢，难道就完全没有时机吗。

根据项目开发经验来说，有以下几种情况：
1.看着别人写的代码很烂，自己又想不出更好的办法来改进，周围又没有可供咨询、学习的前辈（或者觉得没有这个必要），所以就“同流合污”。
2.看着别人的代码很烂，很难改，但还是要努力跟上“烂”的节奏，尽力把任务完成。有的领导认为这种人很上进，不怕困难，值得表扬。可是，你在想想，他除了把之前“烂”（可读性差、难以维护）的代码变的更多以外，有什么贡献的；关键是，他哪天离职了，又有新人补充进来怎么办？这部分代码会渐渐地变成谁都不敢动的地方。
3.我能把功能、任务完成就不错了，人家之前也写了那么多的代码和功能，也能使用啊，大家都听不容易的。
4.项目经理说，不要轻易对代码或者模块进行重构甚至改进，这样的风险很大，测试的同事们还会因为你的改动不知道要加多少班。

所以说，在实际项目开发过程中，想要做到代码质量的持续改进是非常低困难的，主客观因素都是饱满的。

在这里，我给希望能做到精益求精、持续改进成长的童鞋们提一个建议：做开源项目吧。你是项目的发起人，你就是架构师、项目经理、需求、开发、测试，甚至你还是销售、运维；你将有机会接触到项目的全流程，你将会有权利来做任何程度的改进、重构，甚至，你可以把项目推翻，重来一次。只要你的热情是饱满的！当然，假设某天，你发起的开源项目做大了，也是不能随随便便地做改变；但是，从你刚进入开源的事业来，到你能搞大一个项目，路还很长；你真的走到那一步的生活，也就真的成了架构师了，你的项目也能做到高内聚低耦合。怎么样，有兴趣吗。

在我GitHub中的项目，都会不定期地进行代码审查，只为了能做到更专业！欢迎监督、拍砖。

•部署

说到项目部署，有的人可能认为是运维或者实施的人应该去做的事情。但我还是那句话，连写好的程序都不会部署，你还好意思说这是你写的吗？

项目部署绝非是件简单的事情，想想有多少人是死在环境的路上。虽然，Docker的出世就是为了解决环境的问题，但它本身不也需要一个环境吗？持续集成，应用虚拟机，构建工具我们都是要熟练地使用。在Windows上编码习惯了的人，Linux应该是必须会的吧。

首当其冲的，是JVM的部署或者安装了。Windows和Linux下的Java环境变量的配置，PATH、CLASSPATH、JAVA_HOME等变量的准确含义必须要弄明白。另外，Java的版本也是很重要的一块。每个程序都会有一个支持的最低版本。

•分享

我不是个多么高尚的人，但随着阅历的增长和对生活的理解，事实就是这样的——我们每个人都对周围的人、家庭、生活应该肩负起一定的责任。好了，这是个虚的理由。你可以忽略不管。但是，下面我再给出一个自私的理由，谁让我骨子里总是有自私的成分呢，哈哈。

如果您以为您对某个技术或者问题已经掌握的很好，甚至已经可以成为这方面的专家了，那么，这个结论一定是有待考证的。您一定也不希望自己是个自以为是，井底之蛙的人（假设碰巧是的话，请绕道），那么我推荐一个可以验证您是否“权威”的方法。那就是去给别人讲，讲给你周围的人，讲给圈子里的人，讲给外行抽热闹的人。

假如，您能讲明白了，大家伙也都听明白，而且都感觉有所收获的时候，您才可以诚惶诚恐地认为自己也许是某方面的专家或者权威了。或许，到这时候，您会觉得自己只是个刚刚跨过这个领域的小学童而已。

分享，除了可以让您成长，还可以发挥余热——照亮别人。温故而知新，也许就是这个道理。

但是，到这里就算完事了吗。记住一句话，学习和成长之路是没有尽头的。我们除了自己要变得喜欢做分享以外，还得努力感染别人也如此这般。我认为，一个好的团队的特点之一，应该包括热衷于分享，热衷于互相帮助成长！

•问题跟踪

Jira是比较优秀的一款问题（bug）跟踪管理系统，可以推荐给各位使用（当然，这是个收费的）。

如果，您已经做到了这个年头上，不论您是否已经走到管理岗位上，都应该多花点时间来把这个（或者其他的问题管理工具）玩的熟练了。我这里有个比较自私的理由，您迟早会用到这个的，不然您到时候怎么去管理、带领一个团队来干硬仗。

我认为，不管是项目经理还是开发技术经理，都已经对当前项目中的所有问题都掌握的很清楚。包括：问题的数量、严重程度的分布、问题负责人的分布等。

•争

如果您有幸已经到了管理岗位，最应该做的事情就是给团队里的每一位成员极力地争取。更多有关这方面的看法，请参考《团队建设》。

•本系列文章

Java开发成长之路第一年

Java开发成长之路第二年

Java开发成长之路第三年

Java开发成长之路第四年

Java开发成长之路第五年

Java开发成长之路第六年

Java开发成长之路第七年