在博客浏览：https://ssshooter.com/2019-04…
事变
写顺序不是为了夸耀本身的手艺，是要给公司制造代价，要确切协助运用这个顺序的人。以及之前说过的，当顺序员就是为了进步社会效力。
写高效的代码是每一个顺序员的寻求，写易懂的代码是每一个顺序员的美德。
易懂的代码首先是有范例的，从目次构造到代码作风，在项目竖立初就应当肯定，能够写进项目文档中，文档用于给初见项目或是接办的顺序员一个概览,引见一下团体构造，手艺栈，以及一些坑。
手艺选型注重不要挑选没人用的（找不到协助）、无人保护的（发明 bug 会让你很痛楚）、很难用的（你本身懂也有可能要轻易被人懂，挑选框架特别注重，这也是 Vue 热点的缘由吧）。
掌握代码作风能够运用 eslint 和 prettier。前者用于代码范例掌握，后者用于花样化代码。一致的花样化东西设置也是十分必要的，特别在合作的时刻，假如双方的花样化花样差别的话，diff 也是地狱般的体验。
编码不范例，保护两行泪
在有范例今后，还要注重不要为了寻求极简写些难明的代码，你必需掌握简约和可读性间的均衡，比方
i = i ? (i < 0 ? Math.max(0, len + i) : i) : 0而有时刻，hack 是迫不得已的事变，这个时刻必需做好诠释。然则须要注重，诠释形貌的不是做什么（what），而是为何（why）。
一段可读性过关的代码中完整能看出它在干吗，看不出来做什么的代码很大概率是不及格的代码了。
可读性主要由定名入手，变量称号对整段顺序邃晓的主要性显而易见；别的，关于一些功用不太好看出来的几个语句的鸠合，纵然不会复用，也能够将其包装成函数，经由过程函数定名通知读顺序的人（而不是电脑）这一段代码的作用。
/* 另有一个例子是把对象绑到 vue 的 this，然后不 import 直接用
关于这个做法...看你喜好吧
毫无疑问关于模块化的项目，一个模块就不应当挂在其他地方
（虽然这么挂上去可能会免却 webpack 的模块挪用，让你的顺序快一丁丁丁丁丁丁丁点）
假如你真的懒到不写 import
请肯定要在绑定的变量加上 $
最少你这个时刻全局搜刮照样很轻易找到泉源的
*/
Vue.prototype.$axios = Axios有了范例的编码，仍不足以让全部代码库充足简朴，掌握代码庞杂度是下一个目的。
肯定要邃晓你的所做体系的需求，不然只会在误会和毛病的恶性循环中越陷愈深，糟蹋名贵的时候。
我近来就接办重构一个前后端耦合的项目，营业逻辑非常庞杂，邃晓需求这一步绝不能回避，只能一个个细节问清晰。
不要看到大佬提什么需求都一股脑加进去，纵然所提的需求很简朴，但你须要有充足的时候评价这个功用。
新增需乞降需求修正上也是一个原理，不能损坏之前的功用，保证全部体系的贞洁。
所以文雅地增加功用真的很耗时候。
至于真的不可行的需求，请勇敢说不。假如对构造影响很大的需求最好不要改了。不过这是抱负，中国顺序员彷佛没有什么职位
在工时预估方面，能够尝试拆分使命，而且要假定统统都邑更花时候。
拆分使命不仅能够让你更准确地预计完成时候，还能让你的事变更有层次。
至于优先度，还请连系上司指令和完成难度本身权衡吧。
总之，一个圆满的体系不是一步就可以造好的。
关于将来的功用，你能够留个后路，但不要提早瞎做“自以为须要”的功用。不然到时刻写了一堆没用的代码都是糟蹋时候，还可能让进步顺序庞杂度。
优化方面，参考有名的“不要过早优化”。让准确的顺序更快，要比让疾速的顺序准确轻易很多。开辟和优化看成两个自力的步骤来做。
Premature optimization is the root of all evil.
保护是软件开辟主要而难题的一环。不过假如你按着上面所说的做，我置信…保护不会是难事。
然则假如你的代码写得很恶心，你会为之付出代价。
准许我：情愿在完成功用时很痛楚，也不要在保护的时刻更痛楚。
一样平常
- 反复的轮子
巨大的开源形式让全部编程界生长加快。
能够站在伟人肩膀上，就别反复造轮子。
除非你真的很闲（事变不饱和哦～）,或许你找到的轮子着实分歧情意（如老旧、不文雅、功用太冗杂）
- 反复的事变
「反复」是顺序员最大的仇人！
计算机就是担任给你做反复的事变，顺序员为何还要做哦？教计算机做就好了！
你能够依靠 node.js 写处置惩罚顺序处置惩罚你的文档，在编辑代码的时刻能够活用快捷键修正代码。
- 自我开辟
顺序员谢绝 996，然则在家不意味着闲着，你仍须要为本身的头脑投资。
这一行变化还挺快，虽然我也真的完整不会看将来走向，不懂什么言语和手艺会在今后更有代价，然则只管不要范围与进修单个言语，也不要由于是前端就完整不学后端。
我以为如许才当一个有款式的顺序员。
处理题目
If you can’t explain something in simple terms, you don’t understand it. — Richard Feynman
假如你不能流畅诠释一个题目，那申明你照样没懂，也就是还没真正处理这个题目。如果没真正处理题目，便不能闻一知十处理更多类似题目。
处理题目要邃晓题目怎样发生，先思索，后行为。行为无解能够到谷歌搬救兵，搜刮不到的话……
终究计划就是到对应社区发问，然则发问同样是一个学问，请看 How To Ask Questions The Smart Way。
生产力
不是代码越多生产力越高，顺序员应当都懂，至于老板怎么看，就不得而知了 😂
One of my most productive days was throwing away 1000 lines of code. — Ken Thompson
末了，请让上面的头脑铭刻于心中，事变时条件反射地记起 😜
参考链接
Learn the fundamentals of a good developer mindset in 15 minutes
