不完美框架

发布于:2015年1月20日 14时45分

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

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

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

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

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

相关文章: