编程的智慧读后感

本周的摩拜前端周刊总编 yueyue 提了一个任务：每一个人交一篇读后感。

本读后感原文来自：https://www.jianshu.com/p/7645a5ea7f46

内容较长，感谢作者，看了几遍，确不乏一些思考的内容

1、提高编程水平最有效的办法是什么？

面对这个还算普通的问题，你会如何回答呢？

其实没有最有效的，大部分都因人而异，只是看多了成功的人，会发现一些差不多的点。

个人觉得分阶段把，按入行年限来看

初级阶段：

以理论 + 实践为基础，通过一些基础类库的反复应用来熟悉前端生态的整个流程，养成一些好习惯：比如记录一些自己遇到的问题

选对好的团队和好的导师，少走弯路，多写代码

中级阶段：

深度和广度的拿捏开始阶段：找到自己的优势领域，不断去挖掘，带有比较性地去看到问题，有一定的抽象能力和意识，学会去看看别人的优势编程习惯，开始封装部分有共性的东西

主动性和兴趣是支撑自我优势的决定性因素，不同技术方向的锻炼机会也很重要

高级阶段：

深度和广度的拿捏修炼阶段，拥有了多年经验之后，更多地吸收梯队化团队带来的差异性，积极主动地承担一些技术攻关的项目，对代码的细节设计反复思考，能够带动团队其他的同学一起思考和碰撞，制定研发一些利于团队效率的工具和规范，参与设计组件库等

经验是优势其实也是劣势，如何有自己独有的技术调性，敢于去尝试和沉淀

资深阶段：

保持勤奋的学习热情，善于发现业务中的技术生产力，有更多统筹的架构意识，学会关注行业的动态，推动技术升级，带动团队的技术平均水平

站的位置越高，越愿意拥抱技术变化带来的思考，有危机意识

2、原文开始的阶段也提到了：

“看一个作家的水平，不是看他发表了多少文字，而要看他的废纸篓里扔掉了多少。”

对于初中级的同学，其实难免会出现冗余、重复的代码，加上很多业务的压力，在早期大部分的人都是以结果导向为主

但是：

你有没有一个负责任的导师

你有没有一个关注 code review 的团队

你有没有一个注重 lint 的团队开发工具

当然，当你自己有一些调性之后，你自己就会主动地去重构代码。

3、再谈如何定义：可读的代码和简单直观的代码？

有比较才有伤害，或者说：贫穷限制了我的想象力。

原文作者也提到了一些 Unix 命令中的巧妙写法，包含 && 和 特性。

其实做前端久了，你发现慢慢地，同其他语言的不断借鉴，前端也工程化、服务化、组件化，有设计模式、架构设计等等。

前面也讲了，我们通过 lint 来约束团队编码规范、减少低级错误的产生。通过定义的 code review 以及第三方开源案例和类库的学习研究，确定更好的编码方式和设计模式。

当然更多也是 ES6 等以及 ts 的不断发展，源代码相对而言越来越简洁：

你的团队是不是还有一些老项目没有应用 es 等

code review 是否真的认真负责地落地下去

分享交流的习惯是否落到了每一个人

团队的一致性和差异性是否得到最大化

4、最后讲无懈可击的代码

很多人会想到兼容性或者适配，当然不只是如此。

最近我们上了一个摩币游戏，由于游戏有一定的规则和复杂性，所以总会有一两个 bad case 出现。

一般的做法：case by case 地去复现这些奇奇怪怪的操作带来的 bug，然后hotfix。

于是，我们开始反思：

1、不管任何人由于任何方式进入到了结束页面，如果没有拿到他的登陆信息，就一律跳转到首页

2、不管谁分享谁(谁看谁的分享，谁在谁的分享页面右上角点击二次分享)，如果进来打开链接的用户没有登陆过，是否可以理解为它就是第一页，点击按钮，弹窗登陆

当然只是一个举例，对于代码本身的考量其实更多，包含返回值类型的不确定、默认值、异常情况、弱网的处理等等

最近我们在做国内国外性能优化的时候，发现慢查询的业务页面有的甚至有 8-12s 的节点访问，所以

我们优化了 dns、加入了更多 ssr 项目的投入和落地，增加了体验性的占位和骨架图，等等

闲扯一篇而已，恩，去看书了，各位周末快乐

顺带问一下 yue 老板，这篇能得奶茶吗？