自己明显感到这些内容给自己带来的麻烦，已经不止一次地重复修改一处很小的样式问题，可能你会觉得这样根本体现不出一个程序员的才能，其实，能按照需求写 出正确的逻辑的确是一件让人很爽的事儿，但其实如果站到应用程序角度来看的话，统一的标准和样式同样是决定一款应用程序成败与否的重要因素，有的时候甚至 超过后台的实现，因为用户看得到摸得到的对他来讲往往更加重要。

    能从不同的方面让自己来加深自己对软件开发的理解，这就是一次很棒的机会。

    与此同时，团队协作管理在项目进程中的作用体现的更加明显，因为这关乎我们每个人每天的工作内容和质量，有一些小的方面，虽然是众人皆知，但落实到自己头上同样是一件很困难的事儿，这里暂作记录，也是希望自己能够做的更好：

（1） 代码签入要填备注：基本到基本的一条原则，好处不言自明，尤其是当团队成员较多的时候，清楚的注释能够快速定位一些因交叉签入和测试不彻底造成的bug。尤其要注明多个版本同时更新时的同步信息，尽量保证关键信息，如版本、bug号等的完整。

（2） 签入代码前请先获取最新的版本：很容易被忽略的一点，因为很有可能你的同伴也在修改同一个文件，此时，如果你没有获取最新的代码，就匆忙地签入，是非常有可能在比较版本的时候漏掉冲突的地方，而直接签入的，导致同伴的代码被覆盖。

（3） 签入代码前后均要对功能进行验证：嵌入前必须保证代码的正确性，这个不用说，嵌入后，重新获取版本，再次编译并验证，有的时候是非常重要的，这样可以避免我们因为签入失误造成的问题，同时，这也是为了保证服务器上的代码是正常可编译的。

（4） 及时汇报自己的工作进展情况：我们可以每天早上把今天的工作做个简单的计划，然后在下班前把今天的工作 内容做一下小的总结，并抄送给领导，很多时候因为不知道要写啥，或者可能一句话就能说清楚，我们就不愿意去做这个简要的汇报，有的公司会要求大家每周做汇 报，但自己还是觉得每天有个开始和总结，不仅能够让自己对任务更加清晰，同时也可以加强自己和领导间的沟通，何乐而不为呢？

（5） 修改公共代码后请进行全面测试：这个也是毋庸置疑的，因为公共代码牵扯的内容可能很多，如果我们只测试 我们预期效果的那部分功能的话，很有可能是正确的，但其他地方可能就会出现问题！这个几率是非常高的，所以建议我们能够慎之又慎地修改公共代码，如果没有 把握，请尽量通过复制功能代码的方式来通过增加冗余，避免影响其他内容。

（6） 动手编码前请先和相关人员再次确认需求或bug详情：很多的问题其实改起来并不麻烦，但是如果要是因为理解的不一致造成的改来改去，这个是最折磨人的，所以，必须双方都完全确认后，再动手！切忌不要擅作主张。

（7） 经常主动地去和别人进行Code Review：有很多我们固有的不良编码习惯，或者一些我们不熟悉的内容，这些都是我们很难观察到，但我们的同伴可能一眼就能看到的地方，有交互才会有学习，多去理解和学习同伴的好的编码习惯和思考方式，对我们来说这是最容易的一个途径。

（8） 永远不要轻视自己手中的工作：这就像一条充满魔法的诅咒，没有人能逃脱它，所以，千万不要因为轻视一件任务，而延时去做它，否则你会加班到很惨。

（9） 不要偷懒去拷贝代码：现在很多的代码都是我们拷来拷去，但是，因此而遇到的很多问题又多少次让我们几乎抓狂？拷代码不但不能增加我们对代码的理解，还是引入错误的一个主要来源。必须明令禁止！

（10） 在对工程进行改动前，请先确保该功能点已经可以正常工作：很简单，不要随随便便在项目中直接修改功能，尤其是一些新的功能，请先在自己的示例工程中先保证功能的正确性，然后再进行移入，这样会给我们节省很多的时间，不信你试试！

（11） 合理安排工作中的“空闲”时间：所谓“空闲”时间，即在不同项目间或者是在同一个项目不同阶段之间的 短暂的中场休息时间，还有就是当项目后期，集中处理bug的时候，可能会偶尔出现的一些工作真空期，这个也算是做软件行业的一个常见情况，时忙时紧。的 确，我们可以充分利用这些时间来休息，但是如果我们能稍加利用，则会让我们有更大的进步，比如研究一下一些系统中的疑难杂症，学习一些新的技术，看看管理 方面的书籍，最差劲还可以看看别人写的代码长长见识。

（12） 记录工作中的点点滴滴：所谓积少成多，再大的成就也是一点一点攒起来的，我们的个人发展也同样离不开这个原则，对于我们日常遇到的一些技术难题，管理经验，甚至是自己的心得体会，如果能够记录下载，甚至慷慨地拿出来和大家分享，那我们将收获更多意想不到的东东。

    目前，自己就想到这么多，自己虽然也尚未全部做到上面所述，但也正在努力中，这里权作记录，以提醒自己，希望能对大家有所帮助。