心态一：本着多一事不如少一事的原则，发现这些坏味道，只要不影响自己负责的模块，就不提出。但在本地有记录，此处可以如何如何改进，等以后告知相关模块负责人。
心态二：本着精益求精的原则，也可以说是程序员洁癖，看到一些不合时宜的代码，则要对外抛出，主动给自己或其他人找事做。
心态三：本着投入产出比来说，要看情况抛出。比如，重构这块代码能够带来显著的效果，并且自己已有一套重构方案，那就可以提出，如果这块代码不痛不痒，而当前有更重要的工作要去做，那就视而不见。
这三种心态，没有绝对的对错，不同人有不同的看法，执行不同的选择吧了。
这里面抛出的意思时，把准备要改动的范围提出，改动带来的好处和可能的影响也一并提出，至于具体要不要完成，不是重构实施者来决定，而是有团队小集体来决定。
自己的体会，写代码是创造，改代码是修补，读代码是吸收。我们的大部分时间都花在了读代码和改代码上。产品人员提需求，开发人员提重构，测试人员提Bug。
当发现现有软件的Bug时，整理清楚问题复现的路径和环境，告知测试人员，让他们推送Bug的产生。如果发现问题出现在自己负责的模块，那么理所应当要修复它们，这里不是指的马上修复，而是将可复现的路径告知测试，提Bug单后，照单修复。做到在SVN上的每一次提交，都有对应的Bug单、需求单或者重构优化单，这些单才是开发对接产品、测试和运维的依据。
针对关键组件，可以由老带新，以结对编程的方式，传承经验。
对于重要的修改，可以用patch的方式先做做code review，确认无误后再提交。
每个具体模块都要有模块责任人，每个人对自己的模块负责，当其他模块出问题时，直接告知对应责任人即可。可将每个人与负责的模块汇总成表格，给测试或者是其他团队成员来查看，方便测试人员快速对接问题的开发人员。
周报管理在每周的工作总结，不仅仅要写已完成的工作内容，哪些未完成的工作，遇到棘手问题的工作内容更加有记录价值的。自己针对该问题和哪些人有讨论，分析遇到的问题，这是对自己工作的总结。
一项任务进度的描述，不能只有未开始和已完成两种状态，在汇报任务进度时，先要将任务分解为若干子任务，目前已经完成了哪些子任务，还剩下哪些子任务待完成。
在指定年度工作计划时，个人工作目标需要和团队（或者说是部门）的目标一致。
比如说，部门目标是注册用户量过20W，每天交易量要保证是5亿，那么对于负责交易模块的同事，要围绕上述目标来设计。工作内容职责范围均以此为依据，对于其他技能的提高，也要结合当前工作职责来描述，为了更高效地完成工作任务而学习，不要脱离工作职责范围而去胡乱学习，切记写些个人爱好学习之类与工作不相关的内容，这会让审阅者认为你在不务正业。记住，公司不是请你来学习的，而是要你来解决问题的。
在梳理工作小结时，需要有逻辑条理，不能一上来就写你完成了什么功能，还有那些功能没有完成，让别人一下子进入太具体的工作细节描述，很容易绕晕的，不好从更高层次看清你目前工作的全貌。可以按照总分总的逻辑顺序来整理工作内容和工作完成情况。
放权问题合理放权是很重要的。一般来说，一个人可在直接高效管理6个人，对每个团队成员能够很好管控。随着团队规模扩大到12个人，事必躬亲就略显吃力，各个员工管理起来开始困难，当规模快接近20人时，如果管理者还想着每天和20个人都有技术和项目的交流，几乎是不可能的。所以，管理者要善于发现下属中是否有职业规划走技术管理、项目管理的员工，有的话，注意及时给与机会成长，这样一来，既可以建立层级梯度团队，又可以留下优秀员工，同公司一同成长。
做领导要合理放权，也要用于承担责任。
在此分享一篇好文章：IT小团队管理者的突围之道
技术思维技术思维是总从技术的角度去考虑事情，凡事必追求确定性，容不得半点含糊，一是一，二是二。而真实世界的事情不是if-else或者 switch-case就可以解决的，往往存在权衡和取舍。没有完美的解决方案，只有针对当前场景最适合的解决方案。比如产品经理提出了一个对用户很有价值的事情，但是从技术角度上面去实现，会很复杂，这种情况下，如果技术人员不考虑实际用户的需求，以实现复杂性或者影响框架等作为简化需求的理由，就是典型的技术思维，而不是产品思维。技术人转行做产品经理的，技术是他的优势，如果摆脱不了技术性思维，那么将会极大的制约产品的发展。