前言
将之前的团队内分享的内容整理了一下，分享给更多人，希望对你有帮助。这次分享和以往的分享有一点点不一样， 没有希望分享那么严肃，纯属一些工作中常用经验分享和近阶段学习成果拿出来和大家一起探讨。所以大家如果有想法和意见都可以直接提出来，一起讨论。 依赖分享内容来自于实践成果总结和学习成果总结。
目录
- 编码规范
- 代码整洁
- 代码重构
编码规范
现在前端绝大部分项目已经引入 eslint 或 tslint，集成相当完善相关代码规范。 所以这里我并不想讲太多代码规范问题。主要想聊一聊命名问题。
之前网络上流行着这么一段话：
There are only two hard things in Computer Science: cache invalidation and naming things -Phil Karlton
计算机科学中只有两个难点：缓存失效和命名
命名的问题，一直以来是困扰着所有程序员。例如我们的公共库对外暴露的接口，如果已经大量的人使用，事后想要变更名称已经是相当困难。所以怎样才能在一开始就预测一个名字能否在未来的环境存活下来，是非常困难的。
命名的作用
命名的主要作用是便于理解，其次是规范、简单、美观、方便重构。不过命名是有生命周期的，随着业务的不断迭代，原来的命名也会随之失去意义。这种情况就不得不对其重命名。
命名的方法
-
如果真的没有觉得合适的名称，可以
试着先写一段注释，解释当前变量/方法是干什么用的，然后再将注释的内容精简成变量名/方法名。这也是我自己长期以来使用过最多方法。 -
方法/变量名精简而语义清晰当然是最好的，不过千万不要一味追求精简，语义大于精简。即便过长也不影响。
例如：有个方法把状态改为成功 setStatusToSuccess >> toSuccess >> toSucc >> gaibianzhuangtai
下面是 Sun Microsystems 设置的命名约定示例
命名的原则
总结：看懂 > 复用 > 共享
代码整洁
整洁=不混乱
一个没有任何代码的项目，开发时间最短，代码速度最快。不过随着速度变快，一切都变得混乱。所以程序员走的很慢。整洁的代码会使你的时间井井有条，只要你继续保持着对代码的整洁。
走得快的唯一方法是走得好
我们走的很慢，是因为我们制造了混乱，那么为什么我们要制造混乱，是什么驱使我们制造混乱？是走得快的愿望！这个愿望就是我们急切想在短的时间内做成太多事，不停地coding 。你的每一步都很小心，check 着代码，直到成功。 事实上，能让代码运行，功能正常，你只完成了一半的工作，而另一半的工作是如何让你的代码整洁。所以你要花大量的时间做这件事，投入到这件事。
整洁的代码的不同理解
- 整洁代码，是做好一件事。
- 整洁的代码是简单和直接的。
- 整洁的代码就像是在读散文。
- 整洁的代码它就像在关心你。
函数
-
第一原则：
足够小,什么才是足够小，有一个方法就是函数的内容能完全显示在你的屏幕内。另一个维度就是一个函数只做一件事。 -
只做一件事:
只做一件事，就是你没办法从这个函数中提炼出另一个函数。如果可以提炼出另一个函数，证明这个函数不止在做一件事。随之而来的海量函数，并不会让你混乱，因为它们都有自己的名字。你可以通过它们的名称搜索和使用它。 -
函数的参数最好不要超过3个: 超过后理解起来会变得困难。
-
尽量不要将一个Boolean 类型传入一个函数中: 因为这个Boolean 类型一定对应着一个if 语句有两个分支。一个分支表示一个功能，所以为什么不拆成两个功能呢。
可阅读性
当你一行一行阅读代码，并不希望突然出现一个变量在顶端，你不得不回去看它是干什么的，有什么用，这是不礼貌的，你被打断了。适当的空行，就好像中文中的逗号和句号，留给阅读者喘气的机会。
小结
整洁的代码是：能够在最短的时间内让别人知道是在干什么！
代码重构
困惑
可能大家都很困惑，到底重构是在干什么，什么才是有的重构。有没有一个指标去检验重构的结果？
简单总结重构的结果是：方便维护，方便扩展。符合新业务，符合未来的业务。
不敢重构
为什么大多数开发人员不敢不断修改他的代码？
因为他害怕会改坏代码!
为什么会有这样的担心呢？
他们没有做过测试。更不清楚各个模块间的依赖关系。
重构的时机和可能会遇到的问题
这里我想重点说明的是重构的时机真的是非常重要！小的改动还好，大的重构可能会导致你的工作时间失衡，严重影响开发进度。别搞得自己加班加点完成重构，这会是一个错误，加班赶出来的新重构的代码将没有意义。所以重构的时机选择至关重要。
重构的前提：一定伴随着新的需求(问题修复/功能改动)！最好是新的大版本迭代
重构前一般我会问自己这几个问题：
- 重构的这块内容是不是跟随着新的需求？
- 新需求的时间是不是宽松？
- 新需求的测试资源是否充裕？
- 重构的内容的相关需求业务是否真的了解了？
重构要在自己非常有把握的情况下才进行的。有的人可能看到这里有放弃了。
其实怎么可能每次都能满足上面的所有条件，这个时候就需要保证两件事：时间充裕 + 大量的测试资源。
时间充裕才能保证自己能静下心来耐心的打磨代码。大量的测试资源是你的后盾，不断的持续部署，让测试将问题反馈给你，然后不断修复，完成闭环。当然，如果你决定这么做，就需要承担风险，因为总会有遗留的问题，连测试也没覆盖到的时候。你需要评估这种风险是否可以承受，如果不能接受就别重构了，或者划分成小模块重构，重构那些你完全有把握的模块。
“捡垃圾式”重构
重构的时间是当下，并非未来，所谓捡垃圾式重构也就是我们无时无刻不在重构。不要总想着后面安排一个具体的时间段一次性解决，这是不现实的，只会积累越来越多的技术负债。重构的力度尽量小而多。
重构的方法
重构和代码的坏味道都是重中之重，由于内容较多这里不细讲，并不代表不重要，而是非常重要，有兴趣的小伙伴可以参考之前的文章。
参考书籍《重构》
参考文章《重构与设计模式》juejin.cn/post/708184…
重构的步骤
好的重构应该像一边开车一边换轮胎一样，保证系统随时可工作的前提下，还可以对其结构做出安全高效的调整。
测试用例很关键，决定了重构的的结果，如果之前有写测试用例当然是最好，不然就需要你自己先去完善测试用例，覆盖所有场景。
重构的原则/收益
- 循序渐进
我自己有很多次陷入了完美主义的陷阱，总觉得重构就要一步到位，消除所有有问题的代码, 这样会把时间拉的很长，原本计划的 2 天完成，结果 5 天还没完成，一步一步陷入进去。不仅重构的需求没完成，后面排的的需求也延期了。这样的状态下根本没心思想什么设计模式、代码整洁，只想着如何快点完成开发。
持续不断的重构/大刀阔斧，切记小心。万不得已采用。
- 给人看的，要能理解
清晰的结构能帮助理解。“傻瓜都能写出计算机可以理解的代码。唯有能写出人类容易理解的代码，才是优秀的程序员”
- 需求驱动重构
不变得业务代码不必重构
- 少量的性能换取可读性
例如拆分成多个循环。
- 收益：提升团队的效能
- 收益：提高代码的质量，可维护性，可扩展性。
重构的结果
因为每位开发的个人能力和经验不同，重构的结果的好坏也没有一个准确的衡量标准，此时CodeReview 是重构后的一个必不可少的审核环节：
第一次审查是功能审查，确保代码按照预期工作
第二次审查是可读性审查，确保代码是可读的，并且易于理解和维护
小结
每一个开发人员都应该具备重构意识，重构是在任何时间进行的，不可能一次性写出优秀的代码，是在不断编写，不断重构中完善和提炼出来的。
总结
以上便是我本次分享的全部内容，希望对你有帮助。
