Tinyfool的开发日记(blog)

昨天和yayv聊起他的新工作的时候，他说，他在一个新项目里为了追求框架的和谐和更好的运用C++而产生了很多的困惑。这让我想起我刚刚做好的一个项目。

那个项目里面需要使用Ftp传输一些资料，而我发现微软的Wininet API虽然可以进行Ftp传输，但是缺少我非常需要的断点上传功能。于是我决定自己写一个Ftp传输组件。然而当项目时间过半的时候，我才发现我的Ftp传输组件编写的工作量已经开始超过整个项目的工作量，难度也已经超越了整个项目的本身，如果继续写下去，我肯定会让项目延期的。

我只好放弃这个Ftp传输组件的编写，开始研究怎么扩展Wininet，或者说尽量利用Wininet来实现断点上传功能。很快的我就实现了断点上传功能。然后，我开始为了项目的按时完成努力编写代码。最终项目略有延期，但总算还没有让客户完全失望，也达到了客户要求的功能。但是后面，赶进度造成了部分代码质量的下降，延期造成了客户的抱怨。

之后我反思这次项目经历，前期我对项目难度的估计和时间的测算基本上还是准确的。但是问题在于，当我发现Wininet API并不完美的时候，我错误的选择了自己实现一个Ftp传输组件的方案，后来的实践证明，Ftp传输组件的难度已经超越了项目的本身，而且势必造成项目的延期。从功能和性能上讲，采用微软的Wininet API足矣。我自己写一个Ftp传输组件使用起来可能会更加方便，更加灵活，但是付出代价远大于得到的收益。至少对客户来说是这样的，产品基于微软的Wininet API，还是基于我自主开发的Ftp传输组件功能上没有任何的区别。

在反观以前我没有完成的那些项目，或者说至今仍停留在图纸或者构想阶段的一些项目，他们之所以永远是构想，永远是半成品，往往因为我对他们的要求太理想主义，太过苛刻。我总是想一劳永逸地解决问题。然而我们生存的世界不是一成不变的，也不是完美无缺的，所以没有任何一个解决方案能在任何一个方面一劳永逸地解决问题。

另一个方面的问题在于，一个不好的成品也往往好于一个半成品。一个项目里，我们就算有天才的想法，有完美的实现，但是项目完成之前它是不会产生任何效益的。何况，设计环境只是真实环境的模拟，如果你不用成品在真实环境里面运行，有些细节信息你永远不会了解。

我将学会容忍这个世界的不完美，也将容忍自己的产品的不完美，但是这不代表我们放弃了对完美的追求。我们可以通过在运行中改善我们的产品，更好的达到追求品质的目的。