开发新手常犯错误

开发前不思考
人们不会轻易写出高质量代码，这需要严谨的思考和前期调查
书写高质量代码过程：想，调查，计划，写，测试，改

编程实质大多指：看旧代码，调查还差什么以及怎么和当前系统整合，从小的、可测试的小模块开始写新特性。

真正花在编码的时间只占10%
编程是一个基于逻辑思考的创新性活动

开发前计划太多
不要妄想提出完美的计划
只找到一个可以让你开始的好的计划 就行了

事实是，计划是不断变化的

拒绝waterfall，在一开始就把所有特性、功能设计好 是不现实、可行的

写代码是一个渐进式，互动的过程
在Agile的过程中，不断新添加和删除特性 这才是健康的过程

总之，记住 每次只计划接下来的几个特性 就行了。

重视代码质量的重要性
注意代码可读性
开发者主要的工作就是清楚地描述出你对任何解决方案的具体实现

一行不要超过80个字符
ESLint 和 Prettier可以帮助

不要用双重否定

请用简短、有描述意义的词命名

常量也要命名！不要hard code

只有在把你的代码边长会会使其更有可读性时再加长它

删除不必要的代码是你在编码中能做到的最好的事情

不要提升性能，除非你可以测量它

选择第一个解决方案
遇见问题 马上开始实现不考虑复杂度和潜在的失败情况

好的解决方案往往都是从对现有方案的疑问开始的

如果不能对一个问题提出多种解决方案，那或许是我们没有完整的理解一个问题

专业的编程者的工作不是为问题找到一个解决方案那么简单，而是找到一个“最简”方案。最简的意思是工作正确，运行高效和可读性强、易理解、易维护

不放弃旧方案
许多时候，即使我们发现当下的思路不是最简的，我们依然坚持着老的解决方案

开始怀疑一个解决思路的时候，我们应该把当前的思路全部抛开并且重新思考问题

小例子：用jquery动态append元素而不是把DOM在html中渲染好，只通过js控制显示。动态的append元素会引起reflow，影响性能

不搜索查询更好方案
遇到难题先谷歌（百度），很有可能你的问题已经被解决过了，能节省时间和学习到新的东西

Google/Baidu will surprise you

永远永远永远 不要按部就班复制粘贴你搜索到的代码而不去理解

不封装
不封装常常导致难以维护的系统

应用中，一个特性只在一个地方控制，也就是一个对象；这个对象只向其他应用中要用到它的地方暴露必要暴露的东西。

这就是削弱应用之间不同部分关联性的概念。

这样，能使你安全的在类或对象内部进行修改而不会在更大的范围内影响别的功能

什么应该合并成类？：
概念上逻辑或状态的集合 就应该是一个类。这里的类可以是一个Class对象或一个函数，你也可以叫模块或者包。

类中的方法：
在每一个类中，一些task片段组成method。
Method应该只做一件事，并且把它做好！！！！！（相似的类应该有同样的方法名）

不好的类：
1 “龙套”类：某一个类，在很多不相关的类中都用到
2 你改变一处，发现会导致多处连环修改

当向类或方法中添加更多的功能时，不要跳过思考，不要以为你会在后期重构它。在第一次就用正确的方式做！

代码要高聚合，低耦合，不同类之间少一些关联！

为未知做计划
不要写你当下不需要的代码 不要为未知的特性做计划

为一个你认为将来会有的需求编码 是错误的

用最少的代码来完成你的解决方案，考虑边界值，是好的，但不要考虑边界需求
没有使用正确的数据结构
认识到各个数据结构的好坏，可以让你成长为更好的开发人员

几个例子：
1 用数组而不是Map记录“记录列表”
这里的“记录列表”是指 每个记录中包含一个key值用来唯一标志每一个记录并用于检索记录

用数组也不是不可以
但！当数据很多时，用map要比数组快的多很多

2 不用"栈"
用栈结构 替换递归函数

当某一个递归函数的返回两个及以上对自己的调用时，很难对其进行优化

使现有的代码变得更糟
如果现有代码很乱，你需要加一个东西上去，先清理一条通往要增加东西的地方的道路，而不是直接加上去

