Code Review

Code Review 很有必要，在Code Review时，要按既定的原则与目标进行，不炫技，不挑刺，找出代码的缺陷和需求理解不到位的地方，相互学习代码设计与思路。

要做到对每个人的每次提交都做严格的code review机制，这需要一个强大的制度流程保证和团队leader的主力推进。否则很难在实际工作中推行。

关于这点，我有一个思路，在每周四下午，进行集中式的code review，抽检范围为上周四至本周四，对提交记录中随机挑选3条，先由对应提交者讲解，然后大家针对本次提交，提出各自的观点看法，具体可从以下几个点来展开：

• 判断提交类型，是Bug单、需求单还是优化单？
  • 若是Bug单，则要理清Bug的产生链条，修改的思路和影响分析
  • 若是需求单，则需要讲解自己对该需求的理解，完成需求的任务分解和基本解决方案。
  • 若是优化单，则要讲解优化的动机、具体手法和影响范围。

其他同事可对讲解者的当前做法提意见，若没什么意见，老员工可就业务流程进行一些适当的延伸，不管是技术原理讲解，还是业务规则梳理，都可以。整体时间控制在1小时左右，每个commit平均分配20~30分钟即可。

每两周一次业务分享，可以是新技术研讨，也可以是现有架构介绍：团队定期进行新技术的研讨，保持对新技术和新业务的敏感度，业务分享需要提前一周确定分享主题。这个可以和code review每周交替进行，一个月四周，两次code review，两次业务分享。

团队协作

当使用他人提供的接口或者模块时，如果现有功能不能满足自己的需要，即使可以看到他人的具体流程（有源码的情况），也不能去贸然去修改，要将改动的动机以及自己的看法通过邮件或者QQ截图传达给原作者，让他去评估是否做修改。回到自己的工作上，可以自己组合接口基本功能，提供函数来满足自己的需求。

不是所有的Bug的最终走向，都以修复为结束，对于那些暂时不予修复的Bug，需要和产品、测试沟通确定后，将结果落在Bug单中，以备查验。

接收其他部门发来的设计文档、接口文档等原始文档，一定要纳入本地的版本管理系统。纳入版本管理后，才能走下一步。
一定不能去改动原始文档，因为一旦有修改，那么该文档的有效性就由其他部门转给你身上，以后由该文档的错误导致的问题，也会归责到你身上。如果觉得有必要将分散在各个文档的零碎信息汇总到一起，那么，自己应该在本地建立汇总文档，不要将自用的汇总文档覆盖原始的接口文档。

跨部门的协作，如果别人通过群发邮件来咨询问题，当自己知道解决答案时准备回复，需要群发回复，让每一个接收者都知道该问题已经得到解决，以防其他人浪费精力解决已解决的问题。

在实现功能时，有一些细节地方，在需求文档里面没有明确指示的，在A做法也行，B做法也行的时候，一定要向产品经理提出疑问，等待反馈后，将得到的反馈到JIRA需求单例去，根据JIRA需求单来做,做到凡是修改要有记录和可回溯性。

在团队合作中，作为基层员工，你只需要对你自己负责的模块负责。在平时开发工作中发现其他模块的坏味道时，不要想着自己发现别人的问题，然后尝试偷偷地去解决这些问题。这里犯了大错，错在不通知他人的情况下，擅自改动他人代码。
自己的贸然改动，修好了，没有人会知道你的劳动成果，修的不好，一旦发布后出去问题，层层追责后定位到是此模块的问题，这就会你带来不必要的麻烦，即便出现的问题不是因为你的修改直接造成的，但因这其中有你的改动，就不好说清楚因果关系，自己曾经犯过这类错误，以后必须时刻谨记，谨记。不要自作聪明。好心办坏事。

从开发者的角度来看待改动，除非改动的影响范围极其有限，否则是无法拍胸脯保准自己的修改不会带来任何问题，就算是增加一行空行，也无法确保。
对于测试人员来说，开发的任何修改对他们都是黑盒的存在，是不可信的，即使开发说本次改动只影响某个模块。在团队作战中，自测是对开发人员最为基本的要求，除了自测之外，还要让测试人员知道我们所做的修改影响的模块或者范围，不能闷头做事，自己提交代码一时爽，测试人员两行泪。

