10步让你成为更优秀的程序员

shutup

! d. F# |! M/ z( ]$ ?作者: Paul Firth  来源: 外刊IT评论  
* l9 C2 I  R9 |/ W2 U
1 |: ^& w$ g$ ^3 a) Z1 W　　英文原文：10 steps to becoming a better programmer
　　这篇文章要介绍的，是我作为专业程序员这些年来学到的能真正提高我的代码质量和整体工作效率的 10 件事情。
　　1. 永远不要复制代码
6 y" q* X3 O( r3 o: E. p　　不惜任何代价避免重复的代码。如果一个常用的代码片段出现在了程序中的几个不同地方，重构它，把它放到一个自己的函数里。重复的代码会导致你的同事在读你的代码时产生困惑。而重复的代码如果在一个地方修改，在另外一个地方忘记修改，就会产生到处是 bug，它还会使你的代码体积变得臃肿。现代的编程语言提供了很好的方法来解决这些问题，例如，下面这个问题在以前很难解决，而如今使用 lambda 却很好实现：
3 W3 w0 F) H9 p( V' W) W. J/// <summary>
' r6 h$ |, M+ b6 J# M* P+ t/// 一些函数含有部分重复代码
/// </summary>
void OriginalA()
- W! O8 \& l" I% y  H. E{
    DoThingsA();
    // unique code
0 \5 Q7 N" ]& I/ ~2 B    DoThingsB();
9 c; _! W) |$ _5 _1 h}
# k6 ]5 b. z7 i* Y/// <summary>
( j. M7 p( l! F) N" v6 }/ }/// 另外一个含有部分重复代码的函数
$ x8 j% W, G' ~) \, n- {) A2 s/// </summary>
void OriginalB()
5 A; M! v2 g1 \7 ~{
    DoThingsA();
8 ~. S" c8 r! h7 J, a    // 没有重复的代码
% u& Q2 E- A7 Z$ a3 F( t" p    DoThingsB();
/ H( ~3 a- E$ C7 `2 a}
　　现在我们重构含有部分相同代码的函数，用 delegate 模式重写它们：
/// <summary>
/// Encapsulate shared functionality
4 N! ?8 N; ~' T3 h( ?$ [/// </summary>
/// <param name="action">User defined action</param>
+ q& Q) [- V0 Z! l" t! l" ]void UniqueWrapper(Action action)
- R4 i9 U+ P4 ^3 A{
    DoThingsA();
    action();
8 I. d1 d: V+ C; P. ]8 J    DoThingsB();
5 I3 U3 V; M: i  b8 U4 e$ q: o& m}
! J& J* ]7 e* v. [4 r/// <summary>
1 P' q5 ~; U; p) `+ v0 X/// New implmentation of A
' E! \% Y" E3 U, h5 w% t/// </summary>
void NewA()
; p  N0 E7 n, }{
& _( ~' c( m. l    UniqueWrapper(() =>
    {
        // unique code
    });
7 Q9 W  V0 h* y. J- N) J/ ]}
" l7 J) l  v* o' j3 q/// <summary>
/// New implementation of B
/// </summary>
void NewB()
4 \2 f& b4 b# z* E5 N3 f3 }4 H{
    UniqueWrapper(() =>
- ]. i- h+ f* U/ m" S    {
( V8 D- w7 \, Q        // unique code
. N/ W: m, C. a% R+ m    });
}
* Y6 w% x- N. E# `* D　　2. 留意你开始分心的时候
% J) c& c# K5 C: D4 ~　　当你发现自己在浏览 facebook 或微博，而不是在解决问题，这通常是一种你需要短暂休息的信号。离开办公桌，去喝一杯咖啡，或去跟同事聊 5 分钟。尽管这样做看起来有点反直觉，但长久去看，它会提高你的工作效率。
　　3. 不要匆忙赶任务而放弃原则
　　当带着压力去解决一个问题或修改一个 bug，你很容易失去自制，发现自己匆匆忙忙，甚至完全忘了一直坚持的重要的测试过程。这通常会导致更多的问题，会让你在老板或同事眼里显得很不专业。
* C9 S# A* n+ Z/ q$ R　　4. 测试你完成的代码
　　你知道你的代码能做什么，而且试了一下，它确实好用，但你实际上需要充分的验证它。分析所有可能的边界情况，测试在所有可能的条件下它都能如期的工作。如果有参数，传递一些预期范围外的值。传递一个 null 值。如果可能，让同事看看你的代码，问他们能否弄坏它。单元测试是到达这种目的的常规方法。
　　5. 代码审查
　　提交你的代码之前，找个同事一起坐下来，向他解释你做了哪些修改。通常，这样做的过程中你就能发现代码中的错误，而不需要同事说一句话。这比自己审查自己的代码要有效的多得多。
　　6. 让代码更少
/ x3 Z& d; |  J3 z　　如果你发现写了大量的代码来解决一个简单的问题，你很可能做错了。下面的 boolean 用法是一个很好的例子：
! \) R5 U, E1 tif (numMines > 0)
{
* W0 M( Q0 W5 Z3 G* w' A* u   enabled=true;
5 k/ l% W8 ~2 ~}
else
{
   enabled=false;
}
0 _8 J9 e% ?+ S6 v4 Q5 }1 ?$ }9 V　　这时你应该写成这样：
5 v3 ]% p% L  L$ {( `; Kenabled = numMines > 0;
　　代码越少越好。这会使 bug 更少，重构可能性更小，出错的几率更小。要适度。可读性同等重要，你可不能这样做而使代码丧失可读性。
　　7. 为优雅的代码而努力
　　优雅的代码非常的易读，只用手边很少的代码、让机器做很少的运算就能解决问题。在各种环境中都做到代码优雅是很难的，但经过一段时间的编程，你会对优雅的代码是个什么样子有个初步的感觉。优雅的代码不会通过重构来获得。当你看到优雅的代码是会很高兴。你会为它自豪。例如，下面就是一个我认为是优雅的方式来计算多边形面积的方法：
static public double GetConvexPolygonArea (Vector2[] vertices)
{
: F* u* y+ g1 x# R! v    double area = 0;
    for (int i = 0; i < vertices.Length; i++)
' X9 J) T" X  }2 `" Q    {
8 `* Q- i" s6 M: c% I& O        Vector2 P0 = vertices[i];
6 d1 ^: j7 U; ]" h' f/ ^# Y$ S        Vector2 P1 = vertices[(i + 1) % vertices.Length];
        area += P0.Wedge (P1);
    }
    return area / 2;
}
　　8. 编写不言自明的代码
　　勿庸置疑，注释是编程中很重要的一部分，但能够不言自明的代码更胜一筹，因为它能让你在看代码时就能理解它。函数名变量名要慎重选择，好的变量/方法名字放到语言语义环境中时，不懂编程的人都能看懂。例如：
2 G% R$ ^4 D# _" }, w9 R: p+ [4 J/ nvoid DamagePlayer (Player player, int damageAmount)
{
    if (!player.m_IsInvincible && !player.m_IsDead)
# g! C: t, T. o0 x    {
- P0 B! E/ |9 ?! }# S        player.InflictDamage ( damageAmount );
9 L+ F- w# h0 z/ y/ c    }
5 R  O( ^7 L# \4 m% P- c}
　　能自我说明的代码不能代替注释。注释是用来解释“为什么”的，而自我说明的代码是来描述“是什么”的。
　　9. 不要使用纯数字
# h; s* g1 T9 y. J　　直接把数字嵌入代码中是一种恶习，因为无法说明它们是代表什么的。当有重复时更糟糕——相同的数字在代码的多个地方出现。如果只修改了一个，而忘记了其它的。这就导致 bug。一定要用一个命名常量来代表你要表达的数字，即使它在代码里只出现一次。
　　10. 不要做手工劳动
" m- L: o4 L. `　　当做一系列动作时，人类总是喜欢犯错误。如果你在做部署工作，并且不是一步能完成的，那你就是在做错事。尽量的让工作能自动化的完成，减少人为错误。当做工作量很大的任务时，这尤其重要。
% T9 W8 |$ {, A　　11. 避免过早优化
( r' v6 y3 M2 {. G  ]4 r　　当你要去优化一个已经好用的功能代码时，你很有可能会改坏它。优化只能发生在有性能分析报告指示需要优化的时候，通常是在一个项目开发的最后阶段。性能分析之前的优化活动纯属浪费时间，并且会导致 bug 出现。
　　好吧，我说是 10 个，但你却得到了额外赠送的一个！
- y4 g, {/ I$ b. B  g9 X　　这些就是我要说的，我希望它们能帮助你改进编程开发过程。
　　下次再见！祝快乐！
1 D2 @  b0 ^( D( x( Y2 U　　Cheers, Paul.

shutup

来顶个贴。。。