关闭

关闭

关闭

封号提示

内容

首页 _(大道至简).pdf

_(大道至简).pdf

_(大道至简).pdf

上传者: zhouqing1377 2012-12-16 评分 0 0 0 0 0 0 暂无简介 简介 举报

简介:本文档为《_(大道至简)pdf》,可适用于贸易领域,主题内容包含大道至简软件工程实践者的思想周爱民(Aimingoo)著序年月初爱民(Aimingoo)第一次把他的书稿给我我翻看了一下第一反应讲的是感想。这不错在符等。

大道至简软件工程实践者的思想周爱民(Aimingoo)著序年月初爱民(Aimingoo)第一次把他的书稿给我我翻看了一下第一反应讲的是感想。这不错在技术界就是需要有真正实践经验的专家把他的思考和心得与我们分享。Aimingoo在Delphi领域颇有名气其技术钻研的深度直达系统核心层从其著作《Delphi源代码分析》可见一斑。不过接下来第二反应就是太薄了能不能加厚啊。比如说这些感悟都是有其来源的可以把实际案例啊背景故事啊都加上。不然太薄了出版社没有办法出版啊。国家对于出版的书号是有严格控制的所以书号是有成本的。一本讲技术高端的图书销量肯定是有限的以现实情况而言如果很薄定价就只能比较低成本无法回收。而且内容只是心得没有案例读起来也很硬对读者的要求也很高销量可能就更少了。爱民听完我的意见还是坚持这本书就是这样的风格。出厚书违背了他的本意要不然怎么叫“大道至简”。书稿在年月杀青后我从月开始在《程序员》上陆续选择其中的三章发表看看读者的反馈。不过限于篇幅删掉了一些内容不能完整体现出作者系统思考的脉络也比较遗憾。年月爱民跟我讨论到即使没有出版社愿意出版印刷也要把他的作品用电子版问世并邀我作序。我十分感慨在这个浮躁功利的社会难得还有这样的朋友。现在我又仔细从头到尾读了一遍。很多作者写书是为厚而厚大部分内容都是水分作者原创经验精华只有很少甚至没有。而这本书是作者从事十年开发工作的总结虽然不厚却闪烁着独立思考的光芒。世界“虽变化万端而理为一贯。”作者在软件开发一线浸淫近十年回头思考何为开发的本源?这些理论、方法的本质为何?粗粗一看这些道理稀松平常专家教授无数著作早就谈过还用作者来写吗?其实不然理论都是从实践而来但我们学习软件开发的时候是先掌握这些专家总结的果实而不是探求本源所谓“知其然而不知其所以然”。这些道理看似都知道但却没有真正体会上身在实践中最重要的去应用这些道理而不是方法。大多数人看书都希望学到一些招数、方法能尽快在工作中用上这是不错。但要想真正达到更高境界就必须明白背后的道理。真正的专家是从根上解决问题的所以大物理学家杨振宁在北京大学针对本科生讲物理学讲得深入浅出大受欢迎就是因为杨先生可以从历史本源来剖析物理定律公式。只有招数不明道理碰到变化的情况就束手无策了。而在软件开发中每个团队、每个项目都不是尽然相同的。明白道理才能知变通之道。这本小书不是一本教你项目管理软件工程或者编程技巧的书籍他是一本闪烁思考光芒的技术散文集我衷心祝愿这本书的读者能把这本书当作一位朋友的思考一位朋友的总结来参照自身这样就会有收获有想法了。我也和爱民建议这本书的很多主题还可以展开无论是批评还是讨论只要有兴趣的朋友可以给爱民我或者《程序员》杂志社写信我们诚恳邀请各位来共同思考共同把实践经验与大家分享这样意义也就更大了。期望大家的参与谢谢。蒋涛.月jiangtaocsdnnet注:关于书的序的讨论参见附录之一。电子版发布前言我终于决定发布这本书的电子版了。完成这本书的时候我已经在这个行业里做了十年了。这十年来我对自己的经历做过两次回顾。第一次是关于技术的这造就了那本《Delphi源代码分析》是讨论开发的技术和方法细节的。第二次就催生了这本《大道至简》讨论的则是工程、管理中的思想。我其实是很希望这本书能放在读者的书架案头而不是放在电脑的某一个目录中。因为它应当是一本可以阅读和品味的书而不是在电脑中备查的技术资料。然而我在决定担任这家公司的软件架构师的同时我就意识到我没有足够的精力来运作这本书。我的意思是如果要把他做成纸质的书的话我没有足够的精力。出版商是要寻求利润的。于此我一早就知道。但我从来不知道:到底一本书簿一点或者厚一点哪个会让出版商更有利润。我只想写一本“阐明软件工程的思想核心”的书。这本书要很容易就读明白还要很容易就想通还要很容易就知道:工程其实很简单只是大家把它做复杂了。然而问题是:我把它写得太简单了以至于只写了页就没有必要再写下去了。我当然可以把一本书写得很复杂或者很厚。这很容易就如做Coder一样:把代码写烂或者写乱都很容易要想写得简洁却远非易事。代码写得太简洁老板会认为你在偷懒书写得太薄出版社就不愿意出。我看来是忘掉了侯捷先生说过的“买书如买纸”以书的厚薄来论价值的故事。忘掉了就忘掉吧。好的一面是现在书变成了电子版大家终于可以读到它了。不好的呢?我想大概不要钱的东西很难得到珍视吧:如果下载这本书只是因为收集而不是阅读那会是让我感到比讨论“买书如买纸”这样的事更为难过的。好吧。希望你能象对待纸质书籍那样来阅读这本《大道至简》。放心我并不介意你把它打印出来放在床头。补充声明:我保留在传统媒体(书籍、杂志)上刊载、出版本书的权利。但允许任何人在网络上非商业性地、自由地、不加修改地传播这本书的电子版本。周爱民年月日http:wwwdoanynetmailto:aimnet目录编程的精义编程的精义会或者不会写程序程序=算法结构语言在没有工程的时代是懒人造就了方法是懒人造就了方法一百万行代码是可以写在一个文件里的你桌上的书是乱的吗我的第一次思考:程序=算法结构方法团队缺乏的不只是管理三个人的团队做项目=死亡游戏做ISO质量体系的教训谁动摇了你的制度?“那我们就开始开发吧”组织的学问:角色跟随蚂蚁。但不要栽进蚂蚁洞里。“什么是增值税发票?”流于形式的沟通客户不会用C难道就会用UML吗?项目文档真的可以用甲骨文来写最简沟通为不存在的角色留下沟通的渠道流于形式的沟通失败的过程也是过程做过程不是做工程做过场实现才是目的过程不是死模型“刻鹄类鹜”与“画虎类狗”工程不是做的是组织的从编程到工程语言只是工具程序方法过程工程组织BOSS上帝之手现实中的软件工程大公司手中的算盘回到工程的关键点思考项目成本的经理审视AOP审视MDA是思考还是思想软件工程三个要素的价值其实RUP是一个杂物箱UML与甲骨文之间的异同经营者离开发者很远反之亦然矛盾:实现目标与保障质量枝节与细节灵活的软件工程第章编程的精义“虽我之死有子存焉子又生孙孙又生子子又有子子又有孙。子子孙孙无穷匮也。而山不加增何苦而不平?”《愚公移山》《列子汤问篇》编程的精义仅仅就编程序来说实在是一件很简单的事甚至可以说是一件劳力活。两千年前的寓言中已经成就了一位工程名家:愚公。在这位名家的身上浓缩了项目组织者、团队经理、编程人员、技术分析师等众多角色的优秀素质。他的出现远远早于计算机发展的历史甚至早于一些西方国家的文明史。汤问篇中所述的愚公移山这一事件我们看到了原始需求的产生:“惩山北之塞出入之迂”我们也看到了项目沟通的基本方式:“聚室而谋曰”然后我们看到愚公确定了一个项目的目标:第章编程的精义“毕力平险指通豫南达于汉阴”并通过研讨择定了一个井然有序的、可以实现的技术方案:“扣石垦壤箕畚运于渤海之尾”在这个项目中动用了三名技术人员和一名工程管理人员:“(愚公)率子孙荷担者三夫”并获得了一名力量较弱但满富工作激情的外协:“邻人京城氏之孀妻有遗男始龀跳往助之”基本上这已经描述了“愚公移山”整个工程的概况。接下来我们应该注意到愚公作为编程人员的基本素质。在与“河曲智叟”的对答中他叙述了整个工程的实现程序:“虽我之死有子存焉”这里描述了可能存在的分支结构即“IF”条件判断。“子又生孙孙又生子子子孙孙无穷匮也”这里描述了完成这个工程所必须的循环结构。作为优秀的程序分析师愚公论述了这个循环的可行性:由于“山不加增”所以条件“山平”必将成立(“何苦而不平”)所以这不会是一个死循环。在愚公的论述中我们看到了编程的根本:顺序、分支和循环。庞大若“愚公移山”这样的工程都是可以通过这样简单的编程来实现的。这就是编程的精义了。『大道至简』会或者不会写程序的问题我经常会被人问到“(我)能不能学会写程序”这样的问题。这个问题由来以久。上溯七、八年程序员还是少有人从事的职业。听说的人少真正了解的人也不多。而当一个程序软件被装在电脑里并开始运行时人们便开始惊讶于程序员的厉害。所以“能不能学会写程序”甚至成了一些人对自己的智力考评所以便有人向我这样发问。愚公都能明白的编程精义那些向我发问的智叟们又怎么会不明白呢?第章编程的精义所以除了先天智障或后天懒惰者都是可以学会写程序的。如果你能确信自己知道在早上起床后需要:)如果天冷则先穿衣服后洗漱)如果天热则可反之)日复一日直到死亡那么你就可以开始编程了。甚至如果你认为以下条件成立:)如果有类似于生病、不能行动、以及意外的紧急事件则当日可以略过那么你就可以开始向设计师发展。因为你已经具备了一项常人不具备的基本素质:折衷。程序=算法结构编程作为一种行为只需要知道其逻辑方法就可以了。所谓编程实际上是把一件事情交给计算机去做你认为这件事该如何做就用“程序语言”的形式描述给计算机。如果你原本就不明白如何去做那么你也不要期望计算机去理解你想要做什么。所以编程的第一要务是先把事情分析清楚事件先后的逻辑关系和依赖关系搞清楚然后再去代码实现。一接到任务就开始Coding的程序员通常就是加班最多的程序员。记住:积极工作和勤于思考都要占时间。第一个完成关于编程本质的思考的人提出了一个公『大道至简』式“程序=算法结构”。这个公式的精彩之处在于它没有任何的地方提及到Code。甚至可以说在这个公式里代码是不存在的。存在的只是思想。算法是对一个程序的逻辑实现的描述而结构是逻辑实现所依附的数据实体。只要开发人员将这个程序的算法设计出来了把结构描述出来了那么程序就已经定型了。剩下的事简而言之就是劳力活。在计算机专业所学的课程中同时讲述算法和结构的是“数据结构”。现在你放下手边这本书再去读读被你扔到不知哪个角落的《数据结构》你仔细看看在所有的算法描述中有且仅有三种执行逻辑:顺序、分支和循环。简单若顺序表复杂如树、图它们的算法都是用上面这三种执行逻辑来描述的。第章编程的精义语言当你熟悉了一门语言之后你会发现编程语言只有喜欢与不喜欢的问题没有会不会的问题。任何的一门语言你都可以在两周内掌握并开始熟练编程。因为任何的一门语言他们的底层函数库都是那么的相似而他们API都是那样的依赖于操作系统。A语言里有的B语言里也基本都有。通常而言语言的差别主要表现在适用范围上。一些语言适合做数值处理小数点后可以精确到原子级而小数点前则可以表达到宇宙之无穷另一些语言则适合做图形处理它的底层函数库比其它语言可以快上十倍或数十倍还有一些语言则适合于做网页要用它来做一个通讯薄软件都将是史无前人的挑战。成天讨论这门语言好或者那门语言坏的人甚至是可悲的。不但是悲其一叶障目更要悲叹于那种大愚若智的自得心态。在没有工程的时代在没有工程的时代上面所说的就是一个程序员的全部。他们掌握了一门语言懂得了一些生活中最常见的逻辑他们用程序的方式思考和学习了一些算法并根据前人的经验把这些算法跑在了一些数据结构之上最后『大道至简』我们就看到了他们写的程序。在没有工程的时代出现了非常非常多的人物。其中算法大师有游戏大师有语言大师有挣钱的大师唯独没有工程大师。嗯可以理解嘛那是没有工程的时代。好蛮荒好远古的。第章是懒人造就了方法“僰蘭道有蜀王兵亦有神作大滩江中。其崖崭峻不可破(冰)乃积薪烧之。”《华阳国志》是懒人造就了方法战国时期的李冰凿了一座山。史记中说是“蜀守冰凿离堆”是说李冰在成都的时候凿出了离堆。一说是李冰将都江堰附近的玉垒山凿了一个大口子叫宝瓶口而凿的石头就堆成了离堆。另一说则是李的确是凿了一座“(溷)崖”但是是在沫水亦即是今天的大渡河。在哪里凿的山是史学家都说不清楚的事。但的确凿了一座山而且方法是“(因)其崖崭峻不可破(冰)乃积薪烧之”。我们已经看到事物的进化了。同是战国时代《列子汤问篇》里的愚公就要“碎石击壤”而李冰就已经懂得“积薪烧之”了。会有人说愚公是“碎石”并没有说他“碎石”的方法究竟是“斧钺以凿之”还是“积薪以烧之”。但想想那个时代如果有人懂得了烧石头这个方法哪能不立即载『大道至简』文志之永世传承。再说了愚公嘛。愚者怎么会呢?这还需要分析吗?需要吗?所以愚公会凿而李冰会烧。那李冰又是为什么会用“烧”这种方法来碎石的呢?如果李冰也象愚公那样日复一日地督促着他的团队凿石开山那他一定没有时间来学习、寻找或者观察当然也不会发现“烧”这种方法可以加快工程进度使得一大座山短时间就被哗啦哗啦地给“碎”掉了。要知道李冰的团队可是成百上千人要修堰筑坝还要“凿离堆”当然还要吃喝啦撒睡。所以李冰如果忙起来的话他必然是“受命以来夙夜忧叹”必然食难下咽睡无安枕。反之李冰一定是个闲人可以闲到没事去看火能不能把石头烧爆。这么大个工程里如果有一个人会闲到看火烧石头那他一定很懒。那么多事堆着不去做去看烧石头你说他不是懒是什么。正是一个懒人造就了“烧石头”这个“碎石”的方法。愚公太勤快了勤快得今天可以比昨天多凿一倍的石头。或者在愚公的项目计划案的首页里就写着朱笔大字:“吾今胜昨倍许明胜今倍许而山不加增何苦而不快。”但是越发的勤快愚公将越发没有机会找到更快的方法人的精力终归是有极限的。提出新的“方法”解决第章是懒人造就了方法的将是影响做事成效的根本问题。而愚公可以多吃点饭多加点班但突破不了人的精力的极限。记住在两千年前的某一天闲极无聊的李冰下厨给夫人炒了一个小菜他突然发现垒灶的鹅卵石被烧得爆裂开来遇水尤甚。从此《史记》上记下了“蜀守冰凿离堆”而《华阳国志》上记下了他做这件事的方法“积薪烧之”。在差不多同一时间愚公在山北之塞“碎石击壤”。一百万行代码是可以写在一个文件里的早期写程序都是将代码打在穿孔纸带上让计算机去读的。要让计算机读的纸带当然是连续的这无需多讲。其实我也没有那样写过程序真实的苦楚我也不知道。『大道至简』后来有了汇编语言可以写一些代码了。这时的代码是写在文本文件里然后交给一个编译器去编译再由一个链接器去链接这样就出来了程序。第一个写汇编的人可能写的是有名的“HelloWorld”程序那个程序写在一个文件里就行了。所以后来就成了习惯大家都把代码写到一个文件里。早期的汇编语言里GOTO语句是用得非常非常频繁的将一个语句GOTO到另一个文本文件里去既不现实也不方便。所以大家习以为常便统统地把代码写到一个文件里。再后来出了高级语言什么C呀Pascal呀之类的。既然大家已经形成习惯了所以很自然地会把一个程序写到一个文件里。无论这个程序有多大多少行代码写到一个文件里多方便呀。直到如今语言发展得更高级了。可是程序员的习惯还是难改一旦得了机会还是喜欢把代码写到一个文件里的。好了有人说我是想当然尔。En这当然是有实据的。记得Delphi版发布的时候全世界一片叫好声。连“不支持双字节”这样的大问题都不影响他在华语地区的推广。然而不久爆出了一个大BUG!什么大BUG呢?Delphi的编译器居然不支持超过K的源代码文件!这被Fans们一通好骂。直到我用Delphi时一个从VB阵营转过来的程序员还跑过来问我这件事。好在Delphi改了这个BUG这让当时我的面子上好一阵风第章是懒人造就了方法光。k的文件是什么概念呢?行代码大概(平均)是字节k的源代码是行如果代码风格好一点再多一些空行的话差不多也就是行上下。也就是说在Delphi的时代(以及其后的很多很多时代)程序员把行代码写到一个文件里是司空见惯的事了。如果你不让他这样写还是会被痛骂的呢。所以呢按照这一部分人的逻辑一百万行代码其实是可以写在一个文件里的。不单可以而且编译器、编辑器等等也都必须要支持。这才是正统的软件开发。勤快的愚公创造不了方法。这我已经说过了。对于要把“一百万行代码写到一个文件”查找一个函数要在编辑器里按五千次PageDownPageUp键的勤快人来说是不能指望他们创造出“单元文件(Unit)”这样的开发方法来的。然而单元文件毕竟还是出现了。这个世界上有勤快人就必然有懒人有懒人也就必然有懒人的懒方法。有了单元文件也就很快出现了一个新的概念:模块。把一个大模块分成小模块再把小模块分成更细的小小模块一个模块对应于一个单元。于是我们可以开始分工作『大道至简』了一部分人写这几个单元的代码另一部分则写那几个。很好终于可以让源代码分散开来。结构化编程的时代终于开始了新的方法取代了旧的方法而这一切的功劳是要归终于那个在按第次PageDown键时突然崩溃的程序师。他发自良心地说:不能让这一切继续下去了我一定要把下一行代码写到第二个文件里去。我发誓我要在编译器里加入一个Unit关键字。你桌上的书是乱的吗?几周之前在一所电脑培训学校与学生座谈时一个学员问我:“为什么我学了一年的编程却还是不知道怎么写程序呢”。我想了想问了这个学员一个问题:“你桌上的书是乱的吗?”他迟疑了一下不过还是回答我道:“比较整齐。”我当时便反问他:“你既然知道如何把书分类、归整得整整齐齐地放在书桌那怎么没想过如何把所学的知道分类一下归纳一下整整齐齐地放在脑子里呢?”如果一个人学了一年的编程他的脑袋里还是昏乎乎的不知道从哪里开始也不知道如何做程序。那想来只TurboPascal中才开始有了Uses和Unit关键字。在ANSIPascal标准里并没有它。第章是懒人造就了方法有一个原因:他学了也把知识学进去了就是不知道这些知识是干什么的。或者说他不知道各种知识都可以用来做什么。其实结构化编程的基本单位是“过程(Procedure)”而不是上一小节说到的“单元(Unit)”。然而在我看来过程及其调用是CPU指令集所提供的执行逻辑而不是普通的开发人员在编程实践中所总结和创生的“方法”。这里要提及到CPU指令集的产生。产生最初的指令集的方式我已经不可考证我所知道的是CISC指令集与RISC指令集之争在年终于爆发。前者被称为复杂指令集然而经过Patterson等科学家的研究发现的CISC指令只有在的时间内才会用到更进一步的研究发现在最常用的条指令中包含的流程控制只有“条件分支(IFTHEN)”、“跳转(JUMP)”和“调用返回(CALLRET)”于是CISC被RISC(精简指令集计算机)替代了。动摇CISC指令集地位的方法就是分类统计。正如CISC指令集搅乱了一代程序设计师的思路一样大量的知识和资讯搅乱了上面给我提问的那位学员的思想。他应该尝试一下分类把既有的知识象桌子上的书一样整理一下最常用的放在手边而最不常用的放在书在x系统中循环是用条件分支来实现的而且条件分支指令并不是IFTHEN这里用这两个关键字仅用于说明问题。『大道至简』柜里。如果这样的话我想他已经在九个月前就开始写第一个软件产品了。你桌上的书还是乱的吗?我的第一次思考:程序=算法结构方法我的第一次关于程序的本质的思考其实发生在不久前。那是我在OICQ上与Soul的一次谈话。Soul(王昊)是DelphiBBS现任的总版主是我很敬重的一位程序员。那时我们正在做DelphiBBS的一个“B计划II”也就是出第二本书。他当时在写一篇有关“面向对象(OOP)”的文章。而我正在写《Delphi源代码分析》在初期的版本里有“面向对象”这一部分的内容。我们的对话摘要如下:Soul:我在写书讨论“面向对象的局限性”我:En这个倒与我的意见一致。哈哈哈。我:“绝对可以用面向过程的方法来实现任意复杂的系统。要知道航天飞机也是在面向过程的时代上的天。但是为了使一切变得不是那么复杂还是出现了‘面向对象程序设计’的方法。”我:哈我那本书里在“面向对象”一部分前的引文中。就是这样写的。这段对话的确很长。如果你不是非常有经验的程序员那么不能完整地阅读和理解这段文字是很正常的。部分读者甚至可以跳过这段引文直接阅读后面的结论。而有兴趣的读者可以在我的网站上读到它的全文(http:wwwdoanynet)。第章是懒人造就了方法Soul:现在的程序是按照冯。诺伊曼的第一种方案做的本来就是顺序的而不是同步的。CPU怎么说都是一条指令一条指令执行的。我:面向过程是对“流程”、“结构”和“编程方法”的高度概括。而面向对象本身只解决了“结构”和“编程方法”的问题而并没有对“流程”加以改造。Soul:确实如此。确实如此。我:对流程进一步概括的是“事件驱动”程序模型。而这个模型不是OO提出的而是Windows的消息系统内置的。所以现在很多人迷惑于“对象”和“事件”试图通过OO来解决一切的想法原本就是很可笑的。Soul:我先停下来和你讨论这个问题顺便补充到书里去。我:如果要了解事件驱动的本质就应该追溯到Windows内核。这样就涉及到线程、进程和窗体消息系统这些与OO无关的内容。所以整个RAD的编程模型是OO与OS一起构建的。现在很多的开发人员只知其OO的外表而看不到OS的内核所以也就总是难以提高。Soul:OO里面我觉得事件的概念是很牵强的因为真正的对象之间是相互作用,就好像作用力和反作用力,不会有个“顺序”的延时。我:应该留意到整个的“事件”模型都是以“记录”和“消息”的方式来传递的。也就是说事件模型停留在“面向过程”编程时代使用的“数据结构”的层面上。因此也就不难明白使用/不使用OO都能写Windows程序。我:因为流程还是在“面向过程”时代。Soul:所以所谓的面向对象的事件还是“顺序”的。所以我们经常要考虑一个事件发生后对其他过程的影响所以面向对象现在而言是牵强的。我:如果你深入OS来看SEH来看Messages就知道这些东西原本就不是为了“面向对象”而准备的。面向对象封装了这些却无法改造它们的流程和内核。因为OO的抽象层面并不是这个。我:事件的连续性并不是某种编程方法或者程序逻辑结构所决定的。正如你前面所说的那是CPU决定的事。Soul:比如条件选择其实也可以用一种对象来实现而事实没有。这个是因为cpu的特性和面向对象太麻烦。我:可能将CPU做成面向对象的可能还是比较难于想象和理解。所以MS才启动NETFramework。我不认为NET在面向对象方法上有什么『大道至简』超越也不认为它的FCL库会有什么奇特的地方。除了它们足够庞大。但是我认为如果有一天OS也是用NETFramework来编写的OS一级的消息系统、异常机制、线程机制等等都是NET的都是面向对象的。那么在这个基础上将“事件驱动”并入OO层面的模型才有可能。Soul:所以我发觉面向对象的思维第一不可能彻底第二只能用在总体分析层上。在很多时候实质上我们只是把一个顺序的流程折叠成对象。我:倒也不是不可能彻底。有绝对OO的模型这样的模型我见过。哈哈~~但说实在的我觉得小应用用“绝对OO”的方式来编写有失“应用”的本意。我们做东西只是要“用”而不是研究它用的是什么模型。所以“HelloWorld”也用OO方式实现原本就只是出现在教科书中的Sample罢了。哈哈。Soul:还有不可能用彻底的面向对象方法来表达世界。因为这个世界不是面向对象的。是关系网络图面向对象只是树只能片面的表达世界。所以很多时候面向对象去解决问题会非常痛苦。所以编程退到数据结构更合理哈哈。我:如果内存是“层状存取”的那么我们的“数据结构”就可以基于多层来形成“多层数据结构”体系。如果内存是“树状存取”的那么我们当然可以用“树”的方式来存取。可惜我们只有顺序存取的内存。我:程序=数据+算法这个是面向过程时代的事。程序=数据+算法+方法在OO时代我们看到了事件驱动和模型驱动所以出现了“方法”问题。Soul:我的经验是:总体结构>面向对象关系>数据结构实现>算法Soul:看来我们对面向对象的认识还是比较一致的。我第一次提到我对程序的理解是“程序=数据算法方法”便是在这一次与Soul的交谈之中。在这次的交谈第章是懒人造就了方法中的思考仍有些不成熟的地方例如我完全忽略了在面向过程时代的“方法”问题。实际上面向过程开发也是有相关的“方法”的。所谓“面向过程开发”其实是对“结构化程序设计”在代码阶段的一个习惯性的说法。而我忽略了这个阶段的“方法”的根本原因是即使没有任何“方法”的存在只需要有了“单元(Unit)”和“模块(Module)”的概念在面向过程时代一样可以做出任意大型的程序。在那个时代“方法”问题并不会象鼻子一样凸显在每一个程序员的面前。面向过程开发中“过程(procedure)”是CPU提供的“单元(unit)”则是编译器提供的(机制)。程序员不需要(至少是不必须)再造就什么“方法”就可以进行愚公式的开发工作了。如果不出现面向对象的话这样伟大的工程可能还要再干一百年而与“面向对象”是否出现完全无关的一个东西却因为“过程”和“单元”的出现而出现了。这就是“工程(engineering)”。第章团队缺乏的不只是管理“言人三为众虽难尽继取其功尤高者一人继之於名为众矣。”《汉书高惠高后文功臣表序》颜师古注三个人的团队《汉书》中说“言人三为众”是指三个人就算得上是“众”了。这里的“众”应该理解成一个群体亦或者说是一个团队。团队是至少以三个人为规模的。这有其合理性。为什么呢?首先一个人算不得团队那是个体。两个人则互相支撑古文中“从”字是二人互立就是这个意思。然而二人互立并不算团队因为没有监督。三个人便可以构成团队这样便有了团队的一些基本特性:主从、监督和责任。一个人的开发行为可以成功这取决于个人努力。大家熟知的KV、KV反病毒软件最早就是王江民先生一个人做出来的。二人小组如果能相互支撑那也是片面地理解成“三人为众”是不对的。“三”在这里是虚词指的是很多人的意思。然而古人以“三”来泛指很多人或者群体则是很值得玩味的事。第章团队缺乏的不只是管理可以获得成功的同样作为反病毒软件的AV在到年成功占据反病毒软件市场之一隅就是周辉和刘杰先生两个人的作品。然而到了三个人的时候呢就得选个领导了。颜师古为《汉书高惠高后文功臣表序》作注时引用了孟康的话说“取其功尤高者一人继之於名为众”简意就是功高者代替群体受功。古人的受功当然包括封侯晋爵因此这便仿然成了惯例而推广开来功劳大的、能力强的便成了团队中的领导角色。殊不知彼时彼事目的并非要选领导而是要表彰功绩。项目结束会议上总经理说:“M项目完成得很好小S的进步尤其之大他独立完成了全部核心代码的编写因此月奖加三倍”。奖不可谓不丰然而这并不代表在下一个项目该让小S来做项目经理。同样三板斧定了瓦岗寨的程咬金功不可谓不高技不可谓不强。但程咬金不是将帅之才。做管理起码需要能承担责任这是最基本的素质。《史记循吏列传》记载了李离伏剑的故事。春秋时晋国最高司法长官李离因为“过听杀人”断狱失误把一个不该处死的人错判了死刑。随后“自拘于廷请死于君”晋文公欲以其下属有过为由免他的罪而李离说:“臣居官为长不与吏让位受禄为多不与下分利。今过听杀人傅其罪下吏非所闻也。”随后拔剑自杀了。『大道至简』同样的道理你的项目经理职位又没有让给别人做你拿的经理级工资又没有分给别人那项目失败了你为什么要把责任推到别人头上呢?三人团队中的那个领导不是要程咬金一样的牛人而是要李离一样的死士。项目完成不了切脑袋的事倒不必做递交辞呈的那点勇气总是要有的。做项目=死亡游戏如果项目做不成就要掉脑袋那就象好比是枕着铡刀在做程序如果项目失败就要交辞呈那可能就从来不会有项目经理。为什么这么说呢?第章团队缺乏的不只是管理从管理角度来看项目失败与否与项目经理的经验直接相关。我曾经听过一个来自澳大利亚的讲师说软件工程。她说到项目的成功是两个方面的评估:)项目完成质量)项目完成时间由于项目的时间是在项目前期对项目工期的设定因此我问这个讲师:什么方法能保证预期的工期是正确的或者说是可以完成的。讲师的回答很有意思:经验丰富的工程师能尽可能接『大道至简』近地预估工期但没有办法保障(预估的)工期是绝对合理的。那么进一步的推论是由于没有绝对合理的工期所以项目的完成时间可能总是被进度变更所修正所以项目也就总是不能“成功”。看来外来的和尚(包括尼姑)也未必能比本地的更会念经。在这一点上来自澳大利亚的讲师与来自北极的爱斯基摩人(如果他们也念经的话)如出一辙。项目工期的问题不能解决就不能保证项目成功。只有经验更加丰富才能更尽可能地逼近“合理的工期”。因此在此之前项目经理面临的就是失败。这个失败可能不是项目经理本身能力所决定或者也不是团队成员的工作所决定而是在一开始那份给客户的项目协议就签错了。项目经理是需要时间来成熟的。他需要有机会来承受错误而不是一开始就享受成功。做ISO质量体系的教训Y公司终于在年发现管理跟不上了于是开始软件工程中有专门的学科来研究项目的工期问题。学者们试图寻找公式来计算项目的复杂度从而计算出所需的工时和人月。然而在实践中这被认为是不可行的。第章团队缺乏的不只是管理引进ISO质量认证体系希望通过这个体系来规范管理行为提高产品质量和对外的竞争力。他们做得非常认真把全公司的人员都调动起来了质量手册的论证做到了每一个员工他们按照标准的软件工程模型进行了开发流程的重组每一份流程相关的材料都约定了格式并进行了归档说明每一个环节都设定了质量监督员来考核和回顾接下来他们开始实施。三个月后他们发现了一个问题:所有环节的质量监督员是同一个人他没有工程经验于是他提出的问题总是得不到工程负责人的确认。很显然没有工程负责人愿意说自己这里存在问题:有问题就要改就有可能中断或者重新来过。再则这质量监督员也没有管理权限于是他即使确认了问题也没有权利要求立即整改工程负责人随时可以以进度为由搁置这份监督报告。再两三个月后他们发现一切如旧好象工作并没有因为《质量手册》的存在而发生什么变化在手册上被改造的流程因为人力资源不充分而没有办法运作起来绝大多数应该书写的材料因为时间不够而被“候补”。改变最大的是综合部这里多了一个虚设的机构用于分管ISO质量综合部的经理也变成了分管质量的副总但又没有因此而多拿一分钱。改变最少的是开发部其表现为每个人的显示器顶上放了一本质量手册用来挡住窗口射进来的阳光以及落向显示器的灰尘。『大道至简』两年之后我们一群人来回顾这一次失败时很多人都说是“体制的问题”说是原有的公司转型到新的公司不适合新的公司的管理体制以及对管理的要求。其实这并不十分正确。体制的内涵是分两个方面的其一是“体”即“体系”其二是“制”即“制度”。“ISO质量体系”所产生的那份手册只是“制度”在它的背后所要求的是对旧有“体系”的改变。旧的公司转型到新的公司不是搬来一本“管理制度”给每个员工读一遍就要可以的了。在这一个转型期第一要务是解决“体”的问题也就是“组织机构建设”的问题。如果把这个问题缩小到开发部门的工程环节那么就是“如何组织开发团队”的问题。有了确定的团队模式才能寻求相应的管理制度并且才能把这样的制度实施在团队之上。汉朝的刘向在《新序杂事二》中记录了一个故事说是魏文侯出游见路人把羊皮统子毛向内第章团队缺乏的不只是管理皮朝外地反穿着还背着一篓喂牲口的草。文侯奇怪地问他为什么。这个人答道:我爱惜这件皮衣怕毛被磨掉了。文侯叹道:你难道不知道如果皮被磨尽了毛不也就掉光了吗?皮之不存毛将焉附。没有确定的组织机构又如何能指望做出来的管理制度“合用”呢?Y公司在年至年一直保持着从K公司移植过来的组织机构模式和管理模式两年的组织机构建设的时候被白白浪费了。本来做ISO体系是最后一次弥补组织机构建设的机会然而在管理者还没有意识到“皮之不存”的时候Y公司就连“毛”也都掉光了。谁动摇了你的制度?组织模式确定的同时相应的制度也有随之建立。很少是有几年之后才来补制度的。然而制度究竟决定了什么呢?我们先来看看如果员工在工作中出了纰漏:)没有制度你没有办法和依据来惩戒员工因此是管理者的过失)有了制度而没有惩戒他是执行者和监督者的过失)一而再、再而三地犯错又一而再、再而三地被惩戒那就是教而不改就真正是员工的品性和素质的问题了。『大道至简』因此先做制度总是好的。至少在你选择做伏剑自刎的李离之前你还有机会把黑锅扔到出问题的员工的头上。对于一个已经规范管理、体制健全的公司不容许员工犯错是对的。即使是一次犯错立即开除也说得过去。但还是有前提的这至少包括:)员工已经接受过相关的培训这至少包括员工规范和技术技能的学习)在该员工之前相同的或者相关的错误没有被枉纵第一条是人性化的体现。中国人常说不知者不为过:员工不知道管理者也没有给他知道的条件那怎么能说是他的过错呢?如果因为不知道而出了问题那管理者首先应该自省才是。第二条则是公平性的体现。不管是针对谁制度都是一样的没有情面可讲的常说的“特殊情况特殊处理”在制度面前行不通。规矩一旦被破坏就形同虚设反而被员工作为笑柄用来类比其它的制度。如此一来整个的制度也就离崩溃不远了。反过来在已经被破坏了制度面前若再做杀鸡儆猴状那猴子是被吓着了不平声、怨愤声也就跟着出来了。因此最好的方法是赶紧修订制度而不是修理人。所以经常的情况下动摇了制度的人不是犯错的员工而是管理者自己。如果在制度面前既做得到“人性第章团队缺乏的不只是管理化”又做得到“公平性”那么当管理者的便可以多做几次黑脸的包龙图而脖子上的脑袋便可以比李离顶得长久一些。“那我们就开始开发吧”现在公司的组织机构和制度建设已经完成了在这个组织机构里我们已经有了一个或者多个团队。接下来我们要真正的开始团队建设了。这是任务。因为正在读书的你和我一样是要拉齐七八杆枪开始做工程的了。而在这一切开始之前再之前的时间里我还想知道一件事:你知道如何做工程吗?我们先来回顾一下。前一章说的是编程EN那实在简单愚公式的工作。我们先不管愚公们的水平如何以及够不够勤快反正他们会编程就是了。上一章呢说的是一部分懒人“创造”或“寻找”到一些编程的方法。这些懒人们可能来源于做得太老的、或者太累的愚公或者是一些看着愚公们着急又被闲出毛病了人。反正他们找了一些方法出来而我们的愚公们也已经学会了这些方法。现在有了会(比较快速地)编程的愚公而且有了公司我们完成了组织机构建设我们还找到了一名(或好这里的“完成”是指告一段落或者说是阶段性的结束了。完成并不等于完善。而完美则更是无可企及。『大道至简』多名)项目经理他们一不怕死二不怕苦对了更为可喜的是我们还有了开发部:对内我们订了一套规章制度对外我们还拿到了项目单子。“那我们就开始

用户评论(0)

0/200

精彩专题

上传我的资料

每篇奖励 +2积分

资料评价:

/
2下载券 下载 加入VIP, 送下载券

意见
反馈

立即扫码关注

爱问共享资料微信公众号

返回
顶部