年终总结上的经验体会（脱水版）

说明，原文是内部述职会演讲PPT，为了避免涉及公司产品，【】括号的内容可以一眼飘过，脱水之后的内容应该和纯Java技术挂钩，欢迎褒贬不一的评论。 

 

1.重构，伴随着整个软件开发过程，大到软件需求评审会上的需求变更，小到一时灵感对变量的命名，重构不挑食，重构无处不在。
【举了两个工作中实际遇到的例子来说明】
如果发现想要使用某个方法，但它位于其它类中，就可以想是否可以提取父类或者接口，然后把通用的方法提取到其中，再对其进行继承或者实现，那样就可以方便地调用方法了
……
甚至，发现某个变量、方法和类的名字不合理，为了取一个更好的名字，冥思苦想，最后连自己都被纠结了进去，这个过程也算重构。

2.从现在起，开始考虑代码质量。
代码质量提高的目标：优雅、清晰、维护性强、没有坏的味道，如果让人第一眼看到就有种拍案叫绝的冲动，那么就再好不过了。

提高代码质量的方式有很多种，利用工具、经常看一些大师级的代码、团队codereview、重构、深入OO思想以及掌握常用的设计模式等等，都是很不错的方法。

【举了一个工作中实际遇到的例子来说明】

 

3.时时刻刻考虑程序的健壮性和异常，即使过单行道的时候都会向道路两边看看再过去。

在此，我们不争论java中的checked异常是否真的有必要，不争论“用户名不存在”这一事件是异常还是正常的use case，也不争论发生了checked异常是业务逻辑的责任还是发生了unchecked异常是程序员的责任，我们讨论通过异常来提高程序的健壮性。

【举了一个工作中实际遇到的例子来说明】 

 

4.代码就像你的左脚，测试就像你的右脚。

你可以先迈左脚，再迈右脚。然后一直走下去。
也可以先迈右脚，再迈左脚。然后一直走下去。
只要你不是一直单脚跳着前进，你都会走得很稳，而且没有人看得出区别来。

上面这句经典的话当然不是我的原创，但是我知道，测试很重要，非常的重要！

【举了一个工作中实际遇到的例子来说明】 

 

5.虽然软件开发是一个团队活，但是独立开发一些比较有价值的小工具，感觉也不错。

【利用我工作中开发的一款小工具来说明】

 

6.学习需要坚持，特别是看别人的代码。

当你拿到一个10万行的源代码时，前10天肯定很痛苦的，要是你能找到切入点一步步跟着源代码的运行流程看下来熬过前10天基本上就能豁然开朗了。

评论

43 楼 cantellow 2011-02-16  

对于你的领导，那肯定不是程序员出身的，站在用户角度思考问题固然重要，但是软件开发是一个长期维护的过程，如果你的项目是一旦形成交给用户再也不管的话，那么我无话可说。
只要你还在为你的用户服务，那么它的需求是不断变化的，当你修复缺陷、添加新功能时，代码质量就体现出来了，如果你不及时重构，你的代码会越来越沉沦，等到有一天你的领导也读不懂的时候，我想他才开始会意识到重构和代码质量的重要性。

42 楼 wxno1 2011-02-16  

<div class="quote_title">cantellow 写道</div>
<div class="quote_div">
<p><span style="color: #ff0000;">说明，原文是内部述职会演讲PPT，为了避免涉及公司产品，【】括号的内容可以一眼飘过，脱水之后的内容应该和纯Java技术挂钩，欢迎褒贬不一的评论。</span> </p>
<p> </p>
<p><strong>1.重构，伴随着整个软件开发过程，大到软件需求评审会上的需求变更，小到一时灵感对变量的命名，重构不挑食，重构无处不在。 <br></strong>【举了两个工作中实际遇到的例子来说明】<br>如果发现想要使用某个方法，但它位于其它类中，就可以想是否可以提取父类或者接口，然后把通用的方法提取到其中，再对其进行继承或者实现，那样就可以方便地调用方法了<br>……<br>甚至，发现某个变量、方法和类的名字不合理，为了取一个更好的名字，冥思苦想，最后连自己都被纠结了进去，这个过程也算重构。 </p>
<p><br><strong>2.从现在起，开始考虑代码质量。</strong> <br>代码质量提高的目标：优雅、清晰、维护性强、没有坏的味道，如果让人第一眼看到就有种拍案叫绝的冲动，那么就再好不过了。 </p>
<p>提高代码质量的方式有很多种，利用工具、经常看一些大师级的代码、团队codereview、重构、深入OO思想以及掌握常用的设计模式等等，都是很不错的方法。 </p>
<p>【举了一个工作中实际遇到的例子来说明】</p>
<p> </p>
<p><strong>3.时时刻刻考虑程序的健壮性和异常，即使过单行道的时候都会向道路两边看看再过去。</strong> </p>
<p>在此，我们不争论java中的checked异常是否真的有必要，不争论“用户名不存在”这一事件是异常还是正常的use case，也不争论发生了checked异常是业务逻辑的责任还是发生了unchecked异常是程序员的责任，我们讨论通过异常来提高程序的健壮性。</p>
<p>【举了一个工作中实际遇到的例子来说明】 </p>
<p> </p>
<p><strong>4.代码就像你的左脚，测试就像你的右脚。</strong> </p>
<p>你可以先迈左脚，再迈右脚。然后一直走下去。 <br>也可以先迈右脚，再迈左脚。然后一直走下去。 <br>只要你不是一直单脚跳着前进，你都会走得很稳，而且没有人看得出区别来。 </p>
<p>上面这句经典的话当然不是我的原创，但是我知道，测试很重要，非常的重要！ </p>
<p>【举了一个工作中实际遇到的例子来说明】 </p>
<p> </p>
<p><strong>5.虽然软件开发是一个团队活，但是独立开发一些比较有价值的小工具，感觉也不错。</strong> </p>
<p>【利用我工作中开发的一款小工具来说明】</p>
<p> </p>
<p><strong>6.学习需要坚持，特别是看别人的代码。</strong> </p>
<p>当你拿到一个10万行的源代码时，前10天肯定很痛苦的，要是你能找到切入点一步步跟着源代码的运行流程看下来熬过前10天基本上就能豁然开朗了。</p>
</div>
<p> </p>
<p>乌托邦似的想法，如果是项目驱动，要照顾水平参次不齐的团队，有些都很难做到，用我们领导的话说:<span style="color: #ff0000;">不在意你代码写的最终有多烂，而是运行时能有好的表现，要有用户体验</span>，用户不会理解你实现一个功能有多优雅，而是这功能好不好用，这就是程序员和用户的思区别。</p>
<p> </p>
<p>老实说我承认有时程序员的思想都出发自代码角度，但是我总觉得<span style="color: #ff0000;">所谓的用户体验的概念被扭曲了</span>......</p>

