来自Unix/Linux的编程启示录

年前由于不小心坐到了自己左手大拇指导致轻微的骨裂,没有按时更新,实在是惭愧.今年给自己订了个小目标,在安顿好新工作后,每周一篇来总结这些年所学.

话不多说,步入正题

在整个探究过程中,那些经典的著作再次让我获益匪浅:C和指针,C专家编程,深入理解计算机系统(原书第3版),Linux/Unix设计思想,Linux Shell脚本攻略.前两本书购于13年,断断续续的读了许久,这一次重读令人豁然开朗,其中许多不解之处在深入理解计算机系统一书得到答案,而后两本则是年前有幸读到.其中Linux/Unix设计思想不谈技术细节,却揭示了Linux/Unix隐含的指导思想,最后一本则是从Shell出发,以实践的角度教你如何利用Shell(Bash)在Linux/Unix平台上构建有效的解决方案,实乃入门进阶必备啊.

神一样的程序员

“女娲造人”可谓人人皆知,女娲是神,而程序员是能力上最接近女娲的存在.如果说女娲创造的是真实的世界,那么程序员是创造数字的世界,我们所写下的每行代码,所构建每个程序,都在让这个数字世界变得丰富多彩.

没有哪个职业可以像程序员:赋予代码以生命,创造数字世界中的花花草草!尽管我们拥有近乎神的能力,本身却也受着NIH综合征的困扰.

程序员之殇

NIH综合征是什么/p>

Not invented here (NIH) is a stance adopted by social, corporate, or institutional cultures that avoid using or buying already existing products, research, standards, or knowledge because of their external origins and costs.

我们经常为NIH所困:在求解解决方案时,经常自认为可以做得更好或者在看到别人的解决方案会提出各种质疑.这大都是我们缺乏对当时问题解决者所面临限制的认识所造成:可能迫于时间或者预算的限制,也可能受限于当时物理资源的限制.

穿着衣服的猴子

NIH综合征的特点就是人们会为了证明自己能够提供更加卓越的解决方案而放弃其他开发人员已经完成的工作.这种狂妄自大的行径说明此人并无兴趣去维护他人竭尽全力提供的最佳成果,也不想以此为基础去挑战新的高度.NIH综合征本质上是动物天性—”嘿,我更好”的体现,就像所有的公猴都会向母猴证明”我更好”一样.

放弃已有工作成果而另起炉灶的做法无形之间浪费了大量时间.有一些技术人员在入职新公司后,往往有想推倒一切重来的欲望.我曾经有位朋友连续跳槽很多家公司,每次入职之前都信心满满,不就后就黯然离开.朋友能力很不错,但每次入职后总是急于通过推倒重来来证明自己的能力.

更糟的是,新的解决方案往往只是做了一些改进,和之前并无本质区别,再加上现代的应用往往动辄十几万行,远超出每个人所能注意的极限,这也会让程序员产生疏漏,从而使得这个问题变得更糟糕.

当然,少数情况下,新的解决方案更好,这只是因为技术人员早已了解做过的工作,从而针对问题可以提出更高的解决方案.站在现在的角度看历史,还看不出对错的话,除非你对历史一无所知.

该思想和”小即是美”相辅相成,”专注一件事”的应用最终会产生一个较小的程序,而小程序往往只有单一的功能,单一功能的程序往往也会很小.另外,每个程序只做一件事情也意味着我们可以集中精力去解决当前任务,全新全意做好本职工作.

原则三:建立原型

原型的建立是学习的过程:在该过程中可以知道哪些想法可行,哪些不可行.每一个正确设计的背后都有数百个错误的设计方案,通过建立原型,我们可以在早期剔除掉不良的设计方案,以此来降低风险.换句话说,越早的建立原型,离你的软件发布的时间越近.

你的软件发布了吗/h3>

从开始接触软件工程开始起,我们的前辈就告诉我们:”软件永远不会有开发完的时候,记住,是永远!”.

