Monthly Archives: August 2011

51CTO六周年贺礼:译文一篇

一霎眼,51CTO六周年了。我去年为51CTO家园写的那篇“赞歌”还历历在目,而现在家园的园长一休已经成为已婚人士,不免让人再次感慨时光的流逝……(呃,一休的已婚跟今天的感慨无关) 嗯,咳咳。总结过去这一年,更新的博客少了,感到惭愧。无论是抱怨51CTO博客无法在ScribeFire上导入也罢,还是因为自己进入了一个沉淀期也罢,但说来说去,终归是人懒。 (不过话说回来,看到一休的博客还停留在去年7月,我又沾沾自喜了起来) 好吧,其实今天六周年,我没啥好写的。 不过今天看到一篇文章不错,英文的,就顺手翻译过来,当作给51CTO的生日礼物吧~ 这篇文章跟技术负债有关。 其实对于技术负债,我也没有系统的研究过;但是无论对于技术团队,编辑团队,或者个人来说,这种“负债”的概念,一定要清楚的认识到。自己应该到什么水平,自己实际上实现了什么水平,没有这种认识,自己过得固然糊里糊涂,又要如何对他人所交托的任务负责呢? 以下就是: DevOps and Technical Debt: A Debt Crisis in Your Workplace? 开发运维与技术负债:你工作的地方遭遇到负债危机了吗? (译注:DevOps,开发运维,是这两年在运维领域的一个新生概念,基本理念类似开发领域的敏捷开发。大意就是,运维和开发关注的领域都要有一定的覆盖,才能够互相理解,避免扯皮,提高效率。嗯,跟老杨上周在培训上讲的“双方各跨一步就越界”的概念是一样的) 现在满世界的金融新闻都在讨论负债危机的事情,那么对于IT部门中另一种负债的讨论,倒也是一个很好的时机。 这种负债往往发生在不经意间,而它同样也会带来悲催的结局。这就是我今天要说的:技术负债。 技术负债常在敏捷开发的周期中被提及,这是对于代码质量和完整性缺失程度的一种量化方式,从而加速商业特性的开发流程。所谓“技术负债”的意思,就是用“正确的做法”减去“得过且过的做法”得出的结果。 之所以用到“负债”一词,是因为这个现象所造成的结果,是企业或组织在未来的某个时间段必然要进行一种“偿还”(就是修正的过程)。在开发的过程中,你越是不去理睬这些负债,那么负债则会滚雪球一样增加。正如同金钱上的负债一样,技术负债也会产生相当复杂的化学反应。 下面是我最喜欢的几个比喻: 没完善设计就写代码相当于借钱。 重构相当于还债。 由此造成的开发进度缓慢相当于付利息。 对于技术债务的说明,Ward Cunningham,Martin Fowler和Israel Gat这些大牛们说的相当好了,建议想要了解技术债务的朋友们直接去读他们的东西就行。 那么,这个与DevOps有什么关系?我认为,DevOps要解决的问题,最适合用技术债务的概念去解决并量化。我经常听到团队的人说,“先不要管那么多啦,先把东西弄上线了再来完善我们的流程和自动化设计”。这可是相当于巨额的技术负债,而他们往往缺乏对其进行量化的方法。 那么借用如上的比喻方式,DevOps遇到的问题主要跟自动化实现的粗糙质量息息相关: 没有采用自动化,或者设计糟糕的自动化相当于借钱。 对自动化脚本进行实施和改良的过程相当于还债。 缺失或糟糕的自动化导致的糟糕执行效果相当于还利息。 所以,无论对于开发还是对于运维团队来说,技术负债已经是执行层面一个非常具备说服力的比喻。 ————————————————我是正文结束的分割线—————————————— 其实我想说,这个“负债”的概念,用到任何场景都是可以的。虽然说,这样一个比喻默认有一些事情你是“应该”去做的:比如开发必须要先设计好整个的功能体系和架构,部署系统要先做好自动化机制,等等;但实际上,对于我们面对的很多事情,实际上我们很难知道哪一条路才是正确的,这些“概念”大多是前人多年经验积累总结出来的。而这些经验,有些是普适性的,有些则只针对特定的场景。 … Continue reading

Posted in ops | Tagged | Leave a comment