梦断代码(Dreaming in Code)

20世纪90年代科技行业的兴盛,给我们带来了”互联网时间”的概念。该短语含义的理解见仁见智,但多指”快速”之意。数字时代的新时间机制下,一切皆有可能发生,技术生产,公司创立,创造财富,而且速度惊人。这意味着你没有时间做到尽善尽美,无须担心因为别人也一样


和摩天大楼,水坝等等永久性建筑一样,桥梁体现了人类对于物理世界的技术的把握。在过去半个世纪里面,软件成为构建这个世界的虽不可见却深入渗透的人造物。“人类文明运行于软件之上”,广为应用的计算机语言C++发明人说。这里我觉得软件似乎更加反映人类的逻辑,人类所有的软件都是人类的逻辑的结晶。人类的逻辑没有办法考虑周全,所以软件也永远没有完美,也不可能完美:-(


让托伊害怕的并非44号缺陷本身,而是无法确定需要多长时间才能修正缺陷。依此类推,历数chandler中类似的不可知因素,加起来就变成了开发经理的噩梦。日程中的黑洞充满了不确定甚至是不可知的因素的时间陷阱


在2002年10月chandler首次官方声明之后的9个月里面,他们经历了布鲁克斯在人月神话描画的种种困境。尽管他们采用了诸如邮件列表,blog,缺陷追踪,原代码控制等工具,但和他人保持一致仍然极其困难。每次延误,总让人想要雇用更多人力,但是新增的人力似乎根本无法助于推动进度. 在大型团队中,保持一致性是最难办的事情,组织是关键


在第一篇帖子上,他反思了为什么Chandler的进度如此慢如龟行。麦克比较了他在OSAF和Netscape的工作经历,把部分原因归咎于OSAF更为民主化,缺少等级式结构–无论是在大教堂还是集市都认为,等级式结构是将顽固的程序员组织起来的有效手段。这里也说了组织的办法就是永远不要将结构平坦化,因为那样不利于组织:-)


linus说“在科学领域里面,人们互相察看引用各自的成果,整个系统建立与这个基础上面。而在魔法界则有人暗藏秘技,也不会让别人真正理解乃至使用。传统软件就像是魔法。历史上魔法最终消亡了。历史将在软件开发中重演。当问题趋于严重的时候,就不能够允许个人或者是个别公司抱有秘密。应当让所有人分享知识


那么多激情洋溢的鼓吹者为我们描绘出数字化进步的美妙图景,可他们对程序员努力把脆弱代码锻造成型的痛苦记录却只字不提。那记录有一个接一个的灾难组成,在计算机领域的历史时间线上,留下累累弹坑. 今天任何打算开创一个大型软件开发醒目的人都得与这种嫉妒令人气馁的历史包袱相抗争。他让胸怀大志的新来者遭受重创,好像在对他们说,你凭什么认为自己与他们与众不同?然而,在各种软件项目中,不论大小,不论公司,不论新旧,都可以看到类似的悲惨故事。撇开具体细节不谈,模式令人郁闷的一致:标靶移来移去,目的忽上忽下。计划不切实际,期限一拖再拖。预算膨胀超支。绝望至极,混乱不堪:-(. 回到IT产业喜用的关于作软件和建桥梁之间的类比,1995年那份报告认为,软件的问题不只于中途纠正和后期设计更改有关,这些情况都是桥梁建筑师所不能够人受的;他还存在无法从失败中吸取教训的问题“如果桥塌了,就要做调查,写报告说明失败的原因。而在计算机产业中,失败案例总是被掩盖,被忽视而且被认为是合理的。结果,我们不断重复同样的错误”我们总是告诉自己我们和他们不一样,不再会犯这个错误,但是….


选项太多,往往导致软件项目在选择编程语言是随性所谓-根据个人品味,习惯或者是心血来潮


这些例程代码库通常都是孤岛一群。标准化工作往往是略过这个领域,软件业界有太多势不两立的标准了,举目之处,四顾皆是。计算机系统中每一点差异-你用什么中央处理芯片?什么操作系统的那个版本?什么编程语言?什么数据格式?如此等等-都能够惊醒乐高之梦。如多部软件工程著作的作者罗伯特格拉斯所言,程序员们很早以前就解决了小复用问题,通过构建自程序库来为自己减负。但是一直悬而未决的是大复用问题-创造并且使用真正有用的软件可服复用组件。”无关乎志向,亦无关乎技能。只是因为难题源自软件的多样性,根深蒂固并且难以解决


大多数程序员喜欢写程序,甚至胜过沐浴和饮食。他们中的大多数宁肯写代码,也不愿意详细察看文档或者是目录,或者是去找其他笨蛋程序员写的蠢代码。在同等条件下,程序员会选择从头设计构建,而不是重复利用。有时候软件开发者深受”此处尚未创造”综合症的折磨,偏信于自己的技术和所在的研究机构的力量,以至于不相信他人创造的东西。有时他们不肯花时间研究其他人的工作,甚至不肯瞥一眼别人的东西是否符合自己的需求。对于典型的程序员,即使要花2分27秒去找一样的东西,他们就会认为这个东西不存在,就会去重新创造它:-)


