项目组中的夹气小媳妇

          前两天一直再看《大明王朝1566》，中间那个的徐阁老说得话在这些天有所感受，就是上面是皇上，下面是子民，中间就是这个大臣成了受气的小媳妇了。

           最近一直在管理着一个系统的后续开发工作，前期一直到参与其中，从需求到初步验收。现在客户的需求总是不停的发生变化，而且开始说不用管的需求，现在也提上了日程了，比如多语言，比如Mobile。自己也基本上开始从一个纵切面（功能节点）开发，开始向一个横切面开发了，维护所有人的代码。其间很多开始之初预料到的问题，开始逐渐暴露出来。编码不规范，CVX（ctrl＋C，V，X）代码比较多，结构不统一等等，维护起来异常痛苦。虽然开始的时候也要求大家遵守一些规范，也准备对后面的一些需求进行支持，可是种种原因全都是后来不了了之，除了自己强硬要求的以外。（发现即使强硬要求的，很多也都没有遵守）

           自我总结一下，规范推行的阻力之所在：

           1）不在其职，不谋其政

              自己并不是项目管理人员，只是开发中的一员，没有行政手段。也不能对大家如何，只能推广技术，推广编码规范。但是不能强硬，自己要做的很多只能是管好自己的代码。

           2）时间压力

           有时候我觉得这个就是一个借口，一个比较大的借口，也是堂而皇之的谎言，就像CVX确实很快，可是稍微有些修改的时候，痛苦不言而喻。而且CVX这个也是一个习惯的问题，如果从开始就养成一个习惯的话，遇到有些重复的时候，自己就会思考需不需要重构，代码简洁是简短维护成本的最行之有效的，而且也是成本最低的一个。个人一直都认为什么都是一个平衡的，前面失去的，后面会加倍还给你的。前面时间少了，后面肯定会多，而且成倍增长，前面多的，后面会减少很多。可惜这个道理谁都明白，却谁都不愿意执行罢了。

          3）新人较多

           新人在项目中比例有些大，不知道规范的重要性，说了一遍又一遍的，总是不起作用，写的代码天马横空，怎么方便怎么写，有共同方法也不使用，总是需要去检查才更改，有时候苦口婆心说了，也是收效甚微。

          4）没有执行工具，或者说没有使用更好的工具

            从最开始之初就没有把一切贯穿到工具中，我想这个是最大的败笔了。规范有，不能仅仅靠口头传递，靠人为约束，关键还是需要一个工具来操作，工具用来贯穿的话，不会有遗漏，不会忘记执行，工具就是一个保障。

          5）个人能力有限

            自己的工作也是比较繁重，没有更多的精力顾忌很多方面，不可能很多地方面面俱到。

           6）侥幸心里

            后来麻木了，就像这个最后不定是自己维护，或者那个节点不会是我维护等等。结果。。。。

         总觉得这个时候说这些都有些事后诸葛亮的嫌疑，但是又能如何呢，总结一下，避免下次再范吧。

评论

6 楼 dengyin2000 2007-02-03  

使用checkstyle或者pmd之类的代码检查工具。 测试下那些重复代码

5 楼 hgq0011 2007-02-03  

有时候真的很难，比如我的经理把系统分析出来，由于他要到处跑，没有时间来监督。那么个地方就会有一个主管帮他打理，可他又不会写JAVA方面的技术。问题来了，那么他的要求就很底，只要大家把系统给弄出来了，那就行了。所以大家就可以即兴发挥了，随便来了，很多时候，各方面的因素都没有考虑，系统就经常出问题了。我只能是把自己的代码写好，有时间能够提示一下，我不能越级的。郁闷。

4 楼 foxty 2007-02-03  

sinokaka 写道

推广规范更需要的是监督机制和带头作用。

我同意你说的，可是很多东西还是需要政治因素管理，如果你不是项目经理，你说话有人听吗，说多了，有人会说你狗拿耗子，可是自己又不甘心项目逐渐走向混乱。
还有就是代码审查，开始的时候做，后面不一定总是能执行下来，最好还是通过CheckStyle等工具进行操作

不能执行那是因为监督的力度不够。完全凭大家自觉，小范围几个人是可以，人多了就不行。

