小故事【持续更新。。。】

1、MD5校验的重要性（md5sum）

我们项目组曾经遇到过这样一个问题，发布包在我们这里验证是没有问题的，但是在客户那里就是有问题。花了很多时间查原因，最后终于发现了问题所在：客户拿到的发布包和我们提供的发布包并不完全一致，天知道传输的时候出了什么状况。但是这种情况是绝对不允许的，客户不会买账，肿么办？发布包一定要提供一个MD5码 ，客户收到发布包后可以通过MD5码校验来判断发布包的完整性。

2、文档的版本管理

相信每个项目组都知道对代码进行版本管理的重要性，但是不是每个项目组都重视文档的版本管理。有几个月，我不断的收到关于资料的问题单，根因是啥：就是文档没有上库，没有对文档进行版本管理。因为文档没上库，按问题单改了的文档存在本地，下次发版本时都找不着了或者根本就忘了有改过文档，结果有错的文档又再次被发布了出去。文档很重要，客户也许看不出你代码写的烂，但一定能看出你文档写的差。一个成熟的团队一定要对文档的版本管理进行规划。

3、wiki很重要，因为每个人都很懒

我们项目组之前是使用svn的，后来改用git了。git的使用比svn复杂很多，培训也不止一次了，但是大家真到要用的时候还是会不停的来问，几个人问还能忍受，当你面对几十人的团队时，各种轮番轰炸真是很烦人。ppt和doc文档其实都邮件发给大家了，但是大家都嫌麻烦不愿意去找，肿么办。把各种操作案例贴到团队wiki上，有问题的同学先看wiki，如果看完还解决不了，直接联系我或在wiki上反馈，我会不断的更新wiki。慢慢的求指导的人变少了。

4、发版本的时候不要太自信

我们PL有个坏毛病，发版本的时候总是太自信。情况是这样的，临近发布，遇到个问题，解决方案有2个：1，只解决当前问题，改动较小，风险可控，但修改不彻底，之后还需二次修改；2，彻底解决问题，改动较大，风险较大，可能涉及整体架构调整，长远来看对项目有利。当面临这种情况时，他往往选择2。。。我要说的是这样的选择非常二。让我来阐述一下原因，发布的时候绝对不适合对代码进行较大改动，非常非常容易引入其他不可预见的问题，而导致时间上的不可控。

5、技术和管理，两手抓，两手都要硬

从技术通道上升到管理岗位的同学，往往管理能力都令人堪忧，比如我们PL。我跟他聊过这个问题，他说他也很困惑。身为一个PL，手下10来个人，搞得东东各有不同，你都得了解，不然别人问你都不知道该说点啥。而人的精力毕竟有限，偏重技术了，管理就必然疏忽了。。。我想说的是，当你走上管理岗位之后就不是一个人在战斗了，兄弟们都等你发话捏，至少要把计划给理出来呀。