为什么要书写优美的代码

优秀的代码源于我们对细节的热爱和执着，每一行代码，都体现着程序员的修为，思考问题的深度，甚至是处理问题的习惯和态度，代码是我们交流和处世的名片。作为一个技术类的工种，我们没有理由不去思考如何写出优秀让人惊叹的代码，写好我们自己的名片。

优秀的代码是投入少，收益大，投资回报高。最适合当前环境的代码，才是最优秀的代码。我们的产出必须大幅度大于公司对我们的投入，否则就有随时被扫地出门的风险，必须在单位时间内创造更多的价值，否则真的是没有功劳，只有徒劳。

不要当我写这行代码的时候只有我和上帝知道这行代码的意思，一年后，只有上帝知道。这就很难受了

程序猿的存在不是为了写代码，而是为了解决现实问题，实现现实价值，思维能力和行为能力很重要。

化繁为简，通俗易懂的代码，才是我们追求的好代码，编写代码的过程其实是简单到复杂再到简单。复杂是代码质量的敌人。 越复杂的代码，越容易出现问题，并且由于复杂性，我们很难发现这些隐藏的问题。在写代码的时候一定要把逻辑理清楚，否则到后面越改越乱。

代码要注意什么

写一篇文章要层次清楚，段落分明，写代码也是这样，杂志排版，要布局合理阅读舒畅，代码的编排也要这样

开发需求时间紧，哪有时间整理代码，确实是这样的，干净整洁的代码带给我们的远远不止格式上的赏心悦目，他更能提高我们编程速度与效率，因为代码的层次结构，格式部署，是我们对自己思维的整理，也是我们思考逻辑的展现。整理代码其实就是给代码分块，又臭又长的代码会误导我们，不好理解，不好阅读。

整理代码的时候，目标要单一，一个代码块只能有一个目标，我曾在项目代码里面犯过这个问题，领导指出之后进行重新整合了。代码块数量要适当，基础代码块最好不要超过25行，太长太复杂不好阅读。代码块是一个完整的信息块。一个代码块要表达一个相对完整的 意思，不能一个意思没说完就分块了，就像话说了半句一样;

注释就是对代码的解释。注释不需要运行，它是用来提高代码的可读性和可维护性的。不好的注释会使代码变得更糟糕，使人更抓狂。我们有时候会过度依赖解释，从而放弃了潜在的替代方案，比如更准确的命名，更清晰的结 构，更顺畅的逻辑等等。 注释，被我们用成万能的狗皮膏药，有时会让代码更糟糕。

及时维护

如果api已经被废弃，随着时间的推移她的实现可能会存在各种各样的问题，包括严重的安全问题，需要承担这些风险也很多，我们应该尽早的废弃该接口

很多api的设计有检查参数有效性的方法，如果没有参数通过检验，就会报错，影响代码的正常执行，所以建议给默认参数，es6的语法是支持的

对于软件开发者来说，组织代码是一项基本技能，也是我们需要养成的好习惯。组织代码有许多不同的习惯和策略，我们要学会辨别这些策略中哪些是有效的，哪些是有害的

和其他技能一样，最快的提升方法是仔细思考一下为什么我们要做出这样的选择，而不是其他的。知其然远远不够，还要知其所以然。

提高代码质量

提高协作效率的最高技巧不是提高沟通技巧，而是要减少沟通的数量，提高沟通的质量，尤其是要减少数量。如果你参加了工作，没完没了的会议，没完没了的文案，都会加深你对这条原则的理解。软件的设计也是这样，外部接口，要少、要小、要描述清楚。

代码的性能并不是可以多块 地进行加减乘除，而是如何管理内存、磁盘、网络、内核等计算机资源， 越早考虑性能问题，我们需要支付的成本就越小，带来的价值就越大

有过面试经验的小伙伴，你们有没有注意到，正确和有效地编码是面试官考察的两个重点? 招聘广告可不会提到，程序员要能够编写正确的代码和有效的代码。但是一些大的企业，会考察算法，其中一条重要的评判标准就是算法够不够快。他们可能声称算法考察的是一个人的基本功，是他的聪明程度。但是如果算法设计不够快，主考官就会认为我们基本功不够扎 实、不够聪明。 你看，算法快慢大多只是见识问题，但很多时候，会被迫和智商联系起 来。这样做既无理，也无聊，但是我们也没有办法逃避开来，主考官可能也没有更好的办法 筛选出更好的人才。

我们要养成一个习惯，看到声明的变量，就要琢磨这个变量能不能声明成不可变的量。这样就可以避免很多不必要的线程同步，让代码的效率更高，接口更容易使用。在阻塞的这段时间里，做的事情越少，阻塞时间一般就会越短

放慢脚本慢慢来

不知道你有没有这样的情况，学习技术时，我们对基本概念熟视无睹，只想将宝剑尽快握在手，哪管宝剑何时该挥出的教导。学会技术后，基本概念就会回来找我们算旧账，出错一次剑，就记一笔账。账本慢慢变厚的过程，也是我们向基本概念靠拢的过程。当我们掌握了最基本的概念后，开始慢慢还账，账本再越变越薄。我现在就是在还账阶段

