程序员的自我修养

转载一篇文章 ：程序员的自我修养

写在前面

在学校时候，经常看到这样的一句话：‘昨夜西风凋碧树，独上高楼，望尽天涯路’，此第一境也；‘衣带渐宽终不悔，为伊消得人憔悴，’此第二境也；‘众里寻他千百度，蓦然回首，那人却在灯火阑珊处’，此第三境也。王国维说的，道理大家都懂。
有一天，看到了另外一个段子：“程序员的职业生涯，有四个境界:

• 第一境界：
  《C程序设计语言》
  《Java编程思想》
  《C++Primer》
• 第二境界：
  《教你怎么不生气》
  《心经》
  《老子》
  《沉默的愤怒》
• 第三境界：
  《颈椎病康复指南》
  《腰椎间盘突出日常护理》
  《心脏病的预防与防治》
  《强迫症的自我恢复》
  《精神病症状学》
• 第四阶段：
  《活着》

看看你现在处在哪个境界？
借用上面这个段子，想说的一件事是：程序员成长，是从学习专业知识，到通过解决问题积累经验，慢慢走向规范自己职业态度，培养职业习惯的过程。

image.png

感觉自己总是很忙，想想又没有做什么

那么，第一步我们是在积累我们的知识和经验。
在我刚开始工作的时候，一直都是充满了冒险精神的。刚学会一门语言时候的兴奋，尝试用自己会的东西去做一些有趣的尝试，进而发现新的点。这个时候，有趣是多过职责的。
现在，很多时候都很忙，已经失去了当时的那种新鲜的感觉，改不完的问题加上源源不断的需求，每天很充实。可是回头一想，却发现自己也想不清楚今天到底做了什么，这个时候，这种充实就变的像阳光下的泡沫一样了.
从根本上讲，我们更习惯看得到的东西，所以当我们做了很多事，却看不到它真的带来了什么，导致我们缺少一种目标达成感。

image.png

首先，我们需要为设立清晰的目标，哪怕一天，长到数年。
在目标设定中，SMART原则被普遍运用。

• S（Specific）：目标必须是具体的，要对标特定的工作指标，不能笼统；
• M（Measurable）：目标必须是可衡量的，衡量的指标是数量化或者行为化的，验证这些指标的数据或者信息是可以获取的；
• A（Attainable）：目标必须是可实现的，在付出努力的情况下可以实现；
• R（Relevant）：与其他目标有一定的相关性
• T（Time-bound）：目标必须有明确的截止期限 结合这个原则，为我们每天的努力设置一个可以达成的终点。

与此同时，我们每天需要花费几分钟来记下做了什么。有三个作用：一是方便回顾整理；二是看到自己完成的东西会有一种成就感，激励你前行。三是方便写周报。
说到记录，推荐一个笔记本工具–OneNote。虽然这款笔记本工具配合Surface使用才能完全发挥它的作用；对于程序员来说，它能带给我们的是任何时候以任何方式来记录产生的想法。最后，好的程序员都应该有一个自己的代码库。里面可能是你最常用的工具类，也可能是使用某个框架的样例。最重要的时时去更新，所谓骐骥一跃，不能十步；驽马十驾，功在不舍。

BUG是自己的，即使是别人写的

经常有这样一个场景：开发小A优化了一个功能，上线后出了一个线上BUG，经过排查是一个遗留问题。事后分析会，小A强调这是遗留的BUG，不属于自己的责任。

image.png

事实上，小A没有意识到，他离成为一个专家又远了一步；当问题出现时，我们最需要做的两件事：一是最快速的解决问题；二是总结分析问题出现的原因，为以后预防提供改进措施。
从团队来讲，不分彼此的保证上线的质量是培养我们团队精神的一个好的方式。大家一起齐心去解决问题，互相理解和支持，互相形成正向力量，对大家的成长都作用巨大。而互相推诿，无疑会深深的伤害我们的团队。
从个人成长来讲，积极主动的去发现问题，解决问题，才能让自己获得快速的成长。这也是我们将理论上的专业知识转变为宝贵经验的重要方式。见得多了，才能会的多，才能少犯错。
说到底，这是一个态度的问题。一直有个说法：“爱笑的人运气都不会太差”，其实我更相信：“积极主动的人运气都比较好”。因为第一个说法其实也是看颜值的，有时候太爱笑会被人当成二傻子。但是积极主动并不会，而且很多时候这种态度会带动身边的人也变得积极起来。

我们的工作是解决问题，而不是制造问题

以前的公司特别强调一个原则：“不要成为问题的制造者，而是终结者”。这一点深深的影响着我的工作方式。
首先，我们不应该成为问题的源头，这是我们的职业准则； 遇到问题，很多人有一种鸵鸟心态：

image.png

