Tinyfool的开发日记(blog)

看麦兜的时候，我总是想尽力记住麦太说的“纸包鸡，鸡包纸，包鸡纸包鸡，包纸鸡包纸……”，但是每次我都发现我的智商太低，我的记忆力太差，一方面我难以推导出来这看似简单的罗圈话里面的人生真谛，另一方面我的嘴完全不够灵活……

最近，在调试和修改一个老的Mp3代码的时候，我又一次感受到了类似的智力挑战。按下F4后会执行保存Mp3播放列表的功能。

下面是按下F4键后，函数调用关系的一个简单示意：

VK_F4(dlg_list.c) -> gmp3_save_song(dlg_sub.c) -> MP3_insert(mp3a_main.c) -> mp3_main_insert(mp3e_main.c) -> mp3_save-list(mp3e_list.c) ->mp3_save_head(mp3e_list.c)

值得一提的是MP3_insert的函数体

int MP3_insert( struct mp3_item_s *list, int sum )

{

 return mp3_main_insert( list, sum );

}

据说这样的结构是来自于当年公司的一种规划，GUI/内部Api/引擎的三层结构，从文件名很容易看到这种倾向，dlg_*就是GUI源代码，mp3a_*就是Api层的代码，而mp3e_*就是引擎层的代码。我们姑且不谈在这样的小程序里面包来包去究竟有何意义，且看看他包的到底好不好！

分层一向是解决复杂问题的法宝，为什么这个程序的分层让我感觉很不爽呢？

1. 分层没有机制的保证，流于形式
   
   因为分层仅仅是通过文件名和函数名的一些约定来进行的，所以分层容易流于形式，各层的调用方式也无法做的规范。因为没有机制的保证，层之间使用同一个全局变量，是层之间存在过度的依赖关系。
   


2. 横向的分层和纵向的调用关系
   
   分层或者文件是横向布置的，然而调用方向完全是纵向的，最后代码是纵横交错，完全没有办法看。
   


3. 没有文档
   
   这样的过度的分层即使有文档也是非常难以看懂的，何况没有文档。
   

火炬在对.net技术的争论之言论摘抄中说，“包装包装再包装，一层一层包上来，过一段估计就要有对.net的包装和抽象了，原因同上。”不无讽刺意味……