41 楼 wuxing429 2011-01-28  

加油，  我也不喜欢写单元测试代码！

40 楼 cantellow 2011-01-28  

huangheyuan1229 写道

楼主在公司还混得不错吧

2010.6月份刚转正的新员工，年假都没有，你说呢

39 楼 daquan198163 2011-01-28  

pch272215690 写道

EldonReturn 写道

其实这些都有个前提：时间充足，项目不紧。
要不然都不可能

完全同意，我已经堆代码半年了。玩的就是复制黏贴。

你们的意思是说，如果时间不足，项目紧，那么就不可能采用更好的方法来开发软件？
提高质量就会牺牲进度？ 这大概是软件行业最大的谬论之一！

38 楼 NanguoCoffee 2011-01-28  

EldonReturn 写道

其实这些都有个前提：时间充足，项目不紧。
要不然都不可能

其实对项目的整个周期 以及 后期的维护来说。

编写单元测试 比 不写单元测试  省下来的时间不是一点半点，代码质量也有保证。
靠测试测很多东西是测不出来。

37 楼 huangheyuan1229 2011-01-28  

楼主在公司还混得不错吧

36 楼 cantellow 2010-12-24  

harry_2013 写道

希望能看到被缩掉的那一部分。

缩掉的那部分是关于公司业务产品的，不能透露，也没什么含金量，就是举了几个例子而已。

35 楼 harry_2013 2010-12-24  

希望能看到被缩掉的那一部分。

34 楼 harry_2013 2010-12-24  

楼主的语句看着很顺畅。mb中

33 楼 cantellow 2010-12-24  

flysnowxf 写道

几个纠结的问题：
1.一些同事不太关心自己的代码，随便写写，以任务完工为目标。弄地我老想改他们的代码，因为看起来太丑陋了，内心很冲动。
2.代码风格是几年工作习惯形成的，魔法字符串、复制粘贴一大堆，说过几次也无济于事，习惯很难改变。
3.公司没测试，只能自己测，同事交叉测，结果代码质量可想而知。自己熟悉的东西很难测出问题来。

1.严格执行codereview，codereview不通过，不让提测或者上线发布，严格执行，习惯是可以改变的（21天）。
2.同上。
3.我不建议同事交叉测试（万一有什么过节什么的，测试就成为了互相攻击的武器），我还是比较喜欢单元测试+debug模式把代码完整走一遍。

32 楼 flysnowxf 2010-12-24  

几个纠结的问题：
1.一些同事不太关心自己的代码，随便写写，以任务完工为目标。弄地我老想改他们的代码，因为看起来太丑陋了，内心很冲动。
2.代码风格是几年工作习惯形成的，魔法字符串、复制粘贴一大堆，说过几次也无济于事，习惯很难改变。
3.公司没测试，只能自己测，同事交叉测，结果代码质量可想而知。自己熟悉的东西很难测出问题来。

31 楼 aws 2010-12-24  

EldonReturn 写道

其实这些都有个前提：时间充足，项目不紧。
要不然都不可能

这个基本是天方夜谭

30 楼 cantellow 2010-12-24  

tian-84 写道

重构，测试驱动开发什么的都是浮云，程序员都是懒的，有那时间，整点别的呢

没听过程序员的几大优良品质么？
其中有一个就是懒。
因为懒我们才会自动化，才会提高效率。

29 楼 ganjp 2010-12-24  

我觉得刚开始就重要，我刚参加工作不久，每天害怕自己的代码出问题，晚上都睡不着觉，，，，，

28 楼 zjhlht 2010-12-24  

不错啊~~~还有年终总结大会！！！

每一年都可以让自己提升很多！！！哎~~嫉妒啊！

27 楼 tian-84 2010-12-24  

重构，测试驱动开发什么的都是浮云，程序员都是懒的，有那时间，整点别的呢

26 楼 matt.u 2010-12-24  

写得不错，不过要做起来还真不容易。

25 楼 love_ai87 2010-12-24  

我最近一直在坚持比较细致点的自测，我觉得还是很有用处的，上一个项目因为时间紧，没有测试，最后出了两个严重bug，但是这一次，我基本上抽了一天时间来自测，没有说明大的bug，出了有一个地方需求理解错了，把数据取错了，字段改下就ok了

~~~~~~~~~~~~~~~~~

24 楼 cantellow 2010-12-24  

第一次听说开发依赖测试。
我从来没有认为开发和测试是分开的。