程序员的自我修养

互联网的技术大佬们，都具备独当一面的能力，在关键的卡脖子时刻，总是能够站出来，优雅的解决掉问题，然后清风拂袖，深藏功与名，只留下一个牛X的传说给后辈们口口相传。

话骚，理不糙，跟着张工不挨刀。

前言

程序员的自我修养三要素:

• 写的代码，机器能读懂。
• 写的代码，自己能读懂。
• 写的代码，他人能读懂。

代码它是一个讲道理的东西，0是0，1是1，它不会欺骗你，也不会恃强凌弱，更不会搞一言堂。

优良的编码风格能够体现出自身的技术能力，亦可以在留给后来人阅读时，让其感受到高年级同学传帮带的技术文化。

大家平时都是抬头 PRD，低头写代码，很少有时间静心气闲地交流一下业务流程、逻辑、未来扩展的方向，导致在漫长的开发过程中，出现堆积问题。

今天我们先把提升技术质量、促进成长、培养技术情怀这些口号放在一边，来聊聊最近的切身体会。

代码写得好，写得不好的都是一本书，好的代码见贤思齐，差的代码见不贤而内自省也。总之，编码是一种修行，也是一种经验的积累。

苦涩的是每当看到惨不忍堵的代码，心里说：卧槽，牛X！看到优雅的代码，心里也说：卧槽，牛X！

时间紧，任务重，代码来不及规划

我们总是会为的丑代码找个华丽的借口，时间紧，任务重，来不及规划，但却总花着大把的时间焦头烂额地处理故障和投诉。

业务跑得快，代码写得快，可写出来的是一堆没有营养，甚至是有毒的代码，终究是要出现问题的。出来混，迟早是要还的，饮鸩止渴终究不是解决问题的方式，最终只会使自己深受其害。

想让业务跑得快的前提，得保证双腿是健康，好的设计就相当于一名医生，关键时刻，不只渡己还能救人，要不然今天冲刺 100 米，明天就嗝屁了，这样的设计在未来长远的发展中肯定是弊大于利的。

众生疾苦，唯有自渡

代码是讲道理的，靠烧香来保佑不出问题代码，保住的平安往往也是暂时的。

我们要将代码构建成坚固导弹防御系统，一旦受到攻击，系统将自动的打开容灾，削峰，限流并发挥其真实的价值。

在墨菲定律中概率大于零的事，均可能发生。我们经常会抱着侥幸的心理，偷工减料，觉得只要在场景和逻辑上没有问题就行，但是夜路走多了，早晚会遇见鬼的。

所以在开发的过程中我们需要做到读懂它，用好它，写好它。

每一行代码的存在是有意义的

更加严格地说，每一个字符都有它存在的意义。

在开发的过程中要学会思考，思考代码存在的意义，它是不是可有可无的，它是否能够抽离与复用，我们有没有考虑过 JVM 的感受，凭白无故地要多编译这些字节码，然后栈进栈出的忙活一阵子，产生耗时，最后告诉它的劳动是没有任何价值的，这样得代码行就是没有意义的。

代码行数

代码行数不是评判工作的唯一标准，并非鼓励代码行数多，工作负荷大，工作饱和。

在长篇阔论的代码中，我们一定要注意重复逻辑的复用，否则在未来修改的过程中出现遗漏就会造成程序BUG。

5行能搞定的代码，就不要写10行，很多大佬经常鼓励大家多些代码，并不是鼓励代码行数多，而是提倡大家去写好代码，写优质的代码，优质的代码一定是少即是多的。

代码的实现，不要像鲁迅先生说的一样：懒婆娘的裹脚布又臭又长。

单测的重要性

秉承对自己负责，对他人负责，不要做个渣员的态度。

要认真的做单元测试，在做单元测试时要覆盖业务，做出临界值的测试，俗话说的好，单测写得好，BUG 肯定少。

通过单测，能够捕捉到程序中日志的不足，和补充异常的处理机制，有助于日后线上问题的排查，所有单元测试显得尤为重要。

命名规范

人如其名，好的名字伴随一生。

不要张冠李戴，一个漂亮的女孩子如果取名叫李狗蛋，听其名的第一印象就生生地给扭曲了。

命名太混淆，容易给人带偏，一些英语不好的仁兄，通过翻译软件，搞了个英文名称，找个大家都不认识的英文单词，如果在线翻译准确的翻译出来还好，如果表意错误，那可是真要命了。

注释是电影的旁白

不写代码注释的人，相当于没穿内裤游泳，大潮退去，沙滩上裸奔的人就是你。

我们要在合适的契机出现，在复杂的业务场景中，做精简的描述，描述业务场景，实现逻辑。

描述要清晰，是对业务的描述，而不是对代码的描述。

通篇的函数式编程

如果一个 stream 后边的调用超过 5行，我觉得你是为了炫技，因为别人不敢改这段代码，体现出来你的不可替代性。

复杂的函数式编程的方式，就像让人在憋气，超过能承受的换气时间，就会有缺氧的感觉。

函数式编程调试非常困，此难，难于上青天。

结语

“道可道，非常道；名可名，非常名。”

在职业生涯中不断努力完善自己的行为，提高自己的修养和境界，只有经过长期的修行，我们才能获得真正的智慧和解脱。

我们需要不断地学习、实践和修炼，才能真正进入编程的世界，从知道到理解，从理解到运用，从运用到升华，做好每个阶段的自己。