标签：文件 问题 sp 代码 工作 时间 设计 bs 不同的
出来工作已经半年了，经历过很多事情，像是部门的合并和拆分，每次动荡，都让我受益匪浅，无论好坏。
刚来部门的时候，部门还是处在稳步上升的阶段，这阶段是一个甜蜜期，对于新人的培养也是很充分的，会给予一些新的模块或者功能点去做，并且开发任务并不是很赶，需求很明确，部门基本上都不加班。那时的我还没毕业，只是进来实习，都是在看源码，做功能预览，还是学到很多东西。
好景不长，半个月后，部门就被其他部门合并了，硬生生的要求在一个月内整出个东西出来，结果导致项目的进度非常赶，每天一个版本的速度在发，而且当初为了追求速度，合并的时候也是硬生生的将两个不同的项目合在一块，然后在上面不断添加修改。这样的结果自然导致bug不断发生，不断修正bug的同时新功能又不断派下来。。。
四个月后，部门又被拆分了，因为合并后的效果太差了。。。
拆分后，我就去另一个部门，换了一个组长。这两个组长的做事风格完全不同，给我留下深刻的印象。
第一个组长属于那种只要求把事情快速交差的类型。他会要求我们只要能跑起来就行，至于优化什么的放到后面考虑，结果什么优化都没干，因为后面根本没有时间。。。他会交给人一个任务，然后也不定一个最后期限，等到某天需要的时候就过来问人要，也不管做得怎样，就集合进去，测都没测就集合了。。。平时任务不赶的时候，准时走人，一到发版的时候，又紧张起来，因为这时一大堆问题，产品经理又会在发版的时候突然就跑过来改需求，所以造成一边改bug一边做新需求的局面。。。我印象深刻的是，每到发版的时候，总会听到这样的话：怎么会有这么多的bug。。。那时候的我感觉真的是很累，因为项目进度紧张，他也不会把太重要的东西交给新人，干的东西都是修修补补，然后那堆代码基本上都没有写注释，好多硬编码的东西，又不注重变量和方法的命名，可读性很差，原本的设计是不错的，但经过好多人的封装，变成一堆难以理解的东西。。。面对这样的情况，我有跟组长说过，但组长的意见就是：能不动的东西就别动，让它留在那里，哪怕它真的不好，但它现在能运行，而且每次问他一些问题的时候，他都会马上抛出一个解决方案来，让人照着办，实际上，我只是想要知道那个功能的类文件在哪里，具体的代码还没看，就要听他讲一大堆东西，还懵懵懂懂的拿着一个他给的解决方案去做。。。
实际的效果就是：平时大家没啥事干，一到发版的时候就拼命加班加点，最后还是无可奈何的发版了，发完版，第二天又是继续改bug，因为发出的版本bug太多了。。。
第二个组长属于那种把控比较严格的，但又允许手下有一定程度的发挥。他会把新任务和新需求交给新人，然后组织有经验的人进行重构，开了两个分支出来。而且要求平时周二周四加班，干完手头上的活就可以走人。他的说法就是：平时稍微加点班，把事情干好点，后面就不用那么赶了。结果发版的时候，他基本上都不加班。平时都会加点班，但又不是很晚，稍微比正常下班待多一个小时左右的时间，整理一下进度和工作。他对别人的工作不怎么指手画脚，但会限定一个日期，然后具体怎么做就交给拿任务的人，无论是新手还是老鸟，但每次都会说明最后他要达到的要求。他经常说的话就是：我只给你任务，怎么做，就由你决定，但一定要保证在规定日期内达到我要的效果，就算你加班加点也要完成。他还要求每次写新的模块时，一定要确保它是独立的，可抽离的，并且文档先行，文档一定要写好，对注释也是有要求的，谁写了什么，改了什么，都要注明。
实际的效果就是：平时大家都有事情干，并且还能在做新需求的同时还能确保性能，每次发版都是没问题的，并且进度明显快于我之前的组长。
这就是，不同的态度，导致项目的不同面貌。
标签：文件 问题 sp 代码 工作 时间 设计 bs 不同的
原文地址：http://www.cnblogs.com/wenjiang/p/3961418.html