重构时一定要有边界，做什么，在哪里提交，分几次提交，在哪里记录，在哪里反馈等等，在这里，不谈具体重构手法，而谈谈重构的一些注意事项。

当自己发现其他人代码（亦或是自己的代码）中一些坏味道、腐朽的迹象时，心里动了重构的念头，此时，有三种心态：

心态一：本着多一事不如少一事的原则，发现这些坏味道，只要不影响自己负责的模块，就不提出。但在本地有记录，此处可以如何如何改进，等以后告知相关模块负责人。

心态二：本着精益求精的原则，也可以说是程序员洁癖，看到一些不合时宜的代码，则要对外抛出，主动给自己或其他人找事做。

心态三：本着投入产出比来说，要看情况抛出。比如，重构这块代码能够带来显著的效果，并且自己已有一套重构方案，那就可以提出，如果这块代码不痛不痒，而当前有更重要的工作要去做，那就视而不见。

这三种心态，没有绝对的对错，不同人有不同的看法，执行不同的选择吧了。

这里面抛出的意思时，把准备要改动的范围提出，改动带来的好处和可能的影响也一并提出，至于具体要不要完成，不是重构实施者来决定，而是有团队小集体来决定。

自己的体会，写代码是创造，改代码是修补，读代码是吸收。我们的大部分时间都花在了读代码和改代码上。产品人员提需求，开发人员提重构，测试人员提Bug。

当发现现有软件的Bug时，整理清楚问题复现的路径和环境，告知测试人员，让他们推送Bug的产生。如果发现问题出现在自己负责的模块，那么理所应当要修复它们，这里不是指的马上修复，而是将可复现的路径告知测试，提Bug单后，照单修复。做到在SVN上的每一次提交，都有对应的Bug单、需求单或者重构优化单，这些单才是开发对接产品、测试和运维的依据。

针对关键组件，可以由老带新，以结对编程的方式，传承经验。

对于重要的修改，可以用patch的方式先做做code review，确认无误后再提交。

每个具体模块都要有模块责任人，每个人对自己的模块负责，当其他模块出问题时，直接告知对应责任人即可。可将每个人与负责的模块汇总成表格，给测试或者是其他团队成员来查看，方便测试人员快速对接问题的开发人员。

周报管理

在每周的工作总结，不仅仅要写已完成的工作内容，哪些未完成的工作，遇到棘手问题的工作内容更加有记录价值的。自己针对该问题和哪些人有讨论，分析遇到的问题，这是对自己工作的总结。

一项任务进度的描述，不能只有未开始和已完成两种状态，在汇报任务进度时，先要将任务分解为若干子任务，目前已经完成了哪些子任务，还剩下哪些子任务待完成。

在指定年度工作计划时，个人工作目标需要和团队（或者说是部门）的目标一致。
比如说，部门目标是注册用户量过20W，每天交易量要保证是5亿，那么对于负责交易模块的同事，要围绕上述目标来设计。工作内容职责范围均以此为依据，对于其他技能的提高，也要结合当前工作职责来描述，为了更高效地完成工作任务而学习，不要脱离工作职责范围而去胡乱学习，切记写些个人爱好学习之类与工作不相关的内容，这会让审阅者认为你在不务正业。记住，公司不是请你来学习的，而是要你来解决问题的。

在梳理工作小结时，需要有逻辑条理，不能一上来就写你完成了什么功能，还有那些功能没有完成，让别人一下子进入太具体的工作细节描述，很容易绕晕的，不好从更高层次看清你目前工作的全貌。可以按照总分总的逻辑顺序来整理工作内容和工作完成情况。

放权问题

合理放权是很重要的。一般来说，一个人可在直接高效管理6个人，对每个团队成员能够很好管控。随着团队规模扩大到12个人，事必躬亲就略显吃力，各个员工管理起来开始困难，当规模快接近20人时，如果管理者还想着每天和20个人都有技术和项目的交流，几乎是不可能的。所以，管理者要善于发现下属中是否有职业规划走技术管理、项目管理的员工，有的话，注意及时给与机会成长，这样一来，既可以建立层级梯度团队，又可以留下优秀员工，同公司一同成长。