这些事情在项目开始就应该确定下来，而且需要得到上面的认可和支持才能做，如果没有办法影响大环境，还是先从自己做起好了。毕竟不在其位，不谋其职。

3 楼 有思想的芦苇 2007-02-03  

世上最难做莫过一仆二主,如果政出多头底下人很难干活的,俺在原单位就有这样感觉的.

2 楼 sinokaka 2007-02-03  

推广规范更需要的是监督机制和带头作用。

我同意你说的，可是很多东西还是需要政治因素管理，如果你不是项目经理，你说话有人听吗，说多了，有人会说你狗拿耗子，可是自己又不甘心项目逐渐走向混乱。
还有就是代码审查，开始的时候做，后面不一定总是能执行下来，最好还是通过CheckStyle等工具进行操作

1 楼 foxty 2007-02-03  

sinokaka 写道

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 前两天一直再看《大明王朝1566》，中间那个的徐阁老说得话在这些天有所感受，就是上面是皇上，下面是子民，中间就是这个大臣成了受气的小媳妇了。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最近一直在管理着一个系统的后续开发工作，前期一直到参与其中，从需求到初步验收。现在客户的需求总是不停的发生变化，而且开始说不用管的需求，现在也提上了日程了，比如多语言，比如Mobile。自己也基本上开始从一个纵切面（功能节点）开发，开始向一个横切面开发了，维护所有人的代码。其间很多开始之初预料到的问题，开始逐渐暴露出来。编码不规范，CVX（ctrl＋C，V，X）代码比较多，结构不统一等等，维护起来异常痛苦。虽然开始的时候也要求大家遵守一些规范，也准备对后面的一些需求进行支持，可是种种原因全都是后来不了了之，除了自己强硬要求的以外。（发现即使强硬要求的，很多也都没有遵守）</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 自我总结一下，规范推行的阻力之所在：</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1）不在其职，不谋其政</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 自己并不是项目管理人员，只是开发中的一员，没有行政手段。也不能对大家如何，只能推广技术，推广编码规范。但是不能强硬，自己要做的很多只能是管好自己的代码。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2）时间压力</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 有时候我觉得这个就是一个借口，一个比较大的借口，也是堂而皇之的谎言，就像CVX确实很快，可是稍微有些修改的时候，痛苦不言而喻。而且CVX这个也是一个习惯的问题，如果从开始就养成一个习惯的话，遇到有些重复的时候，自己就会思考需不需要重构，代码简洁是简短维护成本的最行之有效的，而且也是成本最低的一个。个人一直都认为什么都是一个平衡的，前面失去的，后面会加倍还给你的。前面时间少了，后面肯定会多，而且成倍增长，前面多的，后面会减少很多。可惜这个道理谁都明白，却谁都不愿意执行罢了。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3）新人较多</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 新人在项目中比例有些大，不知道规范的重要性，说了一遍又一遍的，总是不起作用，写的代码天马横空，怎么方便怎么写，有共同方法也不使用，总是需要去检查才更改，有时候苦口婆心说了，也是收效甚微。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4）没有执行工具，或者说没有使用更好的工具</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 从最开始之初就没有把一切贯穿到工具中，我想这个是最大的败笔了。规范有，不能仅仅靠口头传递，靠人为约束，关键还是需要一个工具来操作，工具用来贯穿的话，不会有遗漏，不会忘记执行，工具就是一个保障。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5）个人能力有限</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 自己的工作也是比较繁重，没有更多的精力顾忌很多方面，不可能很多地方面面俱到。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6）侥幸心里</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 后来麻木了，就像这个最后不定是自己维护，或者那个节点不会是我维护等等。结果。。。。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 总觉得这个时候说这些都有些事后诸葛亮的嫌疑，但是又能如何呢，总结一下，避免下次再范吧。</p>

推广规范更需要的是监督机制和带头作用。

以前在公司制定规范和制度的时候，首先是两个开发员每天做完之后互相监督进行代码审查，主要就是查看编码规范之类的是否符合规范。另外我就随时抽查cvs上的源代码，发现问题直接找负责监督你的同事。不知道大家是否还有更好的办法？

另外还选出几个能力强点的首先带头开始做，重要的是自己更需要带头，要以身作则。