什么样的编程姿势才没有bug

比眉伴天荒 2022-05-18 02:48 202阅读 0赞

工作中，我们总会遇到这样那样的的问题，  
以下的问题是我分析上家公司和这家公司总结出来的，不喜可喷，我会假装看不见，哈哈！  
**目录**

*  一般bug产生的原因有哪些？ 
 *  什么样的编程姿势才没有bug 
    
     *   *  1. 制定合理的开发排期
         *  2. 合理招聘团队技术人材
         *  3. 制定团队协作表
         *  4. 强制要求自测
         *  3. 后端开发一定要能本地运行最新的前端代码
         *  4.技术负责人还得多做的一些事儿
         *  5. 技术领导一定要是最有责任心和积极的一个人
         *  6.利用post man批量测试
         *  7. 培养员工主人翁意识
         *  8. 招一个有软件设计思想的产品

# 一般bug产生的原因有哪些？  #

*  开发时间紧，开发不注意细节上问题
 *  团队整体能力有待提高
 *  领导不合格
 *  员工太懒、主人翁意识不强
 *  沟通不到位
 *  产品设计不合理

# 什么样的编程姿势才没有bug  #

--------------------

### 1. 制定合理的开发排期 ###

开发时间在影响开发质量上，绝对排得上第一。但要记住，非技术领导参与排期是大忌。  
**接口排期**：我见过的项目和听过的一些朋友的项目基本都是按这种方式排的。这里的排期包括客户端与服务端

<table> 
 <tbody> 
  <tr> 
   <td><font>难度</font></td> 
   <td><font>开发排期</font></td> 
   <td><font>说明</font></td> 
  </tr> 
  <tr> 
   <td>容易</td> 
   <td>3个/天</td> 
   <td> 一般是指只查单表的下拉列表</td> 
  </tr> 
  <tr> 
   <td>中等</td> 
   <td>2个/天</td> 
   <td>一般是指多表联查，需要掌握的产品逻辑比较宽泛</td> 
  </tr> 
  <tr></tr> 
  <tr> 
   <td>难</td> 
   <td>1个/天 ~ 1个/周</td> 
   <td>一般是指不仅需要掌握宽泛的产品逻辑，代码里也需要作复杂的计算与判断</td> 
  </tr> 
 </tbody> 
</table>

有些朋友会觉得，实际写接口可能要不了那么多时间，其实我也是这样认为。但为什么还是要这样排呢？这是因为，写接口稍复杂点儿的调用通过只是第一步，我们写完接口后返回数据让前端人员调用后，我们还需要针对我们的接口作全面的考虑，即**自测**。比如**边界测试**、**权限测试**、**根据不同业务试**等等。如果自测很负责任，你甚至会发现，这点儿时间完全不够。

### 2. 合理招聘团队技术人材 ###

技术人材，不止决定了项目的质量，还决定了项目进度。

项目的进度上，基本上是前后端一起完事，一般也只差在一天左右。如果相差太多，是有问题的。比如前端抱怨说是后端接口没有出来，那就说明是项目管理没有做好，因为这种事是可以避免的。比如，在后端刚开始写接口的时候，前端可以先写静态页面，或者前后端先定义数据返回格式，前端自己组装假数据。

团队中的技术不一定要都是牛人，而是合适的人。从接口排期可以看出，很多活是比较简单的活，刚毕业的学生也能完成的很好，有些活需要一定的经验。个人认为一个完整的团队基本上是：**1位负责任的资深技术+1~2个有经验的中级开发+2~4个好学的初级开发**。前端和后端基本上都需要种阶梯式的人材，我记得我来公司的时候，前端没有一个经验丰富的人，总的来说还不如我一个后端，我天天写完后端接口，还得跑去写前端代码，那绝对是一个黑暗的时代啊！！！！也许领导最初的想法是为公司省钱吧，加上那段时间也招不到好的人材。

### 3. 制定团队协作表 ###

排期排完了，给大家分配好工作后，一定要制作一张表，让整个团队都知道前端和后端每个接口和功能是谁在负责，这样大家在有问题的时候，第一时间就知道去找谁。我在项目中经常会听到有人问，这个是你做的吗？别人回答不是，然后又去找另一个人。你去打扰人家一次，另外几个人又去打扰人家一次，然后人家又这样来回打扰你，一来二去，增加沟通成本不说，一看就是个乱烘烘的团队氛围。

### 4. 强制要求自测 ###

自测，是开发人员最基本的素质。在团队中，你会发现有些人写完代码就觉得自己完事了，还觉得自己代码效率高。在之前的公司遇到一位小伙伴，他开发速度是最快的，而bug也是最多的，以至于领导会经常让我给他审查代码；甚至有时候他不会写的复杂代码也悄悄让我帮他写。我总是本着一个团队的想法一次次帮了他。  
自测这个东西，责任心强的人一般做得比较好。团队中态度懒散、与世不争的人一般做自测比较敷衍，类似这种人只有责任化，出了bug作出相应的小惩罚才行。上家公司凡是在验收时出现一个bug，就要请所有开发吃雪糕，不幸的是，整个华为音乐相关系统做完也就吃了人家一次雪糕。

