Linux/Unix弥久长青，设计思想有何独特之处？（获奖名单已公布-2012-5-22）

asuka2001

太可恨了...这样的好书来勾引人啊

书单已经够长了,消化不了了......再这么加下去没机会看看小说啊啥的了,郁闷

“你为什么喜欢Unix? “
简单点说就是Unix是学习收敛的,不像某些操作系统,数千个API...坑爹哦,写应用程序会杯具到什么样啊....还是算了吧.
俺觉得这句话不错: 困难的路越走越容易,容易的路越走越困难!所以即使某操作系统看起来很简单,我还是选看起来困难的路吧!


你会身体力行unix/linux哲学中的哪些？为什么？
以前写应用层程序,体会编程的精髓其实和Unix的哲学很近似;所以要我说那就是
1. KISS
2. DRY
3. 提供机制而非策略
4. 依赖抽象而非实现
5. 一次只做一件事
为什么?这个实在不知道怎么回答!我想不出为什么不这么做......只能说本能上认为这样做才对吧!

asuka2001

条条道路通罗马...大道至简,基本上都是一回事,哎!

asuka2001

只要上升到哲学，大道之类的高度，大家都会觉得说的有道理，实际用起来还是一头雾水！我也没法说清楚，只能简单的说下个人体会！

1. 提供机制和依赖抽象是一体两面：模块本身提供的是策略，使用者就谈不上依赖抽象！

提供机制的好处在于，除了数量有限，预定义好的正交性接口（机制），模块与其他部分没有耦合；而机制本身的正交性可以最大限度的满足需求！模块此时是内敛的，这也是Unix系统为什么能保证稳定的API的缘故！和某个操作系统那疯狂膨胀的API成鲜明的对比

依赖抽象的好处大家都明白，然而如果不是因为你依赖的模块提供了机制，你如何能够使用抽象来满足你千变万化的需求？当你不得不寻求实现来解决你的需求时，必然存在你所依赖的模块没有提炼出来的机制！



2. 逻辑分层的重要性---只做一件事

从我们的实际需求到最终实现之间，存在太高的落差，想一步而就是不可能的。希望降低复杂度，化繁为简，那就轮到逻辑分层出现了。在某个逻辑层次上，我们将不在关注底层的实现，而是信任底层提供的机制可以满足我们的需求。

只做一件事的精髓就在于在同一逻辑层上，他只完成单一功能。如果举个不太恰当的比喻，那就是他只对更上层逻辑层次提供机制。正因为所处的逻辑层次更高，可能这里所提到的机制将更加靠近最终的需求，也就包含更多的策略(使用更底层逻辑层次提供的机制)。但是在他所处的逻辑层次而言，他仍然是只做了一件事，仍然是提供的机制！

3. DRY---它在向你告警

每当看到重复的代码时，我就会抓狂，当将重复的代码提炼出来，将某些代码差异排除出去时，就完成了一次提炼机制，排除策略的过程。

只是需要注意，似是而非的重复，两段代码可能会偶然的有些相似，但是其实他们之间不存在共性，这个时候希望实现代码的复用，会给你自己带来麻烦！

当有的时候为了代码复用，而造成代码可读性降低和引入复杂性时，你就需要注意考虑这是不是似是而非的重复了，不要一味的消灭代码重复而完全不顾忌其他！


4. KISS --- 不要做不需要做的事

我们的最终目的请牢记，是为了满足最终需求。当你陷入到实现细节中，不断的扩充自己的代码规模时，请时刻停下来想一想这是不是你所需要的。常见的问题在于为了可能并不是关键性的需求而为了性能，为了扩展性花费极大的工夫！

盲目的实现很可能达不到你预期的目的，想一杆子买卖做出一个完美的程序是不现实的。更明智的做法是在保证自己的实现满足最基础的原则的前提下，尽量简单！简单的程序容易理解，容易扩充，也节省你的工作量！



5. 请学会折中---程序员最重要的素质

在我看来，折中才是程序员最该具有的素质；任何的规则都是用来打破的，只要你能全面的衡量利弊！所以请自己做好取舍吧！世间没有万能药，也不存在放之四海而皆准的原则，原则只是做大方向上的指导，衡量它所带来的好处与弊端，才是你最需要具备的能力！

asuka2001

回复 30# GFree_Wind

一点个人愚见：管道就我个人理解，应该是以数据为中心，从最初输入到最终输出，不断的在其上通过各种单一功能的程序（它们提供机制，它们只做一件事情，由我们用户提供策略）进行数据加工，不断的靠近最终需求的过程。

可以说这个完全符合软件编程的模块化思想与机制策略分离等一系列原则。而且更加进一步，因为程序与程序之间的耦合是0！

唯一的缺点在于我们的需求空间太过广阔，完全的串行数据处理能力可能无法完成某些特殊的需求，复杂的策略也很难作用于管道之上，不然我们所有的复杂，专用的程序都可以抛弃了：（

asuka2001

回复 39# 无锋之刃

管道是机制,它提供的功能就是串行数据流动

单个的程序其实也是机制,它们提供的可不是仅仅针对你的一个任务!比如grep,它提供的是过滤器的机制!只有当用户加上策略时,过滤器开始发挥它的作用!


更进一步的说: 机制和策略的区分可不是绝对化的,没有需求和实现做背景参照,我们谈论机制,策略没有太多意义.

我在前面的发言中,提到了逻辑分层.提到了越靠近需求,那么机制中混合的策略越多(这里的策略指的是怎么样使用下层逻辑层次的机制)

但是混合有针对下层逻辑层次的策略,还叫机制吗?我认为是!理由是在它所处的逻辑层次上,它是只做了一件事;在它面向的需求空间上,它是正交切分需求空间的,因此它是机制!


因此可以看到,管道它面向的需求空间是数据通道,因此它不加任何假设的让输出数据流入下一级的输入中.这是它提供的机制!但是它离我们的需求显然很遥远...我们需要加入策略,对数据进行加工

单个的程序是机制,因为它们面向用户的需求时,它们只做了1件事,它们无法直接完成用户的需求,需要我们去输入策略.但是如果就管道而言,它们是策略,它们利用管道,并在管道传输过来的数据中,进行策略处理....不然数据只流动,就没有任何意义!




   

asuka2001

回复 50# 无锋之刃

另外，仅仅实现数据流动并不是没有用的。考虑一下tee实用程序，它实现了数据流动而不加以变换的功能，也相当有用。

=====================================================================

恩，感谢指正。

我想表达的意思是：管道本身不包含策略，距离用户的需求太过遥远，仅靠管道是无法满足用户的。

正因为机制距离需求过于遥远，我们才需要引入中间的逻辑层，它们对下提供策略，对上提供机制，不断的逼近需求，最终达到满足用户需求的目的！

反观专用软件，可以说整个策略全部包含一身。所以我才会说管道走得更远，但是世上没有万灵药，它也有自己的不足，不然也许世界只剩管道和小组件了，世界大同了，程序员就解放了；我们都共产拉，社会就河蟹拉：）

asuka2001

回复 77# wau213


同感啊，握手！上次买个本本，折腾得死去活来，Ubuntu 11.10和 Fedora 16都没着，郁闷了，直接当服务器使用算了！