我的编程原则

这是我个人的一些原则, 不一定正确, 不一定适用于你, 但是在一段时间内都会指导我如何写代码.

# 无心智负担

也就是写出傻瓜都能维护的代码, 不必担心副作用, 不必担心连锁反应, 想改就能改, 只要保持功能和接口的统一, 那么就可以被随时修改被替换

# 组件的边界在哪? 组件要做什么? 不做什么?

封装是很常见的事情, 封装时问好自己,我要做什么, 我绝不做什么, 组件的魔爪最长会伸到哪里.

# Finally, remember that linters exist to serve you. If a linter rule annoys you and your team, delete it. It may not be worth it. Learn from your own mistakes.

这是从我喜欢的一个程序员dan abramov在一篇博客里面说的话, 让当时被各种lint规则弄得焦头烂额的我恍然大悟, lint 是为了服务我让我更开心的编码, 如果有一天它给我带来了麻烦, 那我会毫不犹豫的禁用它.

# ui组件不要给自己预留边距

这条规则纯属我个人, 应该是极不通用.

比如写一个Card卡片组件, 通常的做法是会为这个组件周围留下10px之类的边距空间, 让使用的人直接放到页面上的时候天然和其他组件保持一个距离, 如果不预留的话那么使用的人就需要自己写一个边距, 这样看起来这个组件使用就没那么方便.

但是我不预留, 组件贴边裁剪.

因为我烦透了太多使用时要考虑这个组件的默认边距是多少呀? 设计稿上是12px, 那么这个组件是正好12px吗, 还是说我用的时候需要手动覆盖它的样式, 这种思考在我看来是心智负担的一种, 我宁愿多写代码手动填上自己想要的边距, 而不愿去猜去比较组件自带的边距是不是刚刚好.

# 单一职责? Do onething in one function?

这条规则大家基本都知道, 但我很少坚持这种做法, 是因为有些时候我为了少写代码, 会把一些代码写在一个函数中, 上周突然开始想这种做法会不会是导致我经常觉得自己的代码不好看, 时常重构的原因之一?

比如两个函数, 一个做start,一个做stop, 有个要求是start前一定要stop上一次的结果, 于是我经常会在start里面开头写上一行stop.

这其实是违背这个原则的, 因为start不仅做了start还做了stop, 方便的是使用者不用在start前手动stop一次, 所以到底哪个好呢?

也许多阅读一些认可度很高的社区代码能帮我理清这个问题?

也许需要重新整理一下通用的编程原则, 对照自己看看?

# 编写同构(isomorphic)的代码

这里针对的前端开发而言, 写代码时对于环境的依赖保持小心, 尤其是window/document/fs等变量的使用, 他们都是专属于某个特定的运行环境的, 可以放心依赖的只有JavaScript本身(当然了, JavaScript版本是另外一个注意项了)

# 业务代码

业务代码中任何事先的优化和设计都是白费功夫? 所以该对业务代码采取另外一种"够用就好"的编码方式吗?

# 自上而下

自上而下的组织代码, 主要的内容放在上面, 次要的/工具类的放在下面