不完美框架

今天看到一句话，深以为然：“In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.” 意为“如遇冲突，应首先考虑用户，其次是作者，再次是实现者，再再次是标准制定者，最后才是理论完满”。经搜索，发现原来来自《HTML Design Principles》（过去的确是小看了HTML5，以为它只是简单地增加了少量标签，现在看来确实还真该深入地仔细学习）。

与此相类似的，还有编码风格，还有工作目录结构，还有实现框架等等，都是容易遭受完美主义肆虐横行之地。记得很早的时候就听人说过，如果不能尽快形成某种稳定的编码风格，那么迟早会受到其严重的牵制。果不其然，在编码的路上走的时间越长，就会在代码洁癖的泥潭中越陷越深。这能带来好处，比如能够注意到细小的符号错误，但也会带来很大的心理负担。而只有把这些负担转换成为一种行为方式，并强化到成为某种习惯时，才能朝着正确的方向继续前行。

就我个人的经历而言，一个正面的例子是很早就开始学习并使用版本管理工具。最早使用的是subversion，并得益于TortoiseSVN，迅速抛弃了每天打一个zip或rar压缩包的笨办法，并养成了记录版本的习惯，至今甚至到了离开版本管理工具就不太敢动手修改代码的程度。

另一个反面的例子则是对科研分析流程的记录，这方面的理想目标是让别人根据记录能够完全重现过去的分析过程。由于没有可供借鉴的案例和框架，只好自己摸索不同的目录结构，并试图让各种操作（包括手动的操作）都通过脚本进行，并记录在案。这本身并没有问题，但问题在于到底需要多接近理想的目标，完美主义的代价是大量无穷的细节关注。时间一长，重复的操作越来越多，但其中又有很多是因为各种人为因素而不能很好地自动化的，于是就因此而变得疲惫不堪，反倒影响了分析工作本身的进展。这种情况下，才感到有些准备的不足，没有在适当的阶段抽出一些专门“磨刀”的时间，以至于影响到了“砍柴”。

总结起来，不要相信存在完美的框架，要接受不断演进的框架（可以由版本管理工具来记录历史）。避免因为完美主义而犯起拖延症。实时行动，并随时注意抽取重复的劳动，转化成零碎但可用的脚本，让它们成为工作习惯的一部分。