做领导要合理放权，也要用于承担责任。

在此分享一篇好文章：IT小团队管理者的突围之道

技术思维

技术思维是总从技术的角度去考虑事情，凡事必追求确定性，容不得半点含糊，一是一，二是二。而真实世界的事情不是if-else或者 switch-case就可以解决的，往往存在权衡和取舍。没有完美的解决方案，只有针对当前场景最适合的解决方案。比如产品经理提出了一个对用户很有价值的事情，但是从技术角度上面去实现，会很复杂，这种情况下，如果技术人员不考虑实际用户的需求，以实现复杂性或者影响框架等作为简化需求的理由，就是典型的技术思维，而不是产品思维。技术人转行做产品经理的，技术是他的优势，如果摆脱不了技术性思维，那么将会极大的制约产品的发展。

多向身边各行各业的人学习，多接触别的领域，很多时候在你没接触之前就贸然说自己不感兴趣，来不了之类的话，那只是你在未你的懒惰找借口而已，只有接触过，亲自尝试才有资格说不感兴趣。

管理者视角的期望

在工作中，我隐约感觉到，如果是从领导者的视角出发，一个听话、可控的下属比一个厉害、总是做一些不可控事情的下属更加可靠。老师喜欢听话的乖孩子，医生喜欢配合的病人等等，道理都是相同的。

因此，领导不要求下属有多厉害，而是要求下属在领导可控的范围内，干明确的、可控的事情。就像都是本领高强的人士，二郎神和孙悟空就代表了两个极端。可控意味着结果可控，即使结果未如人意，领导也能够承担下来。最怕那些愣头青，不清楚影响范围的改动，会给其他人员带来极大的心理负担。

在平时的工作中，当遇到的问题时，自己要将尝试的解决方法以及各种方法的解决结果，梳理清楚，如果一两天还是无明显进展，需要及时反馈上级，让上级知道下属当前走到的哪一步，碰到的哪些问题。作为上级，他能够给予哪些帮助和指导，让他有参与感进来，而不是让下属一个人努力完成所有工作。

在职场中，做的多，并不一定意味着做的好，如何有效的汇报自己的成果，是需要反复斟酌、思考的。要做到能力比薪水高一点点，就要事事超出老板的期待一点点. 预知或者预设老板的期望值，然后超越它，这就是向上管理中的重点。

在平时的工作中，除了完成自己本职工作外，也要善于发现现有项目、团队中一些有待改进的地方，多观察，多思考，多交流沟通。有一些工作可以先做一部分，初步整理形成可行方案，准备怎么做，预计多长时间，影响的范围有哪些，带来的好处和坏处有哪些，把这些权衡点一一分析梳理清楚后，在合适的时机向领导提出，如果领导支持，可以申请资源来协助自己进一步改进完善，如果领导暂时不同意，那这个想法暂时按下不表，等待时机。

反思

没有总结和反思，经历永远不能成为经验，看别人的总结反思像是在看电影，看的时候很爽，看完一抹黑，能记住的不多。很多坑，非要自己跳进去挣扎一番后，跳出坑后，这些总结反思才会深入骨髓，帮助自己以后不再犯类似的错误。

在任何工作中，要想成为专业人士，必须要掌握一套良好的做事方法和工作习惯，而这些做事方法和工作习惯，一方面通过自己在工作中不断踩坑、反思、总结，来迭代成长，这样获得的经验教训，往往比较深刻。

还有一种是有一个好的导师来带你，时不时给你的工作上给与指导，指导肯定是有依据的，因此，如何提供这些依据，就显得较为重要。这里面有两个细节：

第一个细节：自己在完成一项任务时，要记录自己在完成这项任务时遇到的问题，自己尝试的解决方法以及最后采取的解决方法，将这些工作过程有条理的汇总记录，作为导师给与指导的依据。

第二个细节：在向上级汇报时，要主动将工作记录给上级过目，同时，向上级提出要求，看自己在本次工作过程中哪些地方有改进的空间和地方。