编程感悟：如何写好程序

首先声明，我不是高手也不是老手。下面的内容如有错误或是不合理的，请各位看到的一定要告诉我！^_^!
今天本来在看书《windows 核心编程》，看来一会儿发现做了这2，3年的开发，也写了几万行的code，应该总结一下比较好。记得2年前看过一个林斌在清华大学讲如何写好程序的视频，现在想起来有点体会，写一下，以免忘记。

对于我们这样的以程序开发为生的人来说，我们的职责就是让我们的程序能工作的好点，再好的。这有点类似于服务行业“我们要让我们的服务是一流的”。所以我们每天写它个一两百行代码是正常的事情，说简单也简单，说难也难。行内有句话：对于相同功能的程序，100程序员有100种写法。那么有什么差别呢？我想无非是想的多想的少而已。这句话如何理解呢？
我是这样理解的：考察一个程序的优劣性有很多个方面，第一，可用性，即在正常的输入情况下不能错，这是最基本的，你要是去银行存1w，它把你处理成1k，你不得把银行拆啦$_$！第二，在第一的基础上增加有效性，同样一段程序你的要跑10分钟，而别人的只用1分钟，那么你的程序不可能是好的程序，而这点正是好的程序的开始，关于这点涉及到的知识与方法可能跟人比较相关，所以我认为程序员之间差就差在这点上。那么我们怎么去考察这点呢？我个人认为需要从下面几点来看：
一是解决方案的选用，这点涉及到你对业务的理解。
二是这个方案是否最优，这点涉及到你对操作系统的理解，对数据结构的理解，对语言的理解。不要重复的造轮子，除非你自信造的比现有的要好！
三是实现的难度和时间，这点是不可少的，如果你的方案太难实现或是需要太多的时间实现，我估计你的boss是不会答应的。
第三点是可维护性，好程序是易于维护，毕竟对于一段程序，你写的也好，他写的也好，我们都只是过客，匆匆的来，匆匆的走，唯一能做的是让别人工作更轻松一点，自己也能轻松点，现在的程序在编译时都可以用混淆器来混淆代码了，所以我们不需要你把code写的让人看不懂#_#。对于这点，跟程序员的代码风格有关，也和细心有关。

说了这么多理论性的东西后，你会说那么如何才能写出好的程序呢？我想这是没有唯一答案的，唯一的只是好程序不是写出来的，而是改出来的。这个世界上没有完美的程序，即使是google的也是一样，否则就不需要人维护了。我个人的观点是，一个程序在你发布出去之前，不能少于3遍的修改，第一遍实现了可用性后，扔掉；第二遍，从有效性的角度去考虑问题；第三遍，才是维护性的内容，你的风格，变量命名，采用模块的方式，错误的处理等。

所以，我的观点是：
操作系统提供了，就不要自己写，如果有更好的API就选择更好的API。
使用合理的数据结构，就像你考虑使用数组和链表时的那样。
尽可能的使用数学的方法去完成工作，这个我想看过几篇文档的人都知道。
尽可能的使用模块化，不要以为这个只是OOP的专利哦。
合理的使用空间来换取时间。
不要钻牛角尖，也不要依赖心理，优化需要先考虑整体，在考虑局部，最后考虑编译器。
所有的结论都通过数据来证明，不要自以为是。
让你的程序看起来和别人的差不多（风格问题）。
程序员是勤快的，懒的只是他的工作，多让电脑干重复的活，你所要作的是让它更好的工作。

对于变量：能不全局就不要用全局的，能不静态就不要用静态的，能不新声明就不要新声明。
对于值参数：考虑类型，考虑边界，考虑初始值，考虑内存分布。
对于指针参数：考虑类型，考虑空，考虑输入输出，考虑是否会被修改，考虑与值类型的区别，考虑是否可以用引用或是句柄代替。
对于函数：考虑参数个数，考虑返回值，考虑调用那些库函数和API，考虑作用范围，考虑是否递归，考虑命名，考虑错误处理，考虑被调用的次数，考虑效率，考虑并发的可能，考虑资源的分配与释放。
对于类：考虑设计模式，考虑通用性，考虑成员函数接口最小化，考虑资源的分配与释放，考虑被继承的可能性，考虑多实例，考虑扩展的可能，考虑并发的可能，考虑抽象的意义，考虑独立性。
对于模块：考虑维护性，考虑复用性，考虑多进程共享，考虑是否动态载入，考虑平台移植。

以上这些就是我自己对写程序的感想，一人之见！^_^!