程序员该有的态度~

总结五年来的工作经验，记录一些职场态度，大概可能会让你的业务能力迅速提升，大概可能会让你的bug更少，大概可能会拿到自己想要的绩效，大概可能可以在职场上坦荡的生存下去。。。。。

1、对待UED/设计师：宠 

设计师说要这个看起来复杂酷炫好像要调到天荒地老的动画，那就给！

设计师说要调整颜色，边距，一切你感觉没啥必要的，也给调！

当然，一切建立在可执行前提上哈～其实如果是长期做业务的小伙伴，大概都有个共通的认识：动画不好搞，UI最难调。但是其实相比较而言那就是，业务逻辑代码很简单明了，只要你把握好逻辑，处理好生命周期，规范好自己的代码。几乎一切都是行云流水般顺畅，只有当你实现复杂的交互的时候，不断的去优化渲染，解决延迟，解决异步等等问题时候，才会陷入焦头烂额。但，注意，客户端包括前端都是UI首当其冲，如果你通过一次又一次的在复杂交互中挣扎，也就促使你一次又一次去深挖系统组件的底层逻辑，甚至延伸到更多的层面。那你的水平，至少会上很大一步。目前为止，我跟交接过的设计师关系都很好，他们也更爱我（可能因为我是个酷girl？）。因为我几乎不会对他们的要求说不，都是仅最大努力去实现。同时，如果交互在用户那里得到了好评，归功于的是开发和设计，但是如果交互很烂，背责的大部分是开发了。

2、对待需求/产品经理：质疑

几年观察来看，很多程序员是需求说什么，PRD写什么，我就做什么。完了一提测，各种问题。我们在评审需求阶段，给自己的角色应该是半个产品，这一半站在用户和产品的角度考虑需求的合理性，前后的粘合性等等。另外半个角色就是开发，实现的成本，扩展性和可维护性。这个质疑的态度是贯穿整个开发迭代的，作为开发，当然是产品说什么，开发做什么，但是前提是产品说的有理有据，如果天马行空（当下社会可能不敢有这样的产品经理了），如果前后需求矛盾。那第一时间把控住的就是开发这里。如果需求有不合理，但开发却执行了下去，出现逻辑漏洞，那整个锅你不背一半都对不起我们背锅侠的称号。

3、对待测试：信任

这个还是建立在靠谱的测试，如果不靠谱，一次两次都是自己的操作问题的话，那我们每次质疑bug的由来也是有理由的。一般靠谱的测试在把问题归到你这里的时候，他们自己是做了验证的，最起码基础的验证是做了的，达到了百分之八十的可能性是你的问题，才会开bug到人。测试也很难做，这个我们大家伙也都心知肚明，谁愿意做给别人泼冷水的人呢，所以他们是专业的，我们能给予的就是信任。问题到我，初步判断就不能断定不是自己的问题的时候，就要开始认真对待，先确定场景，一步步追踪。我认识的大多数开发都有个通病，很自信，总觉得bug不是自己的。第一反应就是先找是不是别人的问题。其实这样就已经让你丧失了最快解决问题的时机。还好，目前为止，跟测试的相处也很融洽，从来没有急头白脸的时候。

4、对待组内成员：无保留

以前我总认为，勾心斗角不属于我们开发身上的标签。后来证明，确实不太是，但是互相推卸甩锅的大有人在。一些自以为是的经验开发会自发站在高处，还没搞清楚代码就觉得是别人的问题。所幸的是，程序员，一般是单纯的，不会玩阴暗职场那一套，甩锅给你也是明目张胆的甩，只是最后我们可以通过debug等来证明。证据到位，啥事没有。而且我们的证据都是实实在在的代码和提交记录，一眼明了没啥可说的。所以，跟组内成员的相处之道就是要对所做过的毫无保留。当然我觉得谦逊在什么场所都是可行的，谦逊却不卑，自信却收敛。你怀疑是我的问题，没问题，我们一起找证据，是我的，我道歉，影响到你的模块是我的过失，公诸于世，证明你的清白。不是我的，我也不恼怒，因为没人喜欢飞来横祸。😄，工作那么多年，遇到过几个试图在没确定之前把我推到风尖浪口的人，记住，这种时候，无需惧怕，先承认，可能是我的问题，我来看看。如果真的是你的问题，大家也会觉得你态度良好，不会有较坏的印象，毕竟人无完人何况坑爹的代码和系统。不是你的问题，那就是反转了，扣给你的小伙伴就会被大众一次又一次的加深不靠谱的印象。这些都是建立在不好的现象上啦，当然希望大家坦诚相待，也就没有后面这些推理和影响。

最后，希望大家在日复一日的打工人生活中，找到成就感，找到自我，找到你想要的职场，挣到你想要的钱～