### 3. 后端开发一定要能本地运行最新的前端代码 ###

现在的项目基本上都是前后端分离的模式，如果出现了一个问题，但又不知道问题在哪，这时可能就需要前端和后端一起配合排查。但是，在开发过程中，所有人都比较忙，前端可能会觉得问题是后端导致的，跟他毛线关系没有，要他花费时间配合后端，他心里会很不爽，如果真的是后端的问题也确确实实是浪费了他的时间。所以这时就需要后端拿到前端代码进行自测，不至于同时浪费两个人的时间。这就需要前端将代码上传到公共服务器，后端开发人员pull之后，将IP改成自己电脑的服务器，本地运行起来后，然后一个人安静的找问题。如果问题找确认是自己的，就悄悄的改了；如果是前端的，可以高调也可以低调的说是前端的问题。

### 4.技术负责人还得多做的一些事儿 ###

1.  公共代码比如分页、异常的封装处理。一定要和整个开发团队说明怎么用。
2.  代码风格及要求，开会给整个团队说明。
3.  有什么影响其他人的变更一定要及时告知整个团队。这个坑我可是遇到过，比如字段变了、换表了

### 5. 技术领导一定要是最有责任心和积极的一个人 ###

技术团队的整个想法，基本上是技术领导的想法。如果领导都得过且过，那下面的人基本也就那样了。

### 6.利用post man批量测试 ###

我们经常会遇到这种情况，发现一个bug，然后费老劲了去改，终于解决了这个问题，测了测发现没问题然后就上线。上线没多久，又出现了另外一个问题，一查，居然是上一次改bug后，影响到另外的接口了。但接口那么多，时间又紧，总不能每改一个问题都手动去点其每一个接口吧，这时我们就可以利用post man的集成测试，自动将跑完所有接口，然后查看是否有接口有问题。

做这件事的前期就得需要前期开发的时候用post man规范化测试。

### 7. 培养员工主人翁意识 ###

公司之前有个外包团队，合作了近一年的时间。他们的开发团队有个两个最大的问题，一个是领导对下面的技术要求过低，另一个是下面的人总认为自己是在给别人干活。因为是给乙方干，整个团队天然都会有这种给别人干活的意识。其实自己公司的人，也会有些人觉得是在给别人打工，活是别人的，干得好坏与自己无关。

怎样才能有主人翁意识？其实人的行为会受到自身利益、想法、人生态度等很多影响。要想一个人主动做事还特别上心，那么就要让这个人成为这件事的利益共同者。

从我自己来说，我做事之所以一直秉持着积极、主动、负责任的方式，是因为我从希望自己有个好的做事态度，我觉得这会是人要成功的必要因素。即使我多次因为公司的某些事想离开的时候，我也会坚持这样做。当然我加班就没那么积了，哈哈，其实还有是因为我做了手术后身体不允许我强撸代码了。虽然我不善于交际，能力也一般般，但我一直希望我以后能往更好的方向发展，所以我也会很努力的去做每件事。归根结底，我把这些与我未来的成长、习惯养成看成了一种利害关系。我经常和我的小伙伴说，我们虽没那么高尚的说是为了公司把代码写好，但我们要为自己养成一个好的习惯和态度以及能力的提高而去把事情做好。

虽然我也是打工的，但从客观角度看，有些员工如果是以奖励的方式让他把一件事干得更好，似乎作用不大。是什么原因呢？这是因为你会发现人天生就懒、爱玩儿，当一个人家里不缺钱花，没有什么压力的时候，领导拿一点儿奖励去换他本可以玩手机的打游戏的时间，似乎根本不可能。不过在中国，有钱人还是少数，哈哈。

### 8. 招一个有软件设计思想的产品 ###

我遇到过最好的产品，是技术转的产品；就像我遇到过最好的前端是后端转过去的一样。

一个好的产品，不止要能提炼用户真正的需求，还需要知道避免设计一些常规的影响系统性能的需求。为什么很多开发都会觉得产品的钱真是拿得太轻松了，是因为产品做的事，开发只要简单学习一个礼拜之后，也能叫产品。

毕竟从技术转产品的人也不是那么的多，所以产品人材的招聘上，经验是非很重要的。因为他们在经历了多个项目后，被开发怼的次数多了，慢慢就总结出哪些设计方式是对整个软件设计是不利的。如果产品在源头就犯了错，那后面的开发、测试是要付出更多的代价的。

开发其实就是产品的第一个用户，当开发都很难理解需求时，用户会很轻松理解？开发至少是完全参与着整个产品。如果产品设计连开发看着费劲，那么代码写起来肯定也费劲，bug的出现率自然也大不少。等大家辛辛苦苦的开发完，基本用户一反馈就是搞不懂，什么玩意儿，骂两句就不想用了；然后等来的就是，产品重新设计、开发重新加班干！！！