代码大全(第2版)的笔记(388)

>我来写笔记

按有用程度 按页码先后 最新笔记

  • Phil菠菜

    Phil菠菜

    开着douban.fm,用思维导图XMind写《Code Complete》( 《代码大全2》 )的读书笔记,用Dropbox git做版本管理,用RTM(https://www.rememberthemilk.com)做GTD(Get Things Done),计划把860页的《代码大全2》读完,并做一个完整的软件构建笔记与大家分享:)。 xmind笔记放在https://github.com/philsong/codecomplete2 我的读书计划http://jihua.fm/users/104020

    2012-03-17 07:50   13人喜欢

  • Suave

    Suave (trust instinct, be visionary)

    设计是一个启发式过程 隐喻是启示而不是算法 典型情况下需求会有多少改动?IBM和其他公司的研究发现,平均水平的项目在开发过程中,需求会有25%的变化(Boehm 1981,Jones 1994,Jones 2000)。在典型的项目中,需求变更导致的返工占到返工总量的75%到85%(Leffingwell 1997,Wiegers 2003)。 注意项目的商业案例:有些需求作为功能特色来看是不错的想法,但是当你评估“增加的商业价值”时就会觉得它是个糟透了的主意。...

    2012-02-14 14:09   3人喜欢

  • Suave

    Suave (trust instinct, be visionary)

    “险恶的(wicked)”问题就是那种只有通过解决或部分解决才能被明确的问题(1973)。这个看似矛盾的定义其实是在暗示说,你必须首先把这个问题“解决”一遍以便能够明确地定义它,然后再次解决该问题,从而形成一个可执行的方案。这一过程已经如影随形地在软件开发中存在数十年了(Peters and Tripp 1976) 的确,如何全面的分析所面对的问题是最棘手的事情。面对所要构建的系统,我更推荐先仔细查找、分析你所能找到的所有类型系统..

    2012-05-07 13:37   2人喜欢

  • liuh

    liuh (平常心,不要急,不要等)

    高质量的软件设计应该考虑如下目标,如果这些目标之间存在冲突,需要在其中进行折中,并得到一个最优的设计。 1.最小的复杂度 避免”聪明“但是却不容易理解的设计; 2.易于维护 软件的生命期更多的是维护阶段; 3.松散耦合 4.可扩展性 面向未来进行设计 5.可重用性 每一个项目都要为团队的积累做出贡献; 6、7high fan-in,low fan-out 每一个类应该力求被更多其他类使用; 每一个类应该力求使用最少的其他类,才能管...

    2011-12-20 16:23   5人喜欢

  • SunisDown

    SunisDown (在海边行走)

    最小的复杂度(Minimal Complexity 要避免做出“聪明的”设计,因为“聪明的”设计常常都是难以理解的。应该做出简单且易于理解的设计。如果你的设计方案不能让你在专注于程序的一部分时安心地忽视其他部分的话,这一设计就没有什么作用了 易于维护(Easy of maintenance 易于维护意味着在设计时为做维护工作的程序员着想。请时刻想着这些维护程序员可能会就你写的代码而提出的问题。把这些程序员当成你的听众,进而设计出能..

    2015-09-17 09:13   1人喜欢

  • coco+

    coco+ (程序猿出没)

    1.表驱动法: 从表里查找信息而不是使用逻辑语句(if 和 else),用直接访问代替复杂的逻辑控制结构,例如字符分类,月中的天数和保险费。 2.如果有多种不同的消息,而且这些消息可能改变,可能增加,最好使用表驱动法,因为你不得不为每一种消息建立函数或类,如果里面的数据类型改变,你甚至要改变程序逻辑。而使用表驱动,只需要编写少量的代码就可以完成任务。 3.构造查询键值。有时候并不能直接拿数据作为键值直接访问表...

    2014-10-28 22:29

  • 叫什么好

    叫什么好

    代码大全 3.1.2 在进行创建工作之前必须做准备工作的论据 2013-01-06 08:26:42 在一个正常的生态系统中,海鸥以沙丁鱼为食,沙丁鱼吃鲜鱼,鲜鱼吃水虱,其结果会形成一个正常的食物链。在编程工作中,如果软件食物链的每一级都可以吃到健康的食物,其结果是由一群快乐的程序员写出的正确代码。 2013-01-06 08:27:17 如果需求定义遭受了污染,那么这又会影响结构设计,而这将最终影响创建活动。这将导致程序员们脾气暴躁..

    2013-01-08 21:22   1人喜欢

  • 死鱼眼28号

    死鱼眼28号 (mieru, kaeru)

    稳定的需求是软件开发的圣杯。 这是吐槽书籍么-_- 戳中笑点   (2回应)

    2012-09-01 21:10   1人喜欢

  • 王一刀

    王一刀 (只身打马过草原,独自仗剑走天涯)

    架构应该描述所有主要决策的动机。谨防“我们向来这么做”这种自认为有理的说法。有这样一个故事,Beth想按照她丈夫家祖传的广受好评的炖肉菜谱来做一锅炖肉。她丈夫Adbul说,他母亲是这样教他的:先撒上盐和胡椒,然后去头去尾,最后放到平底锅里盖上盖子炖。Beth就问了:“为什么要去头去尾呢?”Abdul回答说:“我不知道,我向来这么做。这得问一下我母亲。”他打电话给母亲,母亲说:“我不知道,我向来这么做。这得问一下你祖...

    2011-04-08 19:41

  • 落叶

    落叶

    在软件开发中,如果需求被污染了,那么它就会污染架构,而架构又会污染构建。这样会导致程序员脾气暴躁、营养失调;开发出的软件具有放射性污染,而且周身都是缺陷。

    2017-06-13 22:30

<前页 1 2 3 4 5 6 7 8 9 ... 38 39 后页>

笔记是你写在书页留白边上的内容;是你阅读中的批注、摘抄及随感。

笔记必须是自己所写,不欢迎转载。摘抄原文的部分应该进行特殊标明。

代码大全(第2版)

>代码大全(第2版)