人月神话札记:干将莫邪

前言:A good workman is known by his tools。外国谚语如此,我们也有这样的古话,“工欲善其事,必先利其器”。好的开发团队自然有自己一套比较完好的工具,用来提高生产力以及生产效率。

在学习编程的某一段岁月,我喜欢尝试用各种Java的开发工具,editplus、eclipse、jcreator、myeclipse、netbeans等等,最后,我决定使用eclipse。这一段探索的岁月,也证明了brooks的观点,在工作环境中,如果开发人员的工具不够统一的话,就会制约沟通效率。

我记得在开发交易平台的web管理端时,一个组员使用的myeclipse,而我使用的是eclipse,她不会使用eclipse,这在开发中出现了一些问题。在eclipse下,可以看到WEB-INF目录下的classes文件夹,但是myeclipse不行,必须Windows的资源管理器看到;另外,eclipse中支持@override的标签,而myeclipse中则会报错。

以上两点都对我们之间的工作造成了麻烦。

当然Brooks提供的解决方案是针对比较大型的项目,而小型团队没有这个精力,但是其中一些观点,对于小型团队来说也不谋而合。

目标机器

这个小节有几个特别好的观点:

  • 内存容量要大。机器的内存容量大的话有很多好处,比如说mysql的的配置项中如果合理安排的话,会提升很大性能。
  • 要对内存有一定程度上的监督。很多时候,内存监督能够让我们发现程序的性能bug。
  • 进度安排要更合理。Brooks提供的证据得出,在调度人员对机器的操作间隔中,增长人员的使用时间,尽量降低人员之间切换的频率,会显著的提升生产效率。

辅助机器和数据服务

这个小节有个观点非常值得推广。辅助机器一定要和目标机器保持尽量的一致性。

如果辅助机器和目标机器差异大的话,可能根本不会在目标机器上出现的问题在辅助机器上出现,这个时候就很糟糕,因为好的程序员已经被灌输了一种思想,就是出现问题时,先从自身找起,如果因为辅助机器带来的意外bug,会降低程序员的工作情绪。

辅助机器的功效自不必提,我们喜欢把目标机器的运行环境在本地搭建,然后在本地先进行测试,因为本地测试便于我们尽快的定位到bug和调试bug。

集成测试是一个非常好的测试观点。在之前的公司,由于人力资源、硬件设备充足,我们的代码会进行一系列的测试,包括代码review、代码测试、集成测试、性能测试。在进行集成测试期间,我们不允许任何人去修改这个版本中的bug,只有等待下个测试版本出现之前,这个版本的代码是不允许人修改的,只有等这个版本的集成测试bug全部修复完毕后,再进行一个版本的测试。

高级语言和交互式编程

高级语言,就不用说了,现在的我们几乎都会使用Java、C++等等高级编程语言来完成我们的项目编程。

对于交互式编程,我并没有读懂这个内容。??????????????

时间: 2024-10-30 16:54:24

人月神话札记:干将莫邪的相关文章

人月神话札记之人月神话

前言:美食的烹饪需要时间,那么稍等片刻,你将享用更多的美味.缺乏合理的进度安排是造成项目滞后的重要原因,因素有以下内容: - 对估算技术缺乏有效的研究 - 进度和工作量混淆,就是说人员和时间可以转换 - 对自己的估算缺乏信心 - 缺乏信心 - 对进度缺少跟踪和监督,所以站立会和燃尽图至关重要 - 意识到进度偏移时,第一个反应是增加人力,而这时大多数情况如同火上浇油,火越来越大,需要的汽油却越来越多 乐观主义 书中说,编程人员都是乐观主义者,我想,在国内,需求者比编程人员更"乐观",他们

人月神话札记之巴比伦塔失败

前言:在最初的世界,人们只有一种语言,所以大家沟通好说去建立一个通天塔,可以通往天堂的巴比伦塔,然而上帝出现了,他交给人们不同的语言,让大伙最终无法进行交流,最终队伍遣散,巴比伦塔就此失败,那么本章作者想要告诉我们的就是"沟通"对于成功的项目很重要. 编程项目中的交流 书中主要针对的是大型项目的交流,然而同样适合我当前所处的团队: 非正式交流:以前在日企和日方沟通主要是电话会议,那么小型团队的非正式交流就是协作的人员互相凑一起说话就可以了. 会议:站立会,分析讨论会,项目评估会等任何有

人月神话札记之专制、民主和系统设计