除非是自己写的代码,否则很难确定一段代码是否真的有用


如果说以代码行数计算不太可靠,那么衡量软件生产力的其他通用的方法也同样不可靠。你可以更新程序特性或者是功能点,但是他们很难被整齐划分成为难度或者是尺寸相似的单元,只能以对每一个特性完成时间主观预测告终。


温格伯指出,要点是”非正式机制总是存在,而且如果没真正理解就改变它是很危险的,要避免扰乱原本运行顺畅而且你无法以同等代价替换的系统”。与此同时,程序员已经发明了自己的非正式沟通机制,他们发明了一系列技术好让彼此保持联系,他们通过各种新的团队协同工具拓展了软件领域


在软件管理中,协作不是马后炮,也不是无足轻重的事情:它是工作的核心,决定采用何种工具和方法有可能成就或者是毁掉项目,但是同时管理这些工具容易诱使项目偏离正轨:-(


通常由程序员负责猜测程序该如何应对用户输入和机器状态上千种可能的组合,但是他们却不擅于站在用户的立场考虑问题,想出合理之策。他们花费大量时间纠缠于数字化细节,他们被调教得按照自己做出的系统一般运作。他们视之为理所当然的概念,对于非程序员而言纯然是怪异之举。他们多半不了解用户的想法(程序员常依赖一种称为妈妈测试的手段,以对计算机一无所知的父母家乡用例,有时候甚至请这类用户亲自体验)


有时候在想为什么OSAF会发布这个Chandler 0.2版本,甚至组内的成员都没有完全的信心去让用户去实验这个版本。但是事实上这个是对的,时间驱动开发的Chandler很明显需要给出一个时间底线来让自己彻底反省和进行设计。当Chandler 0.2版本发布之后,就可以看到每个人都觉得Chandler走错了方向,迫使组内成员进行自我的反省。OK,即使一个项目没有完全写好,但是给出一个deadline并且严格执行它,这样如果在deadline没有发出一个良好版本的话,那么全组成员都会感觉荣誉的丢失并且自我审视一次,迫使在接下来的时间内做得更好:-)


半格点是比树更松散的结构,仍有层次结构,但是允许子集进行重叠。为什么建筑设计和规划社区总是“树状结构”呢?亚历山大认为半格点更为复杂和难以描述,而且我们不可避免地倾向于用更易于把握的树状结构。但是这种“每个思维简单的人都患有将同名物体放在同一个篮子的狂躁症”却在城市设计中导致了人为的约束和隔离。“采用树状结构就是以人性和鲜活城市的丰富性为代价,去换取概念上的简明性,这只是便于设计师规划师,行政官和建设者。每当城市被撕开一块,用树 状结构代替了原来的半结点城市就向着分裂又迈进了一步”。这是包括建筑师以及每一个软件工程师所需要注意的问题,我们以简明的概念换取软件的简单性没有错,但是我们需要考虑到用户使用的感受:-(。


匈牙利命名法写出的一个句子:-) prepBut nI vrbLike adjHungarian!qWhat’s artThe adjBig nProblem?


作为设计师,我们都需要更多用于来展示自己设计了了不起的东西。初次成功的人特别是年轻时就取得成功究竟是靠运还是靠本事?两者都有一点。如果你能够做到另外一件了不起的事情,那么就能够让世界看到你的实力:-)


