面对困难的代码，分解困难各个击破

怎么说呢，最近遇到一大堆程序的时候真的有点手足无措，感觉很被动阿。

迎难而上才能有所得。这次的经验是面对一大堆要写的代码该怎么办呢？
答案：先搭框架！
其实上面这四个字着实有点太忽悠人，写代码少的人很有能够真正理解框架是什么意思。其实这个词含义真是太丰富了，可是现阶段我自己的所谓的框架，就是要完成我的功能，需要添加的代码的结构。

1 分解的过程，也就是理解和总结思路的过程，这种形式的分解粒度可能会比较粗，这种形式分解结果将其写在纸上。包括model，behavior等等。

2 假如现在准备写某一小块的代码了，可是由于代码可能也不是那么直接，可以在更具体的级别再进行一次分解。这次的分解结果函数之间可以写出函数体，函数内部可以将分解的各个块的注释一一罗列。然后在写代码的时候不断的填充这些函数和注释和分解这些内容即可。

P.S. 自己在写程序的时候，不论是同一模块或者是不同模块的关键的接口函数的注释一定要清晰，注释要包括此接口函数的粒度，在整个模块中的位置，参数类型，参数的意义等等。。不然后果不堪设想。

补充1:
有时候在大框架时候，也一时不知道该如何各个步骤去做什么？这是因为要写的部分的运行机制没搞清楚。这个时候，应该抛开代码，找到机制的核心最关键部分，画出图和数据结构来，理一下这部分怎么成功运行的。然后在将其按照上面说的“注释化”，“代码化”。
总结：这是个由粗到细循环往复的过程。精简如下：
核心机制--->机制分解细化--->机制分解具体化---->想好程序接口---->将接口内部的代码注释化---->"代码化"
在上面最后一步的代码化的过程中，可能就又进入了上面的这个思考流程中，这是由粗到细逐步细化代码的过程吧，我是小菜，不断总结学习。

补充2:
进行补充1中的注释化的时候，要注意很好的区分程序的层次，即是将逻辑处理层，物理操作层区分开来。其实这也就是由粗到细的过程，粗的层面可能对应于逻辑控制，细的层面可能对应于更加细致的逻辑控制或者是物理操作。因此一开始先注重逻辑，而不要太容易陷入物理操作，这样也是在不断的开发过程中明确需求的好办法。
在写某个函数的注释化的过程中，要定位此函数的操作粒度，是高层次的逻辑处理层，还是低层次的物理操作层，不要将不同粒度的操作写在一起，同一层次的操作的粒度要尽量趋于一致，这样有利于层次的划分。

补充3:
要认清自己在写的代码的定位，然后用不同的方法来研究需求。比如说以前写的代码是应用型的代码，下层都有完整的接口，只要想清楚用户希望把产品做成什么样子，那就利用这些现成的接口去做就好了，技术思想的要求上真的没有那么高。

可是现在我自己在写文件系统，首先在上层碰到的问题是我该如何设计向上层，向用户提供的接口？他们需要什么操作？各个操作的参数又应该是怎么样的？需要好好学习这一块。
现阶段再没有强大理论做指导的情况下该如何设计接口函数呢？最简单也是最实用的方法是--站在用户的角度尝试着去使用这个库，将接口函数设计成用户使用最方便的样子。

接口函数的声明定义要包括3方面：

• 各个参数的意义，参数是I/O。
• 函数真正的功能，就是说此函数究竟想去干什么。
• 返回值的意义，是不是不同的返回值代表不同的意义？比如是不是-1代表出现错误了？

只有接口函数使用时候的以上3点的需求都是清晰的了，我们使用interface function的User才能更加了解程序，对于开发接口函数的人来说这就是需求，我们需要了解清楚以上3点的需求，才能写出好的接口函数。

补充4:
作为一个模块库的开发者，需要分清楚错误的来源，从而区别对待。
假设用户调用open函数来打开一个文件：

• 如果是因为用户输入的参数导致的打开文件失败，FileSystem里面处理这一块的函数要尝试将错误码层层的返回给User调用。
• 如果碰到譬如inode用尽这种情况，不用再返回给用户了，这种严重的系统错误就直接panic暂停系统就行。

当然在写程序的时候，主线还是将错误码层层返回给调用者User。在遇到严重系统错误时候，单独对待处理。

补充5:
在阅读别人的代码时候。先提前思考下要是自己去写这段代码会是怎么样的布局，会去怎么样写。自己真正的去思考过了，再去看别人怎么写的，再去取长补短，这样也容易理解对方的代码。