如何写易维护和不易维护的程序

前几天把代码给同事，新员工刚来一两年，说基本上看懂我的程序了。从这可以看出我的程序是多么的易懂，当然也可能新同事水平很高？亦或是这个程序本来很easy。

事实是我那程序写的绝对的是一流的棒。

那么如何写出像我这样棒的程序呢？

1、相对好的命名

2、清晰的划分

3、清晰的文档

大概就这三点了，好像真的是没有什么新意，都是老生常谈的说法，但事实就是如此。

今天在知乎看了一个文章，说他写的比较大型代码很好读，但是随意写的一些很小规模的代码却很难读懂。我也有这种感觉。前些时候写了10个8个C文件的代码反而很难看懂，我美其名曰“一次性代码”，因为在需求上我讲起归类于需求固定，且对安全性要求较低。因此开发套路上往往是想到哪里写到哪里，边写边调试，改来改去，直到最后检测不出bug。可能运行了一两年，有同事告诉我，你这程序有bug了。我一测试，果然有bug，但是我已经无力修改了！！！太难修改了，一看代码，就想吐。

写的好的代码！！？如何写？？！！！首先要看这代码值不值得你好好写？如果是以后经常用到，或者是别人能经常用到，像我这样很多同事都用我写的api，他们不关心内部。这样是不是感觉很有成就感！！既然如此那就好好写吧。从哪里下手？？要借鉴。一定要借鉴老外的东西。借鉴适合的整理结构，借鉴命名方式，要有国际范，这很重要，要完美主义，翻来覆去，翻来覆去，一遍一遍又一遍的设计函数接口，接口太重要了，太太重要了，既要考虑目前的需求和未来的需求是否都能满足，还要考虑到：你的函数接口是不可以修改的，因为很多人再用你的东西，不改函数名字只改接口参数是不可以的。一旦原先的接口有问题，而你的api已经发布了，就是说有同事已经在用你的接口函数了，那么你只能重新命名一个函数，只能如此。当你感觉这个接口已经把你搞得疲惫不堪或者你实在觉得整个程序架构基本上满意却身心俱彼的时候，可以考虑继续搞下一步了。

如何写文档？清晰的文档也不容易写？如何写？我觉得最好是模仿？仿Vxworks的模板，仿照linux的。看看他们事实上都不是绝对的完美，vxworks这么牛的公司，里面不同员工的编码风格就不一样，从他们的文档里你可以看出很多，看出他们的管理。看出到底是不是聪明人在写程序。是的聪明人写程序的套路可能并不适合你。我们都是笨人，最好稳一点。

那么如何写出不容易维护的代码？我在这方面经验不足。其实也能说明我对如何写出容易维护的代码经验也不是很足。否则怎么不知道哪些措施能让程序难以维护呢。当然不能用那些小儿科的做法。什么胡乱命名什么的。要采用的话，也要采用高深的算法。多级指针的运用。而这对于聪明的程序员也是可以看懂的，所以大概写出让别人都不懂的程序，大概很困难了。除非他的基础比较差。

所以要想写出好的程序，要有好的基础，还有一点很重要，好的习惯。书写习惯。

大概就这些了。一时兴起，连续敲了这些字，前言不搭后语，估计。

我这博客主要为了自己看。

估计没几个人看。