Mozilla开发者么决定全部重写浏览器”布局引擎”,在屏幕上画出网页的代码。这一决定的结果是让项目花了好多年时间,外界对此颇有微词。但是那是一个关键性的决定,即便是一个错误的决定。然后设计出可运转的工程进展计划。


如何在项目漫长生命周期的起起落落中鼓舞程序员和他们的经历是一门神秘的艺术


要留心,如果当前计划涉及一年之后,又可能这个项目会失败


方法论的真正目的是卖书而不是解决问题。方法论的关键问题在于,那类发明方法论的聪明人实施方法论时就会有用,但是如果让那些只是知道听令行事的笨蛋来实施,即不管用了


约束是朋友,是打造伟大产品的关键。约束产生创意,如果有人说给你全世界的财富,让你任何想做的东西,那么这个东西多半永远发布不了。给我一个月的时间就好:-)


罗森伯格法则:软件好做如果你只是想完成旧任务。一旦完成新的任务软件就不好做。由于软件不好做,所以只有完成新任务的软件才是值得去做的:-)


抽象并未真的想人们打算的那样简化我们的生活,漏洞抽象法则意味着,无论何时有人拿出一套本能够提升我们效率的所见即所得代码生成工具,你总会听到许多人说”先学会学怎么手工操作,再用所见即所得工具节省时间”。所有抽象节省了工作的时间,却没有节省学习的时间。总而言之,尽管我们拥有了越来越高级的编程工具和抽象,但要成为编程高手越来越难


软件领域感觉特别像《土拨鼠日》,想法总是雷同没完没了。因为我们相信只有想象中的计算框架是可行之路。虽然硬件一直在加速,但是软件却毫无改进,这是计算机科学的奇耻大辱。但是程序员们却自满起来,接受了不能够令人满意的现状还视其为恒久不变之事


软件的大问题在于,程序员起步于小程序,并且在小程序上学习原则和实践经验。但是当程序膨胀到今天的项目一般体量的时候,他们发现所有的经验都没有用了


我们对象成为作家和诗人的学生的要求,比对那些想成为软件开发者的人要求多:他们跟随导师,他们得在讨论班上展示自己的作品并且接受他人的批评,他们反复推敲,不断精炼。我想我们应该感到羞愧,我们拿得出手的所谓计算机教育简直就是一出闹剧


艺术是由人类智慧所作之物,相对于源自天然或者本能的行为而言。假设要在人造物和自然物之间划分界限,那么任何与计算机相关之事都会毫无疑问地落在艺术这边


2004年,windows2000的某个版本的部分原代码泄漏到了互联网上。兴奋的程序员们精读了全部文本。他们惊奇地发现,微软程序员们在代码中骂自己,骂工具,骂同事,骂产品的:-)


要在大型项目中保持高效,你得效忠于他。你要将它印在脑海中,我在做大型项目的时候常常睡觉也梦到代码


如果设计师知道编程的话,那么就会固步自封。一旦知道怎么编程,那么你就会想做那样的东西太难了


SWAG(silly wild-ass guess)盲估就是估计任务的耗时,就是要求开发者在Bugzilla填写任务完成的预计时间,不过不同的是要求任务更细。一旦任务更细粒度更小估计时间就越容易了


Richard Stallam喜欢说”如果有人问我这个事情什么时候结束,我总是回答只要你来帮忙,就会完成得快一些”


老程序很少拥有新潮的图形界面或者是风行一时的特性。但是它有一种不可低估的优势,以工作为取向。适当使用的程序就像是精心打理得旧花园,或者是轻柔弹奏的老吉他,其粗糙边缘已经锉去,缺陷已被发现和修正,人皆知其表现物有所值


软件本质困难,乃是强加于技术进步的人类自由意志和不确定性的通行费


由于重复周期和无限期的延误,变成工作总是让人想到薛西弗斯的劳役没完没了地推石头上山,典型的无用功。我在研究过程中访问和认识的多数程序员始终如一,而且有时毫无由来地对工作持有乐观态度。如果他们是薛西弗斯的话,也会是快乐的薛西弗斯

comments powered by Disqus