把头埋进沙子里，来逃避自己面临的问题和需要承受的痛苦，问题解决不了，就拖拖拖，往后拖，就当没看见，兴许到时神迹出现问题不见了呢。这都是自欺欺人。虽然鸵鸟策略会让程序员暂时避免了痛苦，但却不得不去承受另外两种更深邃的痛苦：看不到希望的交付期和没有尽头的维护。
这样并不会让你真的收获什么，也不会让你下一次碰到同样问题的时候给出解决方案。比起逃避，积极的面对，或许问题没有你想的那么难。
学会处理问题的思路，在我看来比了解问题本身更重要。
首先，需要深入的去分析，去了解问题的现状和影响，结合知识去发现原因；
其次，如果没有很容易的找到原因，那么我们可能需要一些工具的帮助，平时多积累一些工具的使用方法，有可能一个命令能让你少苦恼半天；
然后，如果问题到这里还解决不掉，可能就已经超出了我们的能力范围了，这个时候继续自己一个人去想只会让问题越拖越久，及时的求助，也许会让我们的进展突飞猛进，当然，前提是寻找正确的人求助，你去问一个前端开发为什么内存为什么溢出很显然不会得到答案；
最后，我们做了这些还是解决不掉问题的时候，快速的抛出问题，向上反馈是最好的方案，毕竟你的老大拿的比你多，工作比你久，解决问题的经验也比你丰富的多，更重要的是可以及时止损。
再说一点对付那些百思不得其解的问题：先忘掉它，打个盹。

image.png

你不解决问题，你就会成为问题。作为程序员，这是我们一定要牢记的。面对问题的泥沼，不可能跃过，我们的选择，只能是穿越。

捅死产品经理？不如像产品经理一样思考？

程序员和产品经理相爱相杀由来已久，矛盾点其实只有一句话：“这个需求要改了”。
做专业技术出身的人，往往会养成一种思维习惯，看问题的角度也会形成惯性，我们把这种思维习惯叫做工程师思维。而产品思维是产品经理应该具备的思维模式。

image.png

工程师思维关注技术至上，技术水平代表他的实力，只要有可能，他倾向于在产品中使用先进、流行的技术，因为掌握先进主流的技术可以提高他的身价。
产品思维关注的是，这技术能给用户带来什么价值？有什么商业价值？ 这二者并没有对错之分。
所以，当我们一次次抱怨产品该需求时候，我们更应该想的是：我有没有理解产品经理这么修改的意义，这样的改动给我们带来的是什么？这要求我们更经常的去用产品思维思考问题，而不是局限于代码层面。
当然，产品的改动并不都是有意义的，如果我们能够从产品的角度去发现这种不合理，那我们的反驳会更有力度，最终被说服的人也许就是产品，而不是自己。
在这样思考的同时，也会让我们更深入的理解我们的业务，进而从业务角度来反向推动我们对技术的理解，这种得益是双向的。

做事更细心？还不如给自己一些规范

相信大家都有这样的时候，一个比较复杂的功能，自己辛辛苦苦的码代码，百般小心的测试，最后却因为一个很小的疏忽功亏一篑。
是我们不够认真吗？还是我们不够仔细？当你这样问自己的时候，其实你还是没有明白问题出在哪里。
可能我们首先想到的是态度问题，因为态度上不够重视，所以才不够小心，导致了问题的发生。
事实上，我们的脑力毕竟是有限的，面对复杂的场景百密也终有一疏，而作为程序员，这一疏却是我们不能接受的。
与其一再的逼自己更小心一点，不如让自己更严格的执行我们的规范。
这里是一些我们经常提到的规范：

image.png

用看的见的规范来约束自己的行为，是一种更容易达成的方式，也是一种更有力的保证。

写在最后

要想质变与提升，必须有目的地停下码代码!
只写代码，不走心，那是万万不行的。不走心的程序员很多，干多少年了水平还和初干时差不多，十年如一日。走心就不一样，走心一日如十年。
我们要周期性的回顾以前，看看以前的代码，看看哪些可以改善，有多少种改善思路……这样就能看出以前的自己与现在的自己这两者之间的差距。如果你觉得自己以前的代码优化空间很大，那恭喜你，你绝对提升了不少。
回顾以前，别忘了看看现在。我们还要经常做一下自检，这样就会对自己的能力边界有所了解，知道自己知道什么，也知道自己不知道什么，更重要的是，你会发现自己能把什么东西学好用好，还能发现自己为什么可以把这些东西学好，那样你就可以找到自己擅长的方向，做得更好。
回顾以前，看清了现在，还要想想将来。在技术上，我要在哪些方向继续前行深入挖掘？这点非常重要。我们伫立现在，回首过去，仰望未来，这是上山的姿势。
有人说到了山顶就只剩下山的路了……这到是实话，不过，顾城有首诗《避免》可以看看:

你说
你不爱种花
因为害怕看见花一片片的凋落
所以
为了避免一切的结束
你拒绝了所有的开始

不忘初心，方得始终！