优雅的烂代码


/**
 * ┌───┐   ┌───┬───┬───┬───┐ ┌───┬───┬───┬───┐ ┌───┬───┬───┬───┐ ┌───┬───┬───┐
 * │Esc│   │ F1│ F2│ F3│ F4│ │ F5│ F6│ F7│ F8│ │ F9│F10│F11│F12│ │P/S│S L│P/B│  ┌┐    ┌┐    ┌┐
 * └───┘   └───┴───┴───┴───┘ └───┴───┴───┴───┘ └───┴───┴───┴───┘ └───┴───┴───┘  └┘    └┘    └┘
 * ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───────┐ ┌───┬───┬───┐ ┌───┬───┬───┬───┐
 * │~ `│! 1│@ 2│# 3│$ 4│% 5│^ 6│& 7│* 8│( 9│) 0│_ -│+ =│ BacSp │ │Ins│Hom│PUp│ │N L│ / │ * │ - │
 * ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─────┤ ├───┼───┼───┤ ├───┼───┼───┼───┤
 * │ Tab │ Q │ W │ E │ R │ T │ Y │ U │ I │ O │ P │{ [│} ]│ | \ │ │Del│End│PDn│ │ 7 │ 8 │ 9 │   │
 * ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴─────┤ └───┴───┴───┘ ├───┼───┼───┤ + │
 * │ Caps │ A │ S │ D │ F │ G │ H │ J │ K │ L │: ;│" '│ Enter  │               │ 4 │ 5 │ 6 │   │
 * ├──────┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴────────┤     ┌───┐     ├───┼───┼───┼───┤
 * │ Shift  │ Z │ X │ C │ V │ B │ N │ M │< ,│> .│? /│  Shift   │     │ ↑ │     │ 1 │ 2 │ 3 │   │
 * ├─────┬──┴─┬─┴──┬┴───┴───┴───┴───┴───┴──┬┴───┼───┴┬────┬────┤ ┌───┼───┼───┐ ├───┴───┼───┤ E││
 * │ Ctrl│    │Alt │         Space         │ Alt│    │    │Ctrl│ │ ← │ ↓ │ → │ │   0   │ . │←─┘│
 * └─────┴────┴────┴───────────────────────┴────┴────┴────┴────┘ └───┴───┴───┘ └───────┴───┴───┘
 */

敏捷开发是当下软件开发的主流模式之一,为了摒弃以往瀑布式开发带来的弊端,敏捷开发推崇在团队中以个人为单位进行简单的模块化开发,它更注重的是团队间的沟通和模块间的衔接。

为了使代码层面上的沟通更便捷,一套套的编码规范和设计模式应运而生,毫无疑问,使用这些规范模式会使得我们的代码看起来更优雅,经验也证明这更有利于团队沟通。

对于经验丰富的程序员而言,针对某种功能使用合理的设计模式编写出规范的代码、并提供满足功能调用的接口,可能是易如反掌的事。但每个团队中都不可避免的会存在生涩的程序员,例如我。对我而言这种方式就并不完全是这么回事了。

即使我作为一个项目经验如何不足的程序员,独立开发一个简单功能模块的能力还是具备的。经常在编写代码之前,我脑中已有完整的思路,我可以很清晰地向别人陈述我的编程思想,我也很有信心可以把这些思想变成代码。但事实上这可能比我想象的要难得多。很多时候我发现我花费了比预期更多的时间,却无法写出一段可执行的代码。因为我在编码的时候,想得更多的不是如何去实现这个功能,而是如何让别人更舒服地看懂我的代码。

虽然很多开发团队都强调代码的优雅性,但这是以“可运行性”为前提的。这种过分放大观赏性代码的地位,本就是本末倒置的行为。优雅只是交流的辅助手段,但不是唯一的手段。

事实上,如果仅是实现需求的功能,而不去考虑任何外因,我确信我可以很快地写出一段可运行的“烂代码”。烂代码与优雅代码相比,最表面的区别可能仅是可读性差而已。而且团队开发很多时候并不需要关心别人开发的功能是如何实现的,这些优雅性的问题自然也不会被马上指出来了。

当然,我并不是倡导每个人都去写烂代码。烂代码只是一个过度的产物,考虑到以后代码的维护性和可扩展性,必须在烂代码保证功能需求后,对其进行重构。而往往优雅地重构自己既成的代码,很可能要比优雅地写出构思中的代码要容易得多。

摒弃优雅性的约束,烂代码使得开发过程更轻松、耗用资源更少、编程的目的性更强。其实这与敏捷开发的部分理念恰好是一致的:有目的指向的简单构建、有辅助指向的重构勇气。这正是烂代码的优雅之道。

/**
 * 頂頂頂頂頂頂頂頂頂 頂頂頂頂頂頂頂頂頂
 * 頂頂頂頂頂頂頂     頂頂     
 *    頂頂   頂頂頂頂頂頂頂頂頂頂頂
 *    頂頂   頂頂頂頂頂頂頂頂頂頂頂
 *    頂頂   頂頂       頂頂
 *    頂頂   頂頂  頂頂頂  頂頂
 *    頂頂   頂頂  頂頂頂  頂頂
 *    頂頂   頂頂  頂頂頂  頂頂
 *    頂頂   頂頂  頂頂頂  頂頂
 *    頂頂       頂頂頂 
 *    頂頂      頂頂 頂頂 頂頂
 *  頂頂頂頂   頂頂頂頂頂 頂頂頂頂頂
 *  頂頂頂頂   頂頂頂頂   頂頂頂頂
 */

文章作者: EXP
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 EXP !
 上一篇
请发展你的惰性 请发展你的惰性
你工作的时候就只是工作吗? 我不一定。我有些时候不会把今天的所有时间都用在为了完成今天的工作任务中。而且我也相信,把全部时间都花费在工作并不代表就能很好地完成工作。 作为一个程序员,我上班时出现过的状态不外乎是三种,如果以键盘作为计量单位,
2013-08-04
下一篇 
程序员的"病态" 程序员的"病态"
每个程序员都是从菜鸟过来的,而菜鸟的成长之路总是崎岖的。不断地碰壁、不断地摸索、不断地成长,从中难免衍生出各种各样的“病态”,而这其实都是我们切实作为一个程序员的证明。 密集空间恐惧症这应是程序员的通病了。不知道是谁的谎言:“程序员每天的工
2013-07-16
  目录