C/C++/Java 语言编程的可读性
[
2004/02/13 18:24 | by haryewkun ]
2004/02/13 18:24 | by haryewkun ]
读大学的时候，写的程式都是小意思，也从来没有计较程式的可读性及修改性。那时候，写的最多只有自己同组的几个同学看，维修也是自己干，教上来教授评分完了之后就算了，还修改什么劲？
那时候，以为所谓的「可读性」，就是在程序中加多一些注释(Comment)、Function 取名的时候写得长一点、贴切一点，还有使用匈牙利表示法。。。
现在发现，这样，还是不够的。
再多的注释，都是不足够的。
程序的结构，除了要考虑程式运行的速度、编码的效率之外，居然还要考虑到人类阅读的考量。对我来说，这个发现，有点匪夷所思。程序的结构设计，原来也好像房屋设计那样，不是只要能够住人就好的，还要考虑到老板会基于界面上的修改、功能上的改变。。。那根本就是一种艺术了。
那些老板可能会要求更改，要用这一种编码方式来实现。
那些老板不大可能会要求更改的，要用另一种编码方式来实现。
虽然两种编码方式所执行的都是同一样的东西，可能是同一个 button、GUI、读取 database。。。编码的方式却要千变万化，才能因应不同的状况。
举列来说，一个 Dialog Box 跳出来问 Yes/No，就必须看不同的状况，来决定它应该出现在源代码的那一个部分。要把全部界面集成在一个档案里面？还是放在主程序中？还是要在主程序中开一个小function？
在编程的角度来看，每一种都是会达到同样的效果，效率也没差。差别大的事情，是可重用性、整个系统的更新及程序可读性。
大学的时候读书不用功，不清楚有没有课程教到这些学问及奥妙，但我认为，应该是没有吧。
我想，这种统一的可读性，是印度软件工程师的强处吧。华人的软件工程师，根本就不会想到这个问题。同一个功能，一百人就有一百种写法，理由是「反正都能完成工作，效率也没差，不同写法又有什么关系呢？」
那时候，以为所谓的「可读性」，就是在程序中加多一些注释(Comment)、Function 取名的时候写得长一点、贴切一点，还有使用匈牙利表示法。。。
现在发现，这样，还是不够的。
再多的注释，都是不足够的。
程序的结构，除了要考虑程式运行的速度、编码的效率之外，居然还要考虑到人类阅读的考量。对我来说，这个发现，有点匪夷所思。程序的结构设计，原来也好像房屋设计那样，不是只要能够住人就好的，还要考虑到老板会基于界面上的修改、功能上的改变。。。那根本就是一种艺术了。
那些老板可能会要求更改，要用这一种编码方式来实现。
那些老板不大可能会要求更改的，要用另一种编码方式来实现。
虽然两种编码方式所执行的都是同一样的东西，可能是同一个 button、GUI、读取 database。。。编码的方式却要千变万化，才能因应不同的状况。
举列来说，一个 Dialog Box 跳出来问 Yes/No，就必须看不同的状况，来决定它应该出现在源代码的那一个部分。要把全部界面集成在一个档案里面？还是放在主程序中？还是要在主程序中开一个小function？
在编程的角度来看，每一种都是会达到同样的效果，效率也没差。差别大的事情，是可重用性、整个系统的更新及程序可读性。
大学的时候读书不用功，不清楚有没有课程教到这些学问及奥妙，但我认为，应该是没有吧。
我想，这种统一的可读性，是印度软件工程师的强处吧。华人的软件工程师，根本就不会想到这个问题。同一个功能，一百人就有一百种写法，理由是「反正都能完成工作，效率也没差，不同写法又有什么关系呢？」
以前读书的时候，写的程式根本没有经过压力测试，不管是资料库也好、运算法也好，用的 data 都不会很大，充其量只是几十个数据。现在写科学性的模拟程式，计算数据是很正确，运算法也没错，但却没有考虑到压力的问题。
现在发现，有大负荷的程式的架构不能像以前那样写。。。一下子丢一个 20x 20x 20 的空间下去，已经是八千个点，走得好好的程式立刻负荷不了当掉。就算程式优化，速度加快一倍，下次丢一个 40x40x40 的空间，还是一样会挂掉。好！既然别人写得出来，就一定是我自己的程式功力不够！
所以，要知道用怎样的语言及环境，才能最佳运用运算资源。理论上来说，不同的语言应该有它本身的创造目的，易于上手的(VB)编程出来的程式速度没有C/C++快，Java虚拟机安全性高但执行效率就没有机械码来得快。。。
听说，运算速度最快的是 C/C++，图形显示最通用的是 DirectX，但便携性又不能符合我的教授的要求，Java 因为虚拟机的关系，便携性及安全性都高，但我很担心它的执行效率。
夸张一点的话，如果要写一个模拟核子弹爆炸的原子碰撞(就像美国那些老外干的)的简易版，除了模拟的速度快速及正确之外，还必须要有图形显示把过程即使 show 出来(DirectX/OpenGL)。这个软件可能在Windows 上面执行，也可能在 Linux 上面执行。基于这个目的，要使用什么语言开发呢？
现在发现，有大负荷的程式的架构不能像以前那样写。。。一下子丢一个 20x 20x 20 的空间下去，已经是八千个点，走得好好的程式立刻负荷不了当掉。就算程式优化，速度加快一倍，下次丢一个 40x40x40 的空间，还是一样会挂掉。好！既然别人写得出来，就一定是我自己的程式功力不够！
所以，要知道用怎样的语言及环境，才能最佳运用运算资源。理论上来说，不同的语言应该有它本身的创造目的，易于上手的(VB)编程出来的程式速度没有C/C++快，Java虚拟机安全性高但执行效率就没有机械码来得快。。。
听说，运算速度最快的是 C/C++，图形显示最通用的是 DirectX，但便携性又不能符合我的教授的要求，Java 因为虚拟机的关系，便携性及安全性都高，但我很担心它的执行效率。
夸张一点的话，如果要写一个模拟核子弹爆炸的原子碰撞(就像美国那些老外干的)的简易版，除了模拟的速度快速及正确之外，还必须要有图形显示把过程即使 show 出来(DirectX/OpenGL)。这个软件可能在Windows 上面执行，也可能在 Linux 上面执行。基于这个目的，要使用什么语言开发呢？
熟悉編程的人，或多或少，都曾经幫人家写過一些程式吧！其实我发现，编程的世界里面，根本没有一个正式的市价可谈。我曾经问过我的朋友，某些程式要开价多少，他的回答是：「你能拿多少，就开多少！」
也就是因此，一个普通的程式，有人可以开两百元，有人开到一千元！总之混乱之极，毫无规律可言。这样不但对于客户不公道，对于写程式的人，也一样不公平，盈利全都归于你是否愿意狠狠地敲诈顾客一笔而已。
1) 业余的程式人员，开价必定会低于 专业编程公司(software house)：毕竟，办公室的租金可以省了，固定的薪水支出也省了，正版的开发软件也省了。
2) 不能以开发时间来决定酬劳：有的人功力差，简单的程式也要花上一个月，这样决定价格对于顾客是很不公道的。
3) 开发人员的成本应该是时间来衡量：基本上，程式开发除非要买参考书及上网之外，几乎不需任何时间之外的任何成本，尤其是现在 Streamyx开始普遍，上网费用每月最多几十元。
4) 不能以供需情况来决定酬劳：顾客不会理会你用什么程式来开发，他们不会懂什么是 DELPHI，VB，VC，他们所要看到的只是效果。一千人中可能只有你能做到用VC来开发WINDOWS 程式，但如果效果没有差别，那也不应该拿更高的酬劳。
造成价格混乱，还有一个原因，就是程式重制的成本几乎为零。
我们有两个程序员，一个是程序员A，一个是程序员B，程序员A曾经在学习的时候开发过一个资料库显示的程式。有一天要客户要他们报价，程序员A只需要修改一下之前的程式，就能再次运用，程序员 B 则需要重新开发。很显然，在两人都是业余的情况下，前者的报价一定远远比后者低。
我们假定说一个很简单的程式，嗯。。。就说是一个连上网络界面的资料库程式就好了。有一个客户，他需要一个 application (web 也好，stand alone也好)。他的部门有十个人，以LAN联接彼此的电脑，有一位小姐负责输入每天的 SO (sales order)。他要你写一个程式或资料库(database)，储存那些 SO 的资料，而且 SO 的资料要很方便的被其他九个人查询 (real-time query)。
我們可以写一个 web application，也可以用 VB/DEPHI 写 stand-alone application，但是，我們当然不可能要求那位小姐type 在office的 EXCEL files里面，寄给别人吧，呵呵。
我相信这样的程式不是很困难，问题是大衆会对这样的程式开价(fair price)多少呢？ 要用多久的时间完成呢？基於什么理念来决定酬劳多少呢？
也就是因此，一个普通的程式，有人可以开两百元，有人开到一千元！总之混乱之极，毫无规律可言。这样不但对于客户不公道，对于写程式的人，也一样不公平，盈利全都归于你是否愿意狠狠地敲诈顾客一笔而已。
1) 业余的程式人员，开价必定会低于 专业编程公司(software house)：毕竟，办公室的租金可以省了，固定的薪水支出也省了，正版的开发软件也省了。
2) 不能以开发时间来决定酬劳：有的人功力差，简单的程式也要花上一个月，这样决定价格对于顾客是很不公道的。
3) 开发人员的成本应该是时间来衡量：基本上，程式开发除非要买参考书及上网之外，几乎不需任何时间之外的任何成本，尤其是现在 Streamyx开始普遍，上网费用每月最多几十元。
4) 不能以供需情况来决定酬劳：顾客不会理会你用什么程式来开发，他们不会懂什么是 DELPHI，VB，VC，他们所要看到的只是效果。一千人中可能只有你能做到用VC来开发WINDOWS 程式，但如果效果没有差别，那也不应该拿更高的酬劳。
造成价格混乱，还有一个原因，就是程式重制的成本几乎为零。
我们有两个程序员，一个是程序员A，一个是程序员B，程序员A曾经在学习的时候开发过一个资料库显示的程式。有一天要客户要他们报价，程序员A只需要修改一下之前的程式，就能再次运用，程序员 B 则需要重新开发。很显然，在两人都是业余的情况下，前者的报价一定远远比后者低。
我们假定说一个很简单的程式，嗯。。。就说是一个连上网络界面的资料库程式就好了。有一个客户，他需要一个 application (web 也好，stand alone也好)。他的部门有十个人，以LAN联接彼此的电脑，有一位小姐负责输入每天的 SO (sales order)。他要你写一个程式或资料库(database)，储存那些 SO 的资料，而且 SO 的资料要很方便的被其他九个人查询 (real-time query)。
我們可以写一个 web application，也可以用 VB/DEPHI 写 stand-alone application，但是，我們当然不可能要求那位小姐type 在office的 EXCEL files里面，寄给别人吧，呵呵。
我相信这样的程式不是很困难，问题是大衆会对这样的程式开价(fair price)多少呢？ 要用多久的时间完成呢？基於什么理念来决定酬劳多少呢？
