关于团队成员之间协做的一点感悟

 

我之前作什么都喜欢一我的，静悄悄地，谁都不鸟。工做了以后更多的是团队协做，十几我的的项目组和十来我的的部门都待过，打过交道的人多了以后对人与人之间的合做关系就有了一点点感悟，特此作一下总结。

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

 

关于BUG

现代软件都是多个工(wu)种(zhong)之间互相配合协做开发的，既然哥几个搭伙儿搞事情，事情搞多了，就不免有搞砸的时候，当事情搞砸出现问题的时候应该如何处理呢。

 

通常解决问题的两个步骤：

1. 排查出问题出在哪里（打开冰箱门）

2. 给出解决方案，执行并观察结果（把大象塞进去关上冰箱门）

 

第一步，排查出问题出在哪里，这一步是容易致使内讧的地方，没人愿意认可本身的东西有问题，可是争吵是解决不了问题的（武力更不行...）。以前跟测试打交(si)道(bi)的经历告诉我，靠吼是没有用的，遇事必定要讲道理，只有拿出证据才能让人信服。

1. 不带我的感情，有一个现象就是当咱们对某我的的某个行为看不顺眼的时候，慢慢会演变为对这我的整我的的否认，平时可能还看不出来，当遇到问题的时候就很容易被误导产生偏激的想法。

2. 属于本身职责范围内的事情，当别人提出质疑的时候，应该本身证实本身是没问题的，而不是让别人来证实你是有问题的。

3. 若是证实确实是本身的问题，坦然认可并修复它，不准内心明知道确实是本身错了还死要面子梗着脖子嘴硬（我也有过信誓旦旦嘴硬的时候被铁通常的证据啪啪打脸....~~o(>_<)o ~~）。

4. 无论写的是代码，仍是脚本，关键操做什么的都要多打log，log能够避免不少无心义的争吵，log让生活更美好（Axure是产品经理的利器，log是程序员的利器）。

5. 必定要博学，拥有必定的广度和深度，当你对某个东西不是很熟悉的时候，人家说啥你也很懵逼，就很没有底气，因此说人丑就要多读书是有必定道理的！

 

第二步，给出解决方案，执行并观察结果

1. 谁污染，谁治理。谁搞出来的问题谁负责修复它，一个是这我的比较熟悉，修复起来成本比较低，另外一个就是培养责任感，如今不少程序员都缺乏责任感。

2. 解决方案要公开，透明，别藏着掖着只说修复啦，到底怎么修复的啊，拿出来给你们看看科学不，万一有明显漏洞也能及早发现避免bug reopen。

 

 

关于联调

1. 本身作的东西，起码要自测一遍确认没有明显问题再交给对方，这是对合做伙伴的基本尊重，不要传个还有语法错误的文件说搞好了。

2. 若是是作前端的，页面写完了作点假数据，本身点一点，多用几个浏览器测一测，server url要统一在一个地方配置，不要好几个地方搞的人家部署的人头都大了。

3. 若是是写后端接口的，应该出一份接口文档，此文档以实用为主，哪一个接口，接受什么参数，参数数据类型，是否必选，默认值是啥，接口请求的样例数据，接口响应的返回样例，返回字段解释等等。

4. 若是是传统型软件，计算任务（日期格式化之类的将原始数据转为对用户友好易读格式的计算任务）放在后端没问题，可能后端处理确实要方便一些，但若是是高并发型项目，服务器资源很宝贵，应该尽可能将计算任务往前移，缘由是显然的。

 

 

 

最后，学好Linux很重要！学好Linux很重要！学好Linux很重要！

道理都懂，仍是作很差.........

 

 

。