编程效率

传说程序员打字速度要快, 很多人仍然会以这样一个标准来片面判断技术水平.

拜托, 你是一个程序员, 不是一个打字员, 打字快可以代表一些, 但也并不代表什么.

互联网行业还在纠结打字速度的, 不是外行, 就是一个没有独立思考的人.

如何提升

所谓提升, 就是在现有的基础上进行优化, 让结果比当前更好.

提升编程效率, 可以理解为同样的或类似的一个项目, 一个模块, 一个功能, 能够更快更方便用更少的时间来实现.

这一次做过, 下一次再做同样的, 因为熟悉所以耗时更少, 这种提升不叫提升, 叫做重复劳动.

重复劳动能够提升的效率很有限, 重复一万次同样的流程, 除了增加熟悉度以外, 没有任何价值和效率可言.

既有比较, 就应该记录当前事物的耗时时间, 对比下一次的耗时, 来得出效率结果.

既有提升, 就应当分析哪些模块可以做的更快, 哪些事物导致了效率低下?

编码习惯

由于不同行业和技术有不同的适用场景, 不可能一套方法适合所有.

以下内容仅为随笔, 适合个人的独立思考和分析(前端).

在项目提测上线之前, 是最适合进行小步优化的时候, 因为一旦上线, 之前的代码就不能随意改动.

在开发周期内, 即使任务再紧迫, 加班多严重, 精神多疲惫, 也要尽量以一天, 三天, 一周为单位, 进行整理和优化.

全局变量

如果你发现一个值在多个页面共享或者在不同地方使用过, 那么可以及时设置为全局变量.

常见的如 H5 判断手机型号是 android 还是ios, 屏幕的可视区大小, 统一的字体配色和背景色等.

这样做的好处有以下几点:

• 存储一次, 多次复用(不用每次在需要的地方都重新用方法获取一遍)
• 全局更改, 只需修改值一次, 所有用到的地方都自动统一(不必一个一个修改, 不会有遗漏和改错的问题)
• 方便多模块多系统共享, 方便可视化数据(公共参数和配置一目了然, 其作用也一目了然)

当然, 考虑效率的同时也要考虑性能等问题, 在合适的地方一定要及时用上, 避免不必要的时间浪费.

函数封装

同样的, 如果一个同样或者类似的方法, 重复使用了多次, 就可以进行函数封装.

函数封装有很多优点:

• 代码复用(提升效率的关键)
• 提升程序的简洁性和可读性
• 提高代码的安全性和可移植性

没有什么比拿来即用的方式更快的.

如时间格式化, 显示不同风格的时间, 年月日或者时分秒, 或者时间戳等形式.

这种功能统一的代码, 没有必要在每一个地方都写上一遍同样的逻辑.

只需要封装为一个方法, 在需要的时候调用即可, 函数里面的逻辑我们只需要在创建的时候思考.

组件抽离

类似于开源的第三方 UI 库, 把一些常用的 UI 整理成组件, 需要的时候按配置使用即可.

于前端而言, 界面的任务量占据了很大的比例, 抽离组件, 势在必行.

还是一句老话, 不做重复的劳动, 但凡发现多次使用同一个事物的时候, 就应该考虑组件形式.

设计稿先出的前提下, 基本可以了解有哪些元素多次使用, 但是组件既要考虑解耦, 也要考虑兼容.

操作说明

有的时候, 一个多次重复的内容是随着业务的增加和改变而导致的, 不一定一开始就是.

这种情况很多人会选择复制黏贴代码片段, 显然这种方式会更快一些, 符合拿来就用的形式.

以上的操作都建立在有一定时间的前提下, 如果连基本的开发时间都不够, 再怎么提升效率也是免谈.

无论是从职场还是个人角度上看, 推荐在加班时梳理下代码层面, 在下班后梳理下思维层面.

你不能期待一成不变的思维和习惯会有什么提升效率之类的效果.

前期做的多, 是为了后面做的更少和更快, 是否需要, 具体操作, 自行斟酌.