漫谈软件开发

漫谈软件开发

这个title挺大，不过好在只是发在自己博客上，说说也无妨。是我最近使用python开发的一些心得。

从最早接触boo——一种类python语法的类python动态脚本，依附.net平台，更直白点类似IronPython,大家主要用它来做为模板语言嵌于Castle框架中。

到现在已经有一年半的时间了。这期间用python写脚本越来越频繁，有一些心得体会。

原先只是写点很小很小的片段，最近的两个月，用python用得特别频繁，主要和我在做data mining有关，这期间，我有两次失败的写python脚本的经历与大家分享。

 

第一次是想写一个递归检查某个文件夹下，是否有重复的文件，作这个工作的软件很多，我google过，发现都太复杂了，搞得我都不会用，终于一天，由于我的硬盘实在是没有空间了，加上我还想腾出空间来装ubuntu，于是决定动手写这么个脚本。

我当时的思路时，判断文件的大小，是否一致，先把重复的文件分组显示出来提示你，之后再点y进行删除，这里面的核心是我用了一个reduce函数，来将一个文件和其它所有的文件进行比较，看看两两是否大小一致，如果一致就将它归为一组。这个思路没什么大问题，但在细节处理上，可能有些疏忽，总拿不出正确的结果，结果这时同事说了，可以用md5的方式来进行校验，我一想心就凉了，我走了弯路，不过我想，我都写到这个份上了（已经写了将近１００行代码了，我不愿意放弃重来），还是继续写，把bug找出来，顶多以后这段代码不能复用了，这次用完就扔了，结果后面我折腾了两个小时，搞得筋疲力尽还是没有成功，到晚上８点多，只好下班回去了，很是郁闷。

这件事情是由于我没有果断的放弃前面将近一个小时写的代码，而再搭上了后面两个小时企图去找出bug，结果还是没有找出来。

隔天，我还是使用md5的方法，不到半个小时把问题解决了。

总结一下我觉得有几点启示：

1. 要判断形式勇于放弃，不要一根劲式的一条胡同走到底，如果我知道后面要再花两小时，当然我不会这么蛮干，缺少预见性。
2. 在动手写之前，思考的更加深入一些，多问一些为什么，比如：

   有没有其它的解决方案？

   把这个问题抛给别人，看别人是怎么想的？

   做一些计划，接下来我准备投入多少时间到这个脚本的编写上，如果到时间还没完成，那我下一步的策略是如何？

   潜在的风险在哪一块上

   如何将脚本良好的分解和划分，

   大致分多少个步骤来实施等等

    

    

另外一次失败的经历是发生在今天，一个脚本足足写了半天，最后，真正从绝径中走出来，仅花了二十分钟，起因是这样的：

利用sqlserver的多表关联来构建高维矩阵，因为sqlserver每一张表最多是1024列，所以我需要一个小脚本，每1000维划分在一种表内，因此我要生成这样一个创建多个表创建的sql脚本的python脚本。

之前做了一个简单的原型是直接读出所有维数，存在一个表中的py脚本，于是我就想在此基础上复制了一份脚本，进行局布的修改，这样虽然有一些冗余代码，但是也能适合我的需求了。

脚本修改的比较随兴（我还是有些注意的），但是在一些细节上调试总是调不对，而且python在调试方面，也挺麻烦，基本上我是打print的形式。

结果调试了很久还是没有成功，最后我决定，将最复杂的那段进行重定，使用最传统，我最熟悉的方式去写，结果没多久就搞定了。

这次给我的启示是：

1. 记得写注释，在写一个函数时，我原先一般都是急于要把方法实现，看结果，等到真正实现之后，由于下一个紧接着的函数或是问题困扰着我，所以我就将焦点聚焦到另一个问题的解决上了，这样一环一环下去，一个脚本下来，基本上也就没有写什么注释，有的注释是因为某些原因将脚本注释掉的，但怕后面还要看，或者是把这段脚本再恢复回来，于是写一段注释，因此一般来说我写的注释都是过时的。结果很可能，由于在写到下一个某个函数时，或是整个脚本在完整进行高试找bug时，想看某个函数中的变量，或是函数的作用时，由于当时写的很快，在变量的命名和实现上都很乱，这就给整体的调试找bug带来了很大的难度。
2. 因次，我的建议是在开始写函数之前，尝试花五分钟时间来写一下这个函数的作用。不妨放慢编写整体脚本的速度，我们的思想总是比我们实际编写的脚本要快很多，那既然是这样不妨再放慢一倍的时间来织写我们的代码，会收到效果。
3. 另外我的一点特别深的感受是要抓住整个全局的主干，就是先将整个程序的主干搭起来，大致思考分几块，比如一个Main程序，我们先把主干搭起来，不要纠缠于具体的Step1()里的一个sub()方法如何实现，很多时候我就是因为绕到sub里的subsub方法如何实现，等到真的实现的时候，我已经忘，这个子程序是为了谁工作的了。
4. Main()
5. {

   Step1()

   Step2()

   Step3()

6. }
7. 这次重写最复杂的部分的代码我就用了这个思路去处理，　结果就很简单了。
8. 还有一个心得是，一般来说完成脚本的功能大家肯定非常开心了，要么接着做下一个脚本的开发工作，或者是喝点水去休息休息，即使知道比如代码有得改进，一般会这么说，嗯，下次在这几个方面改进一下，这个代码还有得完善，结果这次用完这段代码以后，以后就再也不会去改它的代码，时间久了，下次看得时候谁还记得哪里需要改时，如果过段时间拿出来运行，只求能顺利运行就不错了，谈什么优化或是重构啊，所以我的观点时，写完一段小的脚本，无论多小，花两个小时，来看一下这段代码，思考一下，哪些代码片段值得复用（有点回到asp的时代了），把它放到自己的公用库里，这用才不至于，下次要开始一段新的脚本代码的编写时又要重0开始使劲的google,导致生产力低下。

我觉得可以用一个字来形容编写代码——织

表明你是在注入心力在编写程序。

posted on 2010-01-12 20:34  lexus 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/lexus/archive/2010/01/12/1645853.html