ZCC的专栏

10人程序开发队伍的沟通模式:    外科医生：Mills称之为首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。他使用例如PL/I的结构化编程语言，拥有对计算机系统的访问能力；该计算机系统不仅仅能进行测试，还存储程序的各种版本，以允许简单的文件更新，并对他的文档提供文本编辑能力。首席程序员需要极高的天分、十年的经验和应用数学、业务数据处理或其他方面的

一、大型编程项目中的交流:    (1)非正式途径:  清晰定义小组内部的相互关系和充分利用电话。     (2)会议: 常规项目会议    (3)工作手册   二、大型编程项目的组织架构:    (1) 树状编程队伍       a、任务       b、产品负责人 :  组建团队，划分工作及制定进度表       c、 技术主管或结构师:

在未来的十年内，无论是在技术还是管理方法上，都看不出有任何突破性的进步，能够保证在十年内大幅度地提高软件的生产率、可靠性和简洁性。        一、摘要     所有软件根本任务:打造构成抽象软件实体的复杂概念结构                   次要任务:使用编程语言表达这些抽象实体，在空间和时间限制下将它们映射成机器语言      二、根本困难    软件开发中困难的

任何人若想看到一件完美无瑕的作品，他所想的那种作品过去不存在，现在和将来也不会出现。   ------->一、存在银弹     出重用和交互的构件开发是解决软件根本困难的一种方法。部分人认为软件困难来自“编程人员缺乏构建当今软件的技术”。而我认为根本困难是固有的概念复杂性，无论是任何时间，使用任何方法设计和实现软件的功能，它都存在。        二、《没有银弹》提出了全力解决复杂

实践是最好的老师 。                                     ----普布利乌斯        实践是最好的老师 ，但智者还能从其他的地方有所收获。

一、   核心观点-----概念完整性和结构师     二、           增量开发模型更佳——渐进地精化三、    人就是一切（或者说，几乎是一切）  现团队质量目前是项目成功最大的决定因素，实际上是下一个次重要因素的4倍。 四、    操作系统世界已经统一了(1)  IBM MVS和VM环境(2)  DEC VMS环境(3) Unix环境，

我们理解的也好，不理解的也好，描述都应该简短精练。 ---塞缪尔·巴特勒，讽刺诗第1章焦油坑 1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。1.2 编程行业

《人月神话》这本书讲述了三十年前软件专案管理和经验的书。论述开发人员缺陷:        第一关键: 乐观        第二关键: 人月       (1)人、月之间不能换算，换言之，2个人做5个月完成，不等于说5个人做2个月完成。       (2)在项目后期增加人手，只能使工期进一步推迟；       (3)项目越大，单位工作需要的人月越多。       一、

他应该瞪大眼睛紧盯着诺亚，然后......好好学习一下，看他们当时是怎样把那么多东西塞进一个小小的方舟上的。     一、作为成本的程序空间     程序有多大？时间和空间开销   二、规模控制    对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。系统结构师必须保持持续的警觉，确保连贯的系统完整性。培养开发人员从系统整体出发，面向用户的态度是软

不了解，就无法真正拥有。                                                                                             ------------歌德      一、需要什么样的文档     a.使用程序:不同用户需要不同级别的文档     (1)目的     (2)环境     (3)范围

带来坏消息的人不受欢迎。                              -------------------索福克勒斯   一、里程碑还是沉重的负担    (1)制定进度表：进度表的每一件事被称为"里程碑"  二、其他的部分反正会落后      进取是很多优秀队员和团队不可缺少的心理素质。           PERT技术是关键路径计划的细化。   

不变只是愿望，变化才是永恒。                                   --------斯威夫特            一、唯一不变的就是变化本身      软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。     二、为变更设计系统     (1)细致的模块化     (2)可扩展的函数     (3)精确完整的

概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是10人一种崭新的组建编程开发团队的方法。    系统的体系结构（architecture）指的是完整和详细的用户接口说明。对于计算机，它是编程手册；对于编译器，它是语言手册；对于控制程序，它是语言和函数调用手册；对于整

过去几十年的大型系统开发就犹如一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每

聚沙成塔，集腋成裘。                                                          ---奥维德     面对估算过高的难题，结构师有两个选择：     (1)削减设计     (2)建议成本更低的实现方法——挑战估算的结果            a. 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配

巧匠因为他的工具而出名                                        ---谚语     一、目标机器   目标机器:需要若干操作员和一两个系统 编程人员，以保证机器上的标准支持是及时更新和实时可用的。     二、辅助机器和数据服务    (1)仿真装置  (2)编译器和汇编平台   (3)程序库和管理  (4)

在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因如下:第一，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这

一、剔除bug的设计:关键的工作是产品的定义     细致的功能定义、仔细的规格说明、规范化的功能描述说明以及这些方法的措施，将大大减少系统中bug的数量。    (1)测试规格说明    (2)自上而下的设计   体系结构设计、设计实现、物理编码    (3)结构化编程 二、构件单元测试   (1)本机调试   (2)内存转储   (3)快照   (4

一、文档化的规格说明--------手册         手册不仅要描述包括所有界面在内的用户可见的一切，还要避免描述用户看不见的事物。               二、形式化定义:用于外部功能，说明它们是什么       不要携带两个时钟出海，带一个或者三个。       三、直接整合             四、会议和大会             周

在堆积如山的文件资料中，少数文档是关键枢纽，每一件项目管理的工作都围绕着它们运转。这些文档是项目经理最重要的个人工具。       计算产品的文档：      (1)目标:定义满足的目标和需要，定义迫切需要的资源、约束和优先级。      (2)技术说明:计算机手册加性能规格说明，它是在计划新产品时第一个产生，并且最后完成的文档。      (3)进度      (4)预算