264    除了改进代码和数据结构，我的重写还有另一层目的，就是要把它演进成一个我完全理解的东西。

265    因为要是你不能对程序了如指掌，维护起来可就不好玩了。

266    在最初的一个月里，我只是遵循卡尔的设计理念。

267    我所作的第一个重要改变是加入了对IMAP的支持。

268    做法是：把原来的协议支持部分改写成一个通用驱动和三个可调用的方发表（分别针对POP2、POP3和IMAP）。

269    这些变动都阐明了一个程序员需要铭记在心的通用原则（特别是对于像C这样本身不支持动态类型的语言）：

270    9.精巧的数据结构即使搭配笨拙的程序代码，也比精巧代码加笨拙结构的组合要强得多。

271    布鲁克斯在《人月神话》的第九章中写道：“只给我看你的工作流程却隐藏表单，我将仍然一头雾水。

272    但是如果你给我展示表单，或许不需要流程图，就能柳暗花明了。”

273    哪怕历经三十年的文化和术语变迁，这个观点依旧正确。

274    这时（1996年9月初，开工后大约六周），我开始考虑要给软件换个名字了。

275    因为毕竟它已经不仅仅是个POP客户端了。

276    但是我在犹豫，因为设计上没有什么新突破，我的popclient需要独具一格。

277    当popclient学会如何将收取到的邮件再通过本机SMTP端转发的时候，这一切迅速改变了。

278    这个容后再表。