《试述样本程序比赛的几个理由》读后感

《试述样本程序比赛的几个理由》读后感

最近在网上看到左总的文章《试述样本程序比赛的几个理由》，读完后感受颇多。文章揭示了很多软件企业普遍面临的问题，包括软件重用、技术积累和“山大王”问题等等。我想结合我几年的工作经验及思考历程，斗胆也谈谈我的想法。

软件业与传统行业相比，有本质的区别，软件是纯智慧的产物，是思维的结晶。至今还没有一种标准，能够全面的度量软件质量。所以我并不主张将软件业与传统行业相比，传统行业，比如建筑业，其生产过程是可视化的，且其工作量可以用数量衡量；而软件业则不然，首先软件的开发过程并不是完全可视化的（项目周报、日报在很多时候并不代表项目的实际情况），切软件的工作成果也不能用数量来衡量，代码量绝对不能真实的反映工作量，反而会误导我们。且软件本身的复杂度并没有因各种开发方法的出现而降低，反而有所提高，而且面临的业务越来越复杂。

“山大王”问题广泛存在于软件公司中，我认为解决该问题还是要靠管理（甚至是强硬的管理），而不是温和的转化，更不是神话“技术高手”。“山大王”对公司是非常危险的，首先，技术上不能有效的制约他，使他可以随心所欲的“秀”技术，“编自己爱编的程序”，造成的结果是项目的战场成为他的“试验田”。其次，项目中存在大量的“山大王”们的“专利技术”代码，使项目与人的关系非常紧密，导致项目离不开人，人不能从项目中挣脱出来，对公司、对个人都非常不利。再次，由于项目中对技术的要求往往过于现实化，使很多人对技术不求甚解，在实际项目应用中，学个三四成就开始用，用的过程中逢山开道、遇水搭桥，没有全局观，给项目留下诸多隐患，且不能形成公司的技术积累，往往“上大王”离职，身后一屁股“债”。

对于技术框架，我的感受更深。框架的泛滥，造就了大批浮躁的代码员（CODER）、蹩足的架构师和混乱的系统。曾经有一段时间，我负责面试，所有的程序员都会用SSH，同时90%的人却不知道SSH是何物。更有甚者，能够写出数据分页处理算法的程序员，有一半以上写不出来查找排序算法。再看现在的WEB项目，恐怕都已经成为流行框架的聚会了。我并不反对应用框架，同时支持使用优秀的框架。但前提是要弄清楚为什么要应用框架，应用框架解决了什么问题，为系统带来了什么好处，有什么风险，而不是为了追时尚、秀技术而使用框架。

对于公司的技术积累，我很困惑。对于软件公司，到底什么才算是公司的技术积累，源代码、开发文档、还是可运行的系统，这些都很难说。以我的经历及感受，我是不愿意接别人遗留系统的，因为接系统就要学习“坏”的东西，包括过时的文档和不堪入目的源代码。而且我认为，系统倒手次数越多，越难以为继，代码的质量并不是随着修改次数的增加而加强。我也看到很多公司都在开发自己的“核心包”，在构建系统时尽量以次为基础，这虽然提高了代码的重用性，但是效果往往并不明显。首先，这些“核心包”源自具体的业务系统，或多或少的都带有业务的特殊性，在将这些代码纳入“核心包”时，往往察觉不出这些特殊性的弊端（当然也就不能很好的订正这些问题），只有在具体使用时才感觉出差异来，造成结果是很迁就的使用。其次，“核心包”代码本身的质量并没有多少保障，在这个项目中可以正常使用，并不代表这些代码是天衣无缝的，一旦在别的项目中暴露出问题，BUG定位都比较困难。

对于样本程序，我的看法是其作用必须明确且单一，这样才会有更强的可操作性。从文中看，样本程序既是可以直接使用的软件组件（程序属性），又是供程序员工作时参考的程序范本（样本属性），还是技术积累的载体。这可能赋予样本程序过多的职责了，会使样本程序最终变成“程序堆”，失去了意义。我认为，程序的实用性和可观性并不成正比例关系，实用性强的程序未必是优雅的代码，同时，看着漂亮的代码其实用性并不令人满意。虽然我们一直在追求代码要美观、要整洁，但是再实际项目中我们往往更追求实用性，而牺牲代码的可观性。另外，我不提倡抄代码，为什么要抄代码呢，如果是相同，那直接调用；如果是不同，那就不用。对于相似，我认为最好不要用这个概念，因为这非常模糊，而程序是要求非常精确的。在实际项目中会遇到很多相似概念，这个系统的一个功能和以前做过系统中的一个功能很相似，所以考虑抄旧系统代码。出发点是为了减少工作量，实际往往噩梦就开始了，旧系统代码的质量不说，单单查找业务差异就令程序员汗流浃背的（毕竟相似不是相同），一通干下来，其工作量并不比独立开发少。而且，程序员是非常自信的人，在程序世界里他们就是造物主，所以在一般情况下他们是不愿意去使用别人的代码的，特别是糟糕的代码。我也曾经多次面对“前辈”们的代码，心潮澎湃，想推到重来的冲动，而且确实实施了几次，结果我的后来人也在学我。

最后，我谈谈我对程序的看法。我认为，好的程序，是很难衡量出来的，对待同一段代码，总是有见仁见智的看法。目前，我还没有看到，有一套标准或规定，来界定好的代码。但是，面对坏的代码，我们却经常高度的一致。在这种情况下，与其追求好的“样本代码”，不如去界定坏的“样本代码”。这样，我们会怀着更宽容的心来看待代码。如果追求“好样本代码”，会认为除此以外的都是坏代码；如果界定“坏样本代码”，则可以认为除此之外的都是好代码。同时我们也给程序员一个更宽松得工作空间，以前，我告诉你们怎么做是好的，现在我告诉你们怎么做是坏的，其余的可以尽情发挥。这对我们可能更有意义。

以上内容，只是我的经验总结和个人感觉，不存在肯定意见，也没有否定观点。是看到文章后，随笔而为之。内容多有偏颇之处，还请海涵。