前言:大教堂的整体设计在基本元素构成上都是一致的.有的教堂偏重于设计师的个人创意,有的教堂舍取设计师的创意而保证设计的纯粹性,在书中提出的观点中,对于计算机系统来说,保持概念的一致性是至关重要的,省略不规则的特性和改进,而反映一系列连贯的设计思路. 获得概念的完整性 一个产品如果其花费在学习使用的时间价值超出了其带给人们的使用价值时,就会难以普及和推广,我觉得产品的易用性是特别重要的.就比如说CSDN推出的Markdown和xheditor相比较,我觉得Markdown并没有征服我,主要是其用起

人月神话札记之外科手术队伍

前言:研究表明,效率高和效率低的实施者之间个体差异非常大,能够达到数量级的水平.类似我这样年龄段的产品经理来说,我认为我只需要有5个精干的成员组成团队,然而我这样的想法就面对着一个很难回避的问题-这样的小型团队很难在有计划的进度安排时间内创造大型的系统! 问题 大家知道,优秀的程序员和较差的程序员的效率存在巨大差异,书中也指出来最好和最差的效率上平均为10:1,编程速度和空间上具有5:1的惊人差异. 需要协作沟通的人员数量影响开发成本,这就意味着人员数量少的情况下,沟通就会减少.然而这不适合于大

人月神话札记:未雨绸缪

前言:软件在设计阶段如果能够多考虑一些后续的维护工作,显然是非常棒的.然而对于现阶段的我,或者很多程序员来说,未雨绸缪有很大难度,我们往往即使已经下雨了,也依然无法把窗户关紧,那么如果你想得到一些指导的话,请随我来,看看我能否品出一些味道来. 没有什么是永恒的,除了变化. 普遍的做法是,选择一个方案,试试看:如果失败了,没关系,再试试别的.不管怎么样,重要的是去尝试. 我觉得书中提供的这两个观点非常的棒,首先,任何事都不可能一成不变,敏捷宣言也提倡我们要拥抱变化.其次,在解决问题的时候,就是要不

人月神话札记:提纲挈领

前言:所谓提纲挈领,从字面上讲就是抓住渔网的总绳,提起衣服的领子,其含义(度娘说要用含义而不推荐用涵义)就是告诉我们做事情要能够抓住要领.那么本篇告诉我们什么是要领呢,就是书面文档,从一开始就要意识到其重要性,那么就不会对文档产生厌烦.因为作为技术人员来说,包括我,普遍对文档没有好感,尤其是看完了长篇大论后,发现无非就是要表达一两句话,那时候,就会气急败坏. 计算机产品的文档 对于该小节,我读了三遍,发现并没有很好的理解,所谓预测->报价->价格之间相互制约的关系,没有弄出来个所以然.希望在以

《人月神话》笔记

人月神话这个名字对我来说很有吸引力,我以为它会是一本讲述计算机历史神话的故事.当我看到第二章我才知道原来这个“人月“是我们项目工程中估计和进度安排中使用的工作量单位:人月.全书共分为以下几个部分: 焦油坑 人月神话 外科手术队伍 贵族专制.民主政治和系统设计 画蛇添足 贯彻执行 为什么巴比伦塔会失败? 胸有成竹 削足适履 提纲挈领 未雨绸缪 干将莫邪 祸起萧墙 另外一面 没有银弹 焦油坑依然存在 对于所有的程序员来讲,都有乐观主义,总是相信自己的代码是肯定能运行的.所以在安排项目的进度的时候就会

读<<人月神话>>

这本书在软件领域知名度很高,每次看到年度推荐的文章里面都有这本书且强烈推荐.出版30年了,可谓经典. 但我在读的过程中并没有那么深的体会.书中很多章节都是基于大型项目或者大型系统的经验总结,至今为止我还没有参与大于30人的项目.只能说自己的境界还不够. 第一章,焦油坑 再也找不到一个词比焦油坑更能形容,软件开发的过程了.我们都在挣扎.计划,计划,不断计划,但还是拖延,拖延,拖延.... 职业的乐趣: 创造性,贡献助人为乐,过程的魅力或者解决问题的成就感或写代码的快感,持续学习新事物,驾驭感. 职

《人月神话》读后感

这个学期选择软件冲程这门课我受益匪浅.在这段学习的过程中读完了一本人月神话则是我认为最有价值的经理. 在软件领域中,很少能有像<人月神话>一样具有深远影响力和畅销不衰的著作.作者布鲁克斯被誉为“IBM System/360之父”,他曾是这一系统的项目经理,后来在设计期任360操作系统的项目经理.由于这一工作,他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖.Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师.1999年,他还荣获