初中级开发如何有效减少自身的工作量？

程序员的工作量主要分布在哪些地方？

1）设计

2）编码

3）测试

4）调试

5）捉 bug

要实际减少工作量，其实关键问题是如何分配这 5 项工作的内容比重。

设计的重要性远比开发人员想象的重要，如果一个开发把设计图和项目经理的要求原封不动不加设计的翻译到开发上，他大概率会在 3，4 上花费两倍以上的时间？为什么？拿现在常见的前后台分离模式的后台开发（下面就基本用后台举例了，各类项目类似）举例：

1）设计视图不等于功能试图

2）功能试图不等于数据视图

当从设计视图不做详细设计直接推导到数据视图的时候，就会有很多的问题，比如我们有个接口是导入个人标签，后台设计的时候，看见页面是在导入数据，这个数据就被直接叫 Shuru 了……，这是不是错？是，因为完全没法协作，也没法排错，因为这个数据是干什么的都不清楚，详细的可以见我这篇文章

百家饭隐私计算平台：API设计的路径规划0 赞同 · 0 评论文章0 赞同 · 0 评论文章

所以清楚的明白自身工作的范围，并对外部需求进行良好的设计，是减少工作量的第一步，再拿后台来说，我的建议是，拿到设计视图先确定数据视图设计，再从数据模式反推功能视图，再进编码，才能事半功倍。

编码阶段，要有抽象和复用的思维模式，我做开发读过最重要的两本书，一本是《修改代码的艺术》，一本是《代码大全》（如果只选一本，我选代码大全），我至今仍然在践行里面两个模式：

1）不写

if err != nil {  return err}

写成

if err == nil {   //正常操作}return err

书里的理由是

把你认为会正常出现的情况放在前面来处理。这符合把决策的结果代码放在尽可能靠近决策位置的一般原则。下面面代码示例里执行了很多错误处理……这段代码很难理解，因为它把正常的情况和出错的情况混在了一起。很难从中找出正常代码的路径来。

2）不写

var count=0;func main(){  printName()  printDescription()  printName()  printDescription()  fmt.Printf("共打印了%d次",count)}func printName(){  fmt.Println("百家饭OpenAPI平台")  count++}func printDescription(){  fmt.Println("很棒")  count++}

写成

func main(){  var count=0;  count += printName()  count += printDescription()  count += printName()  count += printDescription()  fmt.Printf("共打印了%d次",count)}func printName()int{  fmt.Println("百家饭OpenAPI平台")  return 1}func printDescription()int{  fmt.Println("很棒")  return 1}

这两种的区别是什么？第一个版本的 printName 每次执行结果是不一样的，因为第一次执行前 count 为 0，第二次执行前 count 为 2，因为他有个隐藏的全局依赖，这种设计叫破坏了可重入性，函数不能两次进行一摸一样的执行，这样的设计使得程序的设计、测试的测试复杂度都高了很多，单元测试都没法进行，因为没有办法对结果有一个准确的期待，这只是个简单例子，复杂的说，例如一个函数即要调用 api 又要进行计算，那也是一个不能重入的函数，正确的做法是把计算和 API 调用分开，对计算进行单元测试覆盖。

我很庆幸在我做开发的初期阅读了代码大全，这本书很枯燥，没有讲常见的类库怎么用，而且讲了很多看起来和工作一点关系都没有的东西，比如变量命名该用动词还是名词等，但是为我之后能更快速的编程起了非常大的作用。

对必要的代码进行单元测试，仍然是避免多数逻辑问题的上策，上次有人讲 TDD 过时了，我其实同意的，全方面的用测试去驱动开发，确实很难也不太必要，但是对关键步骤确实有进行单元覆盖的好处，但是，因为由于在大多数开发那里，代码都没有做到上面编码第二个问题的可重入性，使得测试基本无法展开。所以一般开发很难去理解如何做单元测试。

从这里我们只能再重复的说一遍，理解编程的基本理念是多么重要的事情。

另外需要提到的是，现有程序开发基本是个围绕框架进行的过程，很多开发除了基础的框架使用之外，对所用语言的下层逻辑理解不足，使得很多初中级开发无法大胆的进行子程序的剥离和抽象也变成了一个大问题，只敢做 controller、service、mapper，不敢再进行深入的继承、子类，exception 的使用，这些问题也导致了开发不能有效的将核心逻辑进行抽离，实现足够的单元测试覆盖率。

对基础逻辑理解的缺失也影响到了调试和捉 bug 阶段，如何进行接口抓包？抓包如何分析？http 状态如何影响上层 api 逻辑？怎么判断 cors 等常见非程序设计 API 错误？最初网络逻辑有七层，后来又说 4 层结构，那这四层结构中，api 调用逻辑在各层都是怎样表现，会出现什么样的错误？

综上所述，要想减轻工作量？进行深入学习，做好提前设计，改善编码风格，基础夯实了，才能真正的实现提质减量。

最后做个广告：

我司正在进行 API 前端工作的自动生成工具的研发，这也算是帮助开发减少工作量的一种措施吧。