为什么开发效率这么低，时间都去哪了?

在埋头打码的时候，总会云游天外思考点人生问题，回过神来吐槽自己：开发效率为何这么低！

明明实现的业务逻辑并不是很复杂，代码量也不会太多，为什么项目的开发要那么久？时间到底去哪了？

一次两次的问题，或许我们不会在意。
但频频爆发的问题，这就值得我们深思了。

这不是个单因单果的问题，找出潜在的可能因素，才能给出针对性的优化方案。在这里我以自身经历描述。

可能的因素

1. 自身能力问题
   　　这是个令人悲伤的故事。
   　　因为学习时间短，知识的积累不够，导致在开发中实现能力跟不上逻辑思路。
   　　比如开发过程逻辑思路没毛病，但因为语法障碍不能直接实现，导致为了实现该目的，而学习其他知识、尝试、做其他处理，多出了工作量。
   　　测试报错定位问题。报错或警告信息看不太懂或没有任何报错提示，不能快速定位问题，导致只能采用低效的暴力尝试。

2. 技术沉淀与指导
   　　某些缘故，公司去年才有的前端，全公司对前端开发相对熟练的只有公司的CTO和1个工作2年的老员工。
   　　公司的规矩：在技术上的问题不准交流和答疑，除非google都帮不了，才能寻求帮助。
   　　没有技术指导，基本只能靠自学。没有前端技术沉淀，每次开发都是新的开始。

３. 需求不确定
　　记得Boss给我第一个任务，需求只有3句话：
　　① 给一串json数据，你画一个图
　　② 待会让你看看数据大概长什么样，图大概长什么样
　　③ 需要多久能完成
　　这是原话，也是全部的需求。
　　场景未知，具体需求未知，用处未知。
　　仅有这些条件，又不得不先应承下来。
　　只能先设计一个可拓展的组件，起草一份demo来验证需求。
　　这不是段子，也不是个例。

4. 需求变更
   　　程序开发完成，前后端正在联调。
   　　然而此时设计师说突然发现少考虑了件事，再加个功能……。

5. 设计变更
   　　有些时候项目需求的小变更，我们能够忍受。
   　　只要程序写的够灵活，拓展性好，坐等对方改需求。
   　　然而，让人出乎意料的是，等来的不是需求变更，而是设计变更。
   　　设计的改动一般是较大的变动，基本上是项目整个翻新。

6. 不明确责任
   　　有时时间很紧，在没有明文规定的责任，大家下意识偷懒，然后开始了扯皮大战。
   　　如前后端接口的接口文档谁写，测试数据谁造这种小问题。
   　　因为没人规定，之前是谁时间方便谁写，现在大家都不方便，都不想在小问题浪费时间。
   　　遇上脾气倔的，耗上大半天都没问题。

７. 概念误解
　　前后端分离，各自完成好自己的模块。
　　感觉挺容易懂的一句话，不知为何大家总有误解，概念总是不统一。
　　我所认为的＂做好自己的模块＂： 程序开发完成 + 测试。
　　旁边的前端同事认为的＂做好＂： 程序开发完成。(无测试：工具不会用，不知怎么模拟数据，怎么模拟请求，算了等后台)
　　旁边的后台同事认为的＂做好＂： 程序开发完成。(无测试：哎，没时间写单元测试，接口太多了，直接功能测试吧)
　　然后前后端一联调，各种报错，前后端都有问题，重新改代码。
　　作为负责人，只能等着，随时准备救场。

8. 联调测试太慢
   　　前后端克服了种种困难，代码逻辑正常，自测通过，终于到前后端联调。
   　　然而迷之 bug 登场。
   　　同样的数据在后台本地运行没问题，由前端通过接口请求反而报错！！！
   　　尝试N久，在请求的 url 中发现有个常量的数据大小写搞错了。接口文档被践踏。
   　　接着，继续痛苦前进，又碰上了迷之bug。
   　　前端传入JSON字符串化的数组在后台被误当成数组解析了。
   　　怀疑是编码问题，然而实际是前后端语言类型的差异，后台的判断逻辑不够严谨导致。
   　　方向错了，做了无用功，导致白白浪费时间。

