程序设计的一些基本原则
[介绍]
本文将对本人在程序设计方面的一些思考,逐步罗列在这里。
note: 此类文章/书籍,多如牛毛。对比它们,本文并不会出现什么新的概念、思路,都是人家说过的,总结过的。如有侵权,请指出,我将给出引用。
note: 它是我在工作中的一些问题/思考总结,附上一些实际的例子(经历过才更有感触)
note::“想的太多,行动太少” 是大忌. 如果你觉得一些东西对你有帮助,请行动起来,应用到你的code里面去
*. 你知道你的程序的运行行为
当写完一段程序的时候,你应该对该程序非常了解,充满信心
-输入,输出 - 这个肯定都知道
-错误情况,会发生什么,如runtime exception, checked expection
-性能咋样
-对其他系统/lib的依赖,即使你不了解那些依赖的系统,请非常清楚接口!
看过一个歪果仁写的文章,他要了解系统从上到下的所有细节,才能充满信心。譬如在写web程序时,他会把ngnix,tomcat之类的源码翻一翻。抱歉,忘了他的名字。
非常能体会他的感触,不过他这个是极端的例子。如果我们都能深入最根本/底层最好,但是项目上可没这个时间。起码,我们确信一些基本的东西。
note: 本条放在最前面,是因为我见过太多的反面例子!! 如果你见的不多,那么1) 你身边高手如云,约么?:) OR 2)上面我没有表达清楚 OR 3) 你没深入去想
* 减少调用层次
a->b->c->d->e->f->g->h->i->j->k->l->m-n
调用层次太深,极大增加程序后期维护成本,以及出问题时trouble shooting将比较困难。
读浅调用层次的代码,会有一种感激代码作者的感觉
note: 如果我们引用的第三方的jar包,那么jar包的作者他自己负责其程序的复杂性。我们只要看我们程序到达调用该jar文件的深度就可以了。
例子: java NIO中JNI中的调用就减少了调用层次。对于如下IO中的RandomAccessFile.read() 和 NIO 的FileChannel.read. JNI程序在NIO中大大简化,两步就调用的kernel IO.
IO call stack - 5 levels after JNI to reach kernel IO
read() of RandomAccessFile and FileInputSteam
JNI -> readSingle(io_util.c)-> IO_Read(io_util_md.h)->JVM_Read(jvm.cpp) -> os::restartable_read(os_solaris.cpp)->Kernel ::read
NIO call stack - only 2 level under JNI to reach kernal IO
read() of FileChannel
read(ByteBuffer dst) (FileChannelImpl.java) -> IOUtil.read(IOUtil.java) -> IOUtil.readIntoNativeBuffer -> read(FileDispatcher.java) -> JNI FileDispatcher.read0/pread0 ->kernel ::read, ::pread64
例子:一个反面的例子就是JDK URL.hashcode()最终给出了相当相当深的调用栈
此文http://winnerbao.iteye.com/admin/blogs/2218624中给出了调用栈
http://dl2.iteye.com/upload/attachment/0109/4213/79904add-47c7-3037-853a-ae010764b9d1.png
* 减少线程
这已经是一个基本的共识了,这里我给出几个例子
它不仅简化程序,而且提高性能。
note: 不要较真:简单,但不能太简单
例子: LMAX Discruptor
一个非常牛X的高性能框架,它的核心之一就是单线程。
例子: Coral 8
一个CEP(负责事件处理)引擎,它的核心之一,也是单线程。如果你追求高性能,请考虑单线程。
* 不要预留扩展接口或者扩展功能,除非真的必要
什么是真的必要? 就是“你觉得必要” 。我又在讲废话了!
工作中,经常听到这样的说法:我这样做一些扩展,以后如果有客户/其他人想使用XX功能,我们就可以非常方便的扩展我们的程序,甚至只要改一下配置就可以了。
这是真的么?这是真的么?这是真的么? 三遍
原则:保持程序简洁性,使得其在遇到真正的需求时,容易调整。而不是臆测一些需求。
note:我不排斥增加一个可能变化的功能。相反,我经常这样做。但是每次我都觉得自己有充足的理由。我知道:你也是!
note:本条比其他条目更加主观。多做项目,踩更多的坑就会增长这方面的能力 :)
[待续]
====下面这些内容放在这里并不合适,发现合适的地方以后移走====
1. 几个月以后,回头看你的程序/设计/任何成果,一般会发现自己当时做的好烂
好消息,你成长了
如果你发现自己当时已经做的很好了,大神,认识一下?我的QQ: 35=131=698
2. "慢慢干,比较快"
体会吧
已有 0 人发表留言,猛击->> 这里<<-参与讨论
ITeye推荐