第一个习惯是，要尽早地考虑性能问题。如果你最早接触的是需求制定，就从需求开始考虑;如果你最早接触的是软件架构，就从架构层面开始考虑;如果你最早接触的是软件设计，就从软件设计开始考虑;如果你最早接触到的是代码，代码也有很多性能问题可以考 虑。总之，要主动、尽早地考虑效率问题

第二个习惯是，性能的实践经验需要日积月累。性能的实践经验和技术丰富繁杂，大到产品蓝图，小到每一行代码，中间还有软件的架构、选型、部署等诸多环节，都有很多的最佳实践可以积累。而且这些最佳实践，也会随着时间的推移发生变化，比如说会出现更好的技术方案，曾经的技术满足不了新需求等。所以，我们也要随时更新我们的储备，摒弃过时的经验

如何面对技术？

热爱研究技术当然是每一个技术人员需要具备的品质，阅读源码也是技术人员必须具备的一种能力。更倾向于带着问题去研究技术，用技术手段去解决业务的痛点，技术是解决问题的工具，而不是结果或者目的。

不断挑战自己，拓展边界 很多时候人容易陷入舒适区，更愿意守着自己的领域做着自己特别擅长的事情。可能就是每天不断地完成不同需求的页面开发，然而实际上只是大量的重复劳动，并没有那么多的成长。多了解其他人在做什么，怎么做，遇到困难的技术场景就去挑战它而不是退缩。对于大量的重复劳动去更多的思考共性，怎么样才能把自己从这些事情中解放出来，有更多的时间去解决更多业务上的痛点以及技术难点。

技术是工具，也是赋能商业的手段，而不是目的 很多刚毕业的技术同学会陷入一种误区，认为把某个框架或者某些技术的实现细节或者实现原理吃透就能成长为技术大牛，或者是为了用某个技术或者某个框架而去做技术选型或者凭空实现一些很虚幻实际上并不能产生价值的功能。热爱研究技术当然是每一个技术人员需要具备的品质，阅读源码也是技术人员必须具备的一种能力。但是笔者更倾向于带着问题去研究技术，用技术手段去解决业务的痛点，技术是解决问题的工具，而不是结果或者目的。

如何汇报问题？

承认问题、分析原因、给出解决方案

尤其是在互联网行业，码农、产品经理、运营等岗位的领导者，他们往往能很好地跨部门沟通合作，向全公司展示业务成果。面对问题和成绩，都能够用得体的表达让老板信服。

会说话，也是职场人关键的自我修养。只会埋头钻研技能，就会丧失很多机会。

最让人难受的是，其实这些原因和解决方案我也想得到！但为什么，我就不能立马说上来呢？

不得不承认，嘴上功夫好的职场贱人，就是比闷头做事的自己更吃香！明明只做了两三件事，说起来像是做了十件事！

问题-原因-解决方案

第一个看到问题的人，就要立刻着手解决，不要拖延。

太多的人浪费了太多时间，为那些已经做出的决定。 投资回报率。把这个概念映射到学习上，就是，投入大量的时间，从源码中获得知识的回报。

好的学习过程，就是要反复提问。经过自己的思考，确实短时间内想不通，那提问就是最正确的选择。提问不会证明任何东西，证明不了你学习没认真，也证明不了你学习能力弱，更证明不了你就很菜。这中间所有的障碍，都只是我们自己给自己设置的限制而已。

问题无高低，问道有先后。

我们需要阅读源码吗？

什么时候看源码：我认为你至少已经对这个开源项目的使用已经很熟练了，并且对它的设计思想，用来解决什么问题等等都比较清楚的时候，为了进一步对它深入学习，就可以来看它的源码实现了。

以 Vue.js 为例，我们知道了它的核心思想是数据驱动 + 组件化，那么我们就可以问自己，Vue 模板的数据是如何渲染到 DOM 上的，数据更新后模板是如何重新渲染的，组件化是如何实现的，模板到 render 函数如何编译的等等。那么每一个问题都可以值得我们针对性地去学习源码。问题驱动的方式和坑驱动不同的地方在于这个学习过程是主动的，自驱的，学到的东西会更加系统和全面；而坑驱动往往都会满足于解决某个问题就停下了，学习会比较局限。

如何建立知识体系

建立知识架构

文法 词法。 编译原理的划分 语法 词法中有各种直接量、关键字、运算符，语法和语义则是表达式、语 句、函数、对象、模块 语义

运行时 类型 数据结构 执行过程 算法 类型则包含了对象、数字、字符串等……

学习的过程，实际上就是知识架构不断进化的过程，通过知识架构的自然延伸，我们可以更轻松地记忆一些原本难以记住的点，还可以发现被忽视的知识盲点

有一些知识，背后有一个很大的体系，你要试着建立自己的知识架构，除此之外，还要学会追本溯源，找到知识的源头

送给自己的一句话

有一种优秀是在看到自己的脆弱、在明知未来的结果后仍能勇敢的往前走。在面对人生逆境之时，接纳现状并且展现了最好的自己。一个人最终会持续的去做一件事，绝大原因是来自内心深处的感同身受，而这种感同身受便是使命。