程序设计的一些基本原则

[介绍]

本文将对本人在程序设计方面的一些思考，逐步罗列在这里。

 

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. "慢慢干，比较快"

体会吧