重构

Go语言在2016年当选tiobe index的年度编程语言。 转眼间6个月过去了，Go在tiobe index排行榜上继续强势攀升，在最新公布的TIBOE INDEX 7月份的排行榜上，Go挺进Top10： ...

一切没有目标的努力，都是瞎忙活儿。 - Tony Bai 刚实施回来，就又投入到新工作中，到今天才有那么一点点时间写写这件事儿。 * 缘起 我们的遗留系统性能一直不高，导致这一局面的因素有很多，比如最初设计和实现的“考虑不足”、后续维护人员的“随波逐流”甚至缺少勇气对影响性能的关 键代码进行重构等等。技术债务就这样一直积累着。直到两年前，我们终见其导致的巨大的影响了。 ...

新三年，旧三年，修修补补又三年。 — 中国俗语。 上面的这句俗语用来形容很多遗留软件系统(legacy software system)的现状是再合适不过了。 今天下午做了一下午的代码评审，对象是一个运行了7年的遗留系统。会上除了几处明显的代码逻辑错误我发言指了出来外，涉及业务流程以及代码设计的问题，我 大多保持沉默。因为我清楚，即便我明确指出问题，可能也得不到修正。也许参与评审代码的其他同事也都知晓这些问题，只是觉得现在还不能去改…。 ...

市面上关于优秀编程风格和习惯养成的书籍还真不少，其中“叫好又叫座”的书诸如《代码大全》、《编程精粹:编写高质量C语言代码》、《编程匠艺》、《重构》以及《Clean Code》等。不过前些天我在网上下载了一本名为《The Elements of Programming Style》的电子书，看过此书后，我才知道开创编写优秀风格代码之路的鼻祖是谁（不知道是否还有比这本书更加古老的且系统地讲述优良编程元素的书籍了？）。 ...

本文翻译自"Improve Code by Removing It"，来自于《程序员应该知道的97件事》一书中的某个章节。 少即是多。这是一句有些陈腐的短小格言，但有时它确实是正确的。 在过去的几周里我对代码库所作的改善工作之一就是删除了其中的几大块代码。 ...

本文翻译自"Put Everything Under Version Control"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。 把项目中的一切都纳入版本控制。你需要的资源包括：免费的工具，比如Subversion，Git，Mercurial和CVS；充足的磁盘空间；便宜且性能强大的服务器；无处不在的网络；甚至包括项目托管服务。安装好版本控制软件后，为了将你的工作成果放入版本库中，你所要做仅仅是在一个包含你的代码的干净目录中敲入适当的命令。你只需要学习两个新操作：将你修改的代码提交到版本库中以及将版本库中的代码更新到你本地的工作版本中。 ...

本文翻译自"Before You Refactor"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。 在某些时候，每个程序员都需要重构现有的代码。不过在你动手之前，请考虑一下下面的内容，因为这可以节省你和他人的大量时间（以及痛苦）。 · 重构开始的最好方式就是对现有代码库及其测试代码进行总结和评估。 ...

近一段时间重读了一些经典书籍，诸如《敏捷软件开发：原则、模式与实践》、 《程序员修炼之道》、《Unix编程艺术》等。这些书中关于如何衡量或评价一个类或函数设计好坏的几个原则(Principle)让人印象深刻。《敏捷软件开发》中谈到了SRP、OCP、DIP; 程序员修炼之道则以DRY、“正交性”为话题展开;《Unix编程艺术》围绕紧凑性、SPOT、分离等阐述作者立场。这么多经典原则，如何学习把握？我们不妨来挖掘一下这些新设计原则背后的本质。 追本溯源，从计算机编程语言的发展历史来看，成熟的结构化程序设计语言(如C语言、Pascal等)要先于成熟的OO设计语言(C++、Java等)出现，那么其成熟的设计理论显然也是要早于后者的。这里就不能不提到经典结构化设计的代表作：《Structured Design: Fundamentals of a Discipline of Computer Program and System Design》，这本书出于1975年(年份来自维基百科，Amazon上卖的是1979年版)。说实话我也没有看过此书原版，不过书中的内容和思想早已被其他后继书籍引用和借鉴，我们在市面上能看到的关于结构化设计方面的书籍，尤其是中文书籍，多照搬了此书内容和思想，所以也算是间接学习到了。 ...

近期在考虑对底层函数库进行一些重构，今天下午花了两个小时考量现有的函数库的接口设计，发现目前函数库的实现存在着一个普遍的问题：与特定的内存分配实现耦合的太紧。 我们的应用是多进程结构的，并使用了共享内存这种最快捷的IPC机制，鉴于此很多同事在实现一些数据结构或者算法时可能只考虑到了我们常见的应用场景-多进程共享，而对非共享内存分配的情况考虑不足。那如何将目前某些库函数实现与内存分配之间的强耦合解开呢？针对这道题我发起了一次mail讨论。 题目再重述一下：“目前底层库中的一些数据结构，比如xx_tree、xx_hash_table等，在它们的实现中都会有“分配内存空间”的需求，现有的实现多是直接调用已有的xx_shm_malloc和xx_shm_free在共享内存上动态申请和释放内存，但实际上有些场合我们并不需要在共享内存上分配内存，进程私有堆上的内存完全可以满足需求。如果让大家考虑修改目前xx_tree的实现或重新设计xx_tree的接口，以达到让xx_tree支持多种内存分配策略的目的，你是如额考虑的，请谈谈你的设计思路。" ...

早在几个月前就从网上下载到了"Working Effectively With Legacy Code"这本书的E版，之所以下这本书是因为看到了"Legacy Code"这两个单词了，说实话当时我并不知晓这本书的价值，只是想当然的认为：这本书可能会有助我改善我所从事的项目中的"Legacy Code"。早在上个月去逛书店时，就看到了书架上的这本"修改代码的艺术"，遗憾的是没有给予足够关注。在最近看到这本书译者刘未鹏的博客以及Dreamhead关于这本书的评价后，才又从电脑中找到这本书开始翻看。从与这本书几次"擦身而过"的经历来看，自己识书的能力实在是差劲。 ...