你是在设计程序，还是在写代码。。。 热：报错

其实标题的内容，和你是程序员还是码农，是一致的。最近在做些原型设计，正好要写完整文档。就把我的一些做法说说。哈。

1、需求分析。打算做什么，如果这个事情，已经有可替代的了，那么ok，了事。不过既然做原型，希望以后可以代码级的整合，好为后期特定业务场景的优化做基础，除非有可独立的模块的源码，否则对于c的开发，很难说有可替代的。但对诸如面向对象等更高级的程序开发，包包，类类的选择，很重要，选择的判断依据也是从需求分析来的。

2、基础数学原理和系统模型。别tm不看中数学。我发现我的短板全在这。集合化的描述方式非常有助于对系统模型的阐述和分析。这个和具体语言还没有关系。

3、输入，输出的数据结构的设计。他们确定后，才能稳定住接口。而他们确定前，需要根据系统模型把该实现的纳入，但凡需要组合实现的剔除（当然这个针对c的模块化设计，面向对象的高级语言相关开发方式没仔细研究过）

4、上述数据结构对应空间的维护设计，诸如create ,destory, set ,get ,check。基本跑不掉这几个基础的。

5、根据系统模型，细化原子操作，与自底向上的设计思想很象。原子操作便于测试，也方便由它决定该操作前后的数据结构。

6、根据各个原子操作，将系统模型的整体结构细化出来，该调用的调用，该判断的判断。不过调用也好，判断也好，无非都是状态迁移，与其说难，不如说烦。

7、最后根据上述设计文档，写一堆函数和宏，组织组织。

8、进行代码实际的实现。

前面7步，都是设计程序，最后第8步，是码农的干活。如果函数接口都确定，函数内部操作逻辑都确定了，测试点也就明确了。

测试实际上分两大类，

代码实现的测试。这个和码农有关系。系统模型可行性的测试，这个和系统设计有关系。

我不知道有多少码农反复测试，反复debug，是否搞清楚了哪些是代码实现的问题，哪些是系统结构的问题。

不是我反对框架和架构。但真心看不起，系统设计还没到第7步时，就到处找架构的小白。利用别人的框架和架构是为了省事快速的实现系统。而不是系统的设计本身。系统的设计，源头是需求分析，只有在外部可利用的框架大部分的满足系统设计要求时，才对系统设计做局部的妥协。

所以我说，真心看不起，基于某某框架下开发的小白。这和利用某某框架实现某个系统，完全是两个概念。因为后者，即清楚了系统结构，也清楚了所利用的框架的组成特性。

哈，好好喷喷小白码农们，希望能引起其中一部分上进的小白的注意，，尽可能的抽空多思考设计本身，而不是基于某个框架码代码，或许这对你以后多挣money有帮助。没想法的，你爱怎么喷我怎么喷我，反正我又不掉肉。

另外有空多看看数据结构，操作系统原理，计算机组成原理，编译原理，别看不起这些基础的。现在很多的新概念，说来说去是把他们的设计原理应用在新的场合而已。正规大学老师教的是有价值的，当然具体老师的水平另谈。大学不好好学基础，就知道折腾什么java或者android的开发，做来做去，都是提不起筷子，和学会photoshop ，ps点图没有两样，除非你有艺术细胞，别人看中你的开发成果，也仅仅是那个ideal，没有基础，无论做出来什么都是垃圾。。。估计这也是很多语言增加“垃圾回收”功能的客观需求。哈。