例子：
1 简单拷贝/粘贴现有代码，只稍微改动一两句话
请谨时刻记抽象的概念，并时刻使用它当你可以的时候

2 不用配置文件
什么样的值需要放在配置文件中？：
在不同环境、不同时间会变化的值
在代码的多个地方用到的值，也应该放在配置文件中

3 使用没有必要的条件判断和临时变量
新的条件判断会向函数中新加一个逻辑分支而不是新建一个函数，也就是让函数变得更复杂

当你在不牺牲可读性的情况下可以避免条件判断的时候，请这么做

每次你想加一个if条件判断或者新的变量时，想一下我们是不是在正确的层面上修改代码呢？是不是应该在更高的层面思考一下问题

经典例子：
function isOdd(number) {
if (number % 2 === 1) {
return true;
}
else {
return false;
}
}
==>>
function isOdd(number) {
return (number % 2 === 1);
};

写没必要的注释
通过命名有意义的变量名，可以省去很多不必要的来解释每个变量是用来干什么的注释

好的注释，应该是来说明为什么要写这段代码，而不是写这段代码是干什么的

不写测试
作为人类，你会忘记之前成功的判定，让机器帮助你

如果可以，在开始编码前就开始设计你的判定（TDD）

认为正常工作的代码就是正确的代码
注意边界问题：
输入为空
非法输入：非数字、非数组、非字符串、负数等等等·········
函数的默认行为 都要考虑进去

不质疑现有的代码
任何你没有完全了解的代码 都有可能是不好的代码 尽情的质疑它

有时，有些代码看起来很不好，但也许有一些特殊的原因导致它必须是这样的

痴迷于最好的实现
只要你花更多的时间 总会找到更好的解决方法

保持质疑、挑战任何理论 头脑清醒 只做深思熟虑的决定！

痴迷于性能
如果不能够用代码衡量性能问题，请不要试图优化它

不要在执行代码前优化它 有可能只是在浪费时间

记住一些很明显的优化点足以，如：永远不要在nodejs中发布洪水时间池

不注意End-user的用户体验
将自己放在end-user的角度思考特性

如果自己是end-user，怎么样能更快、更好的找到和使用这些特性 而不是简单的把特性加入现有的应用中

注意特性的可发现度和使用性

没有选择正确的工具工作
选择和工作适合的工具进行开发 而不是老旧的，自己用的惯的或者市面上用的人多的

没有意识到 代码问题会导致数据问题
永远不要放任对数据进行操作的代码的“小问题”

只修改与数据相关的代码而不修改因老代码造成的数据错误会导致更坏的结果

怎么办？：
运用多层数据一致性判定
哪些层：前端，后端，网络层和数据层
其中，数据层的限制是必须的

哪些限制：
not null / unique / check / primary key / foreign key
老生常谈的一些属性了

还要注意“事件”的处理 如果多个操作要发生在一个数据项上并且相互关联，必须要把这些操作放在“事件”中，如果发生失败，好回滚。

重塑第三方库
请使用开源第三方库，可debug也好修复问题

不要包含一个大库，而只用其中很小的一部分方法，如果只想用一部分，请只包含进来那一部分

对Code review有不正确的看法
将每一次code review当成学习的机会，当别人教你一些东西的时候，要心存感谢

互帮互助 相互交流

不做代码控制 (Git)
代码控制的意义在于清晰的历史记录

commit很重要，帮助维护人员了解代码一步步迭代发展的过程

多commit多提交 用一般现在时态 如果几句话说不清你的commit 说明你提交的太晚了

了解、学习、使用更多的git特性

过度使用共享数据
在合适的 小的作用域中使用变量

当多个资源要在同一时间修改同一个数据时，会有问题

不要用定时器实现数据锁

对错误有不正确的态度
有错误是好事 说明你在进步

改变对待错误的态度，将他们视为助手，处理他们，从中获得进步

有些错误需要升级为exception，exception是一些需要计划的为用户设计的错误，需要展示或控制

有些错误需要留下了 使系统停止工作

不休息
作为人 我们的身体和脑 需要休息 我们无法妥协

强制自己在工作中做一些小的休息 从椅子前离开 走几步路 放松一下 回来用全新的视角看待代码