翻开日历，不知不觉间，2017 年的余额已不足 2%，这一年又猝不及防的步入了尾声。今年过得怎么样？你的目标还差了多少？
在这一年仅剩下的小尾巴里，咱们程序员可以好好总结一下将要逝去的 2017，规划即将到来的 2018。下面先来看看程序员工作中的 17 种状态，你中枪了吗？
程序员的 17 种状态，扎心了
1.明明是个小 Bug 但就是死活修不好...
2.作为一个码工我意外走入了一个充满 PM 的会议室...
3.偶然间看到了自己多年前写的代码
4.调试过多线程的都会懂！
5.这就是你们追捧的结对编程
6.Git merge
7.当他们问我是否需要兼容 IE 的时候
8.当我以为已捕获了所有可能的异常的时候
9.你永远 try...catch 不到所有的可能性！
10.数据库的 Delete 语句忘了，使用限定词 Where...
11.当我试图把一个 Bug 踢给别人的时候....
12.好像真的没人发现我产品里的 Bug...
13.第一次尝试退出vim
14.当我试图清理几行所谓的旧代码的时候...
15.当我按照 Stack Overflow 上的回帖，解决问题的时候......
16.编译错误：括号不匹配
17.作为一个程序员，最后是拷问灵魂的时刻了：
“你热爱自己的工作吗？”
“...爱！”
“再给你一次机会”
“...唉...”
人艰不拆，求别说。
即将到来的 2018，如何做个合格的程序员？
最近同一部门另一个项目组的一位程序员被"主动离职"了，虽然我未曾与这个程序员共事过，但是听过一两次他的内部分享，感觉技术还是挺厉害的。
后来与一个消息灵通的同事聊天，才知道真正的原因是老大觉得 A 难以沟通，搞得其他程序、QA 都怨声载道。
工作这些年，身边的好多同事来了又走了，主动或被动，这不禁让我思考什么样的程序员算得上合格的程序员。
虽然大家都自称"码农"、"IT 民工"，但我相信，这仅仅是自嘲或者自黑，大多数程序员应该还是认可自己这个职业的。
当然，我算不上一个优秀的程序员，因为我都不曾在开源社区贡献过代码、也不精通白板算法、对技术也不狂热、不 geek。
我的目标是做一个合格的程序员：把本职工作做好，对得起自己的薪水，平衡生活与工作，996 什么的我是难以接受的。
对于程序员而言，技术过关当然是非常重要的，这是硬实力。然而只会技术也是不行的，毕竟大多数的程序员还是要与人打交道，软实力也是不可或缺的。怎样才能算合格，我认为有以下几点：
扎实的基础
计算机领域是一个快速更新换代的领域，每隔一段时间都会有新的语言、框架、思想产生，追随每一个新技术很累。
但仔细想想，事实上并没有那么多新东西。很多新东西只不过是已有技术的封装、或者借鉴的其他领域的技术。
比如缓存数据库 Redis、Memcached，其基本思想不就是操作系统中的缓存吗；分布式存储中的分片与复制集，不就是文件系统中 RAID 的扩展吗？
还有 Google 的 MapReduce 框架，不就是来源于函数式编程语言的 Map Reduce 吗？掌握好计算机基础知识，能够更本质的看待新技术。
善用工具
磨刀不误砍柴工，打造好自己的工具集非常重要。
开发中会用到大量的工具，不管是编辑器、调试工具还是监控工具，大家都喜欢争论哪个 IDE 更好。
然而，这并没有多大意义，关键在于能够熟练的使用自己喜欢的工具，掌握各种快捷键，高度自定义，这样能够大大提高工作效率。
而且对于日常中重复的操作，最好脚本自动化，这里推荐一下 Python，写小工具还是很快的。
另外，强调程序员必备的两个工具，那就是浏览器和 VPN。后者大家都懂的，不多说，主要是有了后者才能发挥浏览器的威力。
浏览器大家天天都在用，但是如何高效的使用，比如在指定网站搜索、通过标题、url 过滤、选择合适的关键字还是值得研究一下。
对于程序员，要使用好浏览器，那还得具备下一个能力：英语。
过得去的英语
不得不承认，在软件创新领域，国内还是落后于国外的，新的技术、一手的资料都是英文的。
当新技术被广泛应用之前，我们在百度搜到翻译要么是 machine translated，要么错误百出。
看翻译的最大问题取决于翻译者本身的水平，即使翻译水平都很高，但同一个单词往往有不同的翻译，导致看文章的时候会有困惑，最好还是直接看英文原文。
大多数原文，除去专业词汇、还是比较好理解的，而且，我发现很多牛逼的项目，都有非常通俗易懂的文档。
良好的编码习惯
代码是写给机器执行的，同时也是给人阅读与维护的。维护者可能是别人、也可能是几个月后的样子。良好的代码规范，必要的、清晰的注释可以让自己少被问候祖宗十八代。
对于代码风格，网上争议也很多，最重要的是保持项目内的统一。做为技术负责人，一定要在项目开启之初就定好规范，当大量代码被堆出来之后就很难统一了，然后做好新人的 review。
保持学习
程序员这个职业，相比其他职业，可能还是要年轻许多。特别是在国内，最老的一批程序员好多都转管理了，再过 10 年 20 年，我们会怎么样呢，没人知道。
前段时间华为 35 岁程序员被离职的事情，还有最近传遍朋友圈的中兴 42 岁程序员坠楼身亡的事（痛心！中兴42岁程序员跳楼身亡，是什么把他逼上了绝路？），都给我们敲响了警钟，悲哀之余，只有尽力学习了，拼不过体力就拼能力与经验吧。
学习这个事情说起来就复杂了，我觉得两点很重要：基础、学以致用。
独立思考
合格的程序员解决的是问题，而不是实现某个解决方案。产品经理（特别是知道一点技术的产品经理）的某个需求可能只是某个问题的解决方案，他认为这个方法可以解决他的问题，于是把解决方案当成了需求，而不是真正的问题。
程序员应该主动沟通，多问几个为什么，了解真正的问题，也许能有更好的解决方案。
之前就有这么个例子，给到的需求：为每一个用户（用户有唯一的 id 标示）生成一个唯一的邀请码，同时也要为未来一段时间可能增加的用户预生成邀请码，保存到数据库。
而真正的需求是老用户分享自己的邀请码，如果新用户使用了该邀请码，则老用户获得相应奖励。我提出的方案很简单，直接用户的唯一 id 生成可逆的邀请码，这样就根本无需数据库存储。
产品经理经常改需求这是程序员最头疼的事情，作为程序员应该也站在 PM 的角度思考，帮助 PM 分析出本质的需求，这也许可以减少需求的变更。
当然，前提是得干一行爱一行，需要对业务有一定的了解。
先思考后行动
写代码的时候先想清楚了再下笔，而不是先写出一堆代码，然后在开始修 Bug。
修改 Bug 的时候，多看看上下文，搞明白为什么出 Bug，修改这个 Bug 可能带来的影响，然后再修改。
反面教材有两种：
- 随便改改就把代码改好了，但自己心里并不清楚为什么这样修改就修好了，撞运气，也许还有其他同样的 Bug 也发现不了。
- 头痛医头脚痛医脚，不仔细评估修改的影响，这样往往会引入新的问题。
程序员成长的一个办法就是修 Bug，修别人用不了的 Bug，但前提是搞清楚 Bug 的缘由，这样才能避免类似的错误，有所收获。
顺畅沟通
顺畅沟通不是巧如舌簧、也不是忽悠达人，需要的只是耐心倾听，然后清晰表达自己的意见。
现在的软件开发，已经不再是单打独斗的年代，大多数的软件、产品都需要多人、多部门的协作。而交流、沟通是非常耗时耗力的。
沟通之前，先想好目标，组织好语言，尽量不要发散、不要跑题，对事不对人。对于重要的事情，保留沟通记录，最好有邮件，免得说不清。
沟通是门复杂的艺术，最基本是听明白、说清楚。
管理好自己的暴脾气
作为一个程序员，要被 PM 怼、要被交互怼、要被 QA 怼，再变态的需求都可能有，QA 给你提的 Bug 可能也不属于你。而且，还有猪一样的队友（自己在别人眼里何尝不是这样呢）和下属。
不管谁是谁非，发脾气、吵架都一点用没有，吵完还是得解决问题。calm down，有怒火也得等个几秒再发作，也许这几秒理智思考一下，就能解决问题。
负责任
能力（技术能力）与责任心谁更重要呢，都重要。如果一个新人有培养的潜力，那么责任心就更重要。
两个人，第一个技术能力很强，但责任心很差，对项目的事情也不上心；第二个能力差些，但责任心强，是自己的问题一定负责到底，即使自己不能解决也能主动寻求帮助。
我觉得前者对项目的危害更大，特别是项目紧要时期，因为能力强的人一般负责的是比较复杂、困难的功能，别人上手也需要时间，这个时候如果摞担子，Bug 也不修，那么就很为难了。
不负责任的典型表现就是扯皮、甩锅：这不是我的 Bug、不关我的事。
有协作的地方更容易出现问题，比如前端与后端、各个部门之间。如果不清楚到底是谁的问题，不妨主动一点，帮助排查。
不要总是说不会
作为程序员，总有一些工作是以前没有做过的，也许来自产品人员的需求，也许来自项目自发的优化。
我见过一些程序员，在面临未知的问题、挑战时，总是习惯于说：不会、没办法、不可能，这样的程序员就算不上合格的程序员。
事实上，这样的程序员是给自己过早地留好退路，事实上问题可能并没有想象的那么困难，也许经过一番探索就能解决。
如果习惯于对未知说不，那么在别人看来就是能力不行，影响个人形象与声誉，而且总是待在自己的舒适区也不利于自我成长。
当然，也不是说要盲目自信，急于拍胸脯保证一定能解决，这样往往是坑自己。
所以，面对新的需求，谨慎对待，既不轻易否决也不随意承诺，而是再理清需求先去研究一下，评估是否能完成，需要的资源与时间。
暂时就想到这么多，与君共勉。Relax！准备好迎接你的 2018 吧。