9. 工具驾驭不了
   　　善用工具能提高工作效率。然而驾驭不了工具就很坑了。
   　　VSCode突然内存泄漏，电脑卡顿（明明插件都禁用了，内存就从没低过800M，我好怀念使用Sumblime Text的简捷）。
   　　RAP的网站突然访问不了，数据的模拟都在那，就这样被一锅端了。
   　　git的版本控制，突然发现代码拉错地方、代码推错地方、代码被某个混蛋给改了。不知怎么回退，好慌。
   　　google搜索，英语渣看的好费力，信息量太多排查要好久。
   　　第三方插件的引入竟然被检查出语法有错（第三方插件本身没问题），导致程序打包报错。

10. 前人留下的坑
    　　有次收到Boss的消息，XX有急事回家，但项目未完成，另外需求有变，项目后天交付，希望我过去帮忙。
    　　当时我并不知道她的项目情况，那晚大概了解下需求，第二天接手代码。
    　　接手别人代码是件痛苦的事，尤其是碰上写死的页面和数据、混乱的结构、一堆无关的代码以及有误的处理逻辑。
    　　事情的结果就是比我计划时间多花了1倍才完成。

11. 不在状态
    　　开发过程经常遇到的问题， I'am not myself.
    　　上个厕所，吃个饭回来，思路断了。
    　　碰上某某情况，老板请客，中午出去吃一顿。两三个小时没了。
    　　没休息好或碰上烦心事，头脑不清晰，注意不集中，写多少错多少。

优化方案

1. 基础能力问题
   　　问题关键在于时间成本。因为能力不够耗了时间，随之学习时间少了，能力上升缓慢，形成恶性循环。
   　　前期题海战术（针对性解决问题），快速入门，之后再思考根源问题。

2. 技术资源问题
   　　没有枪，没有炮，敌人给我们……醒醒吧，自己造。
   　　如果造不出，那……换坑吧。

3. 需求不明确
   　　这是无法控制的外因。
   　　要么主动尽可能的问清楚，并留下记录。
   　　要么速度快点，起草demo验证需求。

4. 需求／设计变更
   　　逃不过的外因，只能提前预防。
   　　程序尽可能写灵活，保证能快速响应变更。
   　　不要因为一时偷懒，坑了自己。

5. 分工问题
   　　一般自个没有决策权，找Boss说情况定规矩，按制度走。
   　　虽然可能吃点小亏，但也是为了大局着想。

6. 概念误解
   　　谨慎确认。特别是有前科的人。
   　　如果同事不是特别给力，建议还是谨慎点，防止被坑，即使对方并不是有意（人在江湖，身不由己）。

7. 联调测试问题
   　　按规矩走，自测通过后，双方交换测试数据，再自测一遍。排除数据格式出错的可能。
   　　遇到问题别慌，也别急着推卸责任。比起谁的锅，Boss更关心项目的成果。

8. 工具问题
   　　工具的驾驭程度，在前期帮助很大。
   　　自个找时间上网找教程，或动手实践。
   　　不要因为畏惧改变，而放弃了好东西。

9. 前人的坑
   　　无法避免的坑。
   　　交接时问清楚，留下联系方式，有问题一边试一边问。
   　　另外，祈祷同事坑挖的小点吧。

10. 不在状态
    　　这没什么好说，别让工作打乱自己的思考。
    　　环境和时间会慢慢打磨一个人，勿忘初心，方得始终。

思考

大多时候，我们都发现了这些问题，却不怎么在意，或是没能有效解决而放弃。
　　逃避解决不了问题。要么快速解决，要么阻止发生。
　　懒于改变现状，或畏惧改变，可见的未来并不是我们真正想要，不试怎么知道自己真的无可救药。