“怎么会完不成呢,我只要不做了不就行了么,现在想想,这比让一个沉迷在购物中的女人停下脚步更难(如果钱是无尽的话).编写软件亦如此,你永远都会想要加入的更多的功能.想加入的更多功能的可能不是你,或者是你的产品经理,当然你的boss也会掺一脚.

我一直在向周围的朋友传递这么一种观点”世界上唯有不变的事物那就是变“,对于软件工程同样如此.既然变化无可避免,那软件是怎么完成的管我们做事都希望看到最后的结局,但是对于软件而言并非如此.可以说,没有做完的软件,只有发布的软件.

我曾犯过类似的错误.16年我在负责一款移动端产品的开发,希望在一个月内上线第一个版本.由于个人疏忽,当我着手原型工作时离发布时间只有20天的时间了,在这期间发现原有的一些方案无法奏效,我不得不临时更改一些既有的设计.最终导致第一个版本正式发布的时间超出15天.我也曾因此被认为是个糟糕的工程师.在团队没有任何移动应用产品开发的经验下,及早的开始建立原型或许不会导致如此后果.在离开这家公司之后,我仍倍感惭愧.

原则四:舍弃高效率而取可移植性

偏向高效率往往会导致代码不可移植,而选择可移植性往往会让软件的的性能不那么尽如人意.每当有为了追求高效率而放弃移植性的想法的时候,请在心中默念以下两句话:

1. 速度欠佳的缺点会被明天的机器克服
2. 好程序不会消失,而被移植到新平台.

关于优化的两点建议

在unix环境中,可移植性的含义通常意味着人们要转而采用shell脚本来编写软件.抛开平台不谈,关于优化,我有以下两点建议:

• 不要立刻优化:如无必要,无须优化.换句话说,不要想当然的优化,尤其是在用户无感觉的情况下.
• 关注微优化:影响性能的往往只有几处,在需要优化的时候只要解决这几处就好,切莫以优化的名义重构全部.

原则五:使用纯文本来存储数据

原则六:利用软件的杠杆效应

给你一个杠杆,在不考虑杠杆质量的前提下,你真的可以撬动地球.一个人精力只有这么多,如果想要取得非凡的成就,你就必须放大自己对这个世界的影响力,这就需要你找到其中的”杠杆点”,也就是关键点.

层次化思考并并非新名词,对大部分程序员而言,”分层”是所有解决方案的指导思想,这里的分层便是层次化思考的结果.与层次化思考相关的一种分析方法是AHP(Analytic hierarchy process),即层次分析法.(关于AHP更多的信息就不多讲了),它是思考和构造复杂系统的一个基本方法,按照该方法设计出的系统具有明显的层次体系.

现实世界充斥着层次化结构,小到细胞结构大到宇宙,从小团队到跨国公司,其都呈现出层次化结构,对计算机软件而言亦如此.在层次体系中,下层构件为上层构件提供服务支撑,上层和下层之间的关系就像是方法的”调用-返回”.采用层次化设计的应用就像金字塔,先有底层构件,然后在之上构建高层构件,相对低层构件而言,高层构件更容易理解.

可以说,一个系统无论最初采用什么样的组织方式,最终都会走向分层体系.
我经常说的一句话是:无分层不架构,通俗点就是没有分层的应用是没有架构可言的.分层结构在计算机世界中无处不在,来看几个最典型的例子:

ISO/OSI七层 络模型

Unix/Linux系统分层结构

MVC & MVP

除了上述几个典型示例外,两种典型的开发方式MVC 和MVP也都是典型的分层结构:

总结

也许你会像我当初一样纳闷这么优秀的操作系统就靠这些看起来无比简单理念引导实确是如此,这有点像我们所说的”大道至简”,复杂的东西简单做,也是我们解决问题的最重要的一步.

关于Unix/Linux中的编程哲学,我想以上十三条已经足够.其中最有启发的应属”小既是美”,这也是我决定以后不写长文的原因.

文章知识点与官方知识档案匹配，可进一步学习相关知识CS入门技能树Linux入门初识Linux24758 人正在系统学习中