共计 3280 个字符，预计需要花费 9 分钟才能阅读完成。
之前在公众号里有个读者给我留言：
请教个问题，公司高职级和初中级，都是写业务代码，那么高职级的价值在哪里呢？
由于公众号回复留言的限制，当时我就简单的回复了如下的几个点：
- 初级多在写代码，高级多在设计代码；
- 初级多在解决一个问题，高级多在解决一类问题；
- 初级多在考虑技术问题，高级还要参与业务上的需求；
- 初级工程师只管接需求，导致自己忙不过来，高级工程师会砍需求，用自己得经验告诉产品这个需求不需要，告诉设计师这个交互没必要；
- 初级工程师可能做完一个项目就完了，高级工程师可能会封装几个组件，整理一个脚手架出来。
还有很多很多，初级工程师和高级工程师差距不仅仅是代码质量上，而且其他能力上，解决问题的能力，抽象问题的能力！
今天有时间，想详细的跟大家谈谈我所遇到的、见到的厉害的程序员，同样是写业务代码，为什么会比初级程序员拿的工资高？
初级多在写代码，高级多在设计代码
一般人可能拿到需求，就开始写代码了，写着写着由于页面功能越来越多，感觉代码越来越复杂，自己都会觉得难以维护了。
我拿我自己举个例子，之前有一次我写完一个页面之后，然后给另外一个同事 (可以理解为高级程序员) 让他帮我 Review 代码，看到我的代码之后就觉得这个写得不对呀，怎么会这么去 设计 呢？
然后他给我理了下整个页面应该如何去设计，一个页面分为哪些块，有哪些事件，每个事件应该 dispatch 哪些 action，然后整个模块有哪些数据放在 store 里，哪些模块放在 state 里，当时反正听他理完之后，感觉自己写的代码真的很垃圾，然后花了两天时间把上周写的代码重写了一边。
注意，这里是重写，不是重构，重构是对软件内部结构的一种调转，目的是不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。那么如果保证不改变软件可观察行为呢？就需要写测试用例，保证测试用例能跑通的情况下进行重新构造代码才是重构的第一步，没有测试用例的重构就是耍流氓。
那么如何提高设计代码的能力呢？
我觉得有一个方法对于提高设计代码的能力非常有帮助，那就是采用 TDD(测试驱动开发)。
TDD 的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。– 来源百度百科
为什么 TDD 会提高设计代码的能力呢？可以看到 TDD 的原理是要在写代码之前就要写测试用例，在写测试用例的时候你必然得去思考你的每个函数，每个模块，每个组件应该如何去设计才能使得易于测试，往往易于测试的代码都比较好维护。
这就可以达到在写代码之前先去设计代码，然后才写代码，也就是先思考，后行动。
我只是说 TDD 可以提高设计代码的能力，并没有说我就特别提倡 TDD，说 TDD 很麻烦，难以实施的人就不要跟我讨论了。
初级多在考虑技术问题，高级还要思考业务上的需求
我们要知道，技术是为业务服务的，没有业务谈技术的好坏都是瞎扯淡！
常常可以看到很多实习生，或者刚来的应届生会吐槽以前的老代码用的框架老，用的技术旧，然后就去改成新的，自己觉得牛逼的，然后没有多个环境测试，发上线就挂了，这种例子很多很多，别说我们公司，就连我们组都出现过好几次这样的情况了。
这种就是只考虑技术问题的，而没有去考虑为什么以前前人要这么写，前人没有用这些东西，难道仅仅是因为那个时候没有新东西，或者说认为前人比你差。
很可能就是他们考虑到了业务上的需求，比如要兼容 IE、或者比如考虑到了有很多用户用 iOS，Safari 不支持 webp，或者比如考虑到很多用户是低端机，性能不好，不能用一些新特性等等问题。
对于老板来说，他根本不管你用什么新技术，新特性，也许你用了新特性确实让代码更简洁了，但是，但是，但是，发到线上挂了，那么你写的东西就是垃圾，连最基础的稳定性都保证不了，更别说流畅性，高并发。
初级工程师只管接需求，高级工程师会砍需求
经常看到很多初级工程师就是，不管产品、运营甚至后端提出一些需求，他也很友好，只要是需求，他都接，然后整天忙忙碌碌，还经常加班，但是实际上，很多需求做了没有什么价值，也许还有些是重复工作，还把自己搞得很辛苦，这种情况真的很多很多。
然后还有一种情况是有一个产品需求来了，然后 balabala 一顿需求讨论之后，产品给出一个期限，初级工程师满打满算，可能能完成，然后就说能行，结果要么对自己能力估算错误，要么很多突发情况，然后不能按时上线。
而高级工程师基本上不会出现不能按时上线的情况，我思考了几点原因：
- 会给自己留 buffer，来避免突发情况导致时间的耽搁。
- 在需求分析的时候会思考每个需求是否有必要，如果有些需求觉得没必要，会和产品讨论，拿出 充分的理由 将需求砍掉。如果都有必要，然后时间又不太够，会去和产品谈是否能使交互简单一下，一期先出个什么样子，下一期再做完整一点。
- 对需求的评估以及自己能力的评估更准确。
这里我想要表达，不是所有的需求都是有必要的，不要每个需求都去接。
那么如果来判断一个需求是否应该接呢？
我觉得主要是去思考他背后的价值，为什么要做这个东西，做了能达到什么样的效果，如果产品说不出来价值，或者说产生的价值与你花费的时间不匹配，那么这个需求就是有待商讨的。
初级多在解决一个问题，高级多在解决一类问题
很多初级工程师可能昨晚一个项目就完了，还觉得很 OK 呀，然后也把在项目中的问题一个一个的解决了，按时按量的完成了任务。
对，这就是初级工程师的标准，能完成一个项目。
那么对于高级工程师除了完成项目还会做什么呢？
也许会封装几个公用组件发到 npm 上大家都可以用。
也许会整理一个脚手架出来大家用，比如以前公司没有用 TS，那么用 TS 写完项目之后，踩了很多坑，你就可以整理出一个脚手架，然后把踩得坑记录下来，方便后面想用 TS 的人用。
也许发现前端工程师还原 UI 搞是一件枯燥无味，而且没有技术含量的事儿，我司有个大佬就写了一个 UI2Code 的工具，可以将 Sketch 文件转化为 html 代码。
也许高级工程师发现一上线一个功能，小程序和 H5 都要写一套一模一样的，然后我司大佬就写了一个可以将 vue 代码转换为小程序的框架，一套 vue 代码，h5 和小程序都能用。
这些都是我身边的例子，可以看到高级工程师经常解决的不是一个问题，而是解决一类通用的问题，然后给出解决方案，并且得以实施，从来不会认为吧项目做完了就完了，没有一点产出，也许你做这个项目是对自己太大的帮助，成长的。
初级程序员经常犯的错误集锦
然后我在知乎上看到了一个初级程序员经常犯的错误集锦，我觉得非常大家都可以看看，自己有没有这些毛病。
1 命名不规范
2 日志不规范
3 拒绝写接口和假数据
4 不写单元测试
5 盲目集成
6 逻辑不清
7 不做方案
8 不关注性能
9 害怕重构
10 做出来就好，不考虑优雅的方案
11 不考虑未来需求的变化
12 遇到问题的时候不会试错
13 不会写伪代码
14 不做数据量的预估
15 提交代码不规范
16 不喜欢打 Tag
17 不遵守发布流程
18 不知道 Bug 修复的优先级
19 总喜欢手动修改线上代码
20 不做数据备份
21 不做自测
22 不尽力模仿真实数据，测试数据很随意
23 不抽取公共代码
24 不认真听需求讲解
25 不看验收标准
26 不主动推进项目进度
27 遇到难题不主动反馈
作者：暗灭链接：[](https://www.zhihu.com/questio…https://www.zhihu.com/question/33578621/answer/451931102
总结
初级程序员主要是体现在目光短浅，缺乏思考，做完东西没有成果，不积极主动。
而高级程序员不仅仅是代码写得好，写得快，确实思考得更长远，做的东西更有用。
我列举我身边所遇到的高级程序员所做的事，我觉得更有说服力，不是空谈大道理，都是我从身边的大佬们身上学到的，希望能给刚入职场，或者感觉自己是个初级程序员的程序员们一些警惕。
当然，上面所说的高级工程师所拥有的优点和初级工程师的缺点，都不是所有高级工程师都会有所有的这些优点，也不是所有的初级工程师都具有这些缺点，这是没办法进行定量的。
你们身边还遇到什么高级工程师的特点，或者初级工程师的缺点，欢迎在评论区里面留言。
最后欢迎大家关注我的公众号「前端桃园」
