标签：也有 结果 另一个 pen 应该 计算 导致 广度 没有
我以前做什么都喜欢一个人，静悄悄地，谁都不鸟。工作了之后更多的是团队协作，十几个人的项目组和十来个人的部门都待过，打过交道的人多了之后对人与人之间的合作关系就有了一点点感悟，特此做一下总结。
-----------------------------------------------------------------------------------------------
现代软件都是多个工(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很重要！
道理都懂，还是做不好.........
。
标签：也有 结果 另一个 pen 应该 计算 导致 广度 没有
原文地址：http://www.cnblogs.com/cc11001100/p/7352268.html
