Scribd Logo
Upload

Welcome to Scribd!

  • 87 views

    A PHILOSOPHY OF SOFTWARE DESIGN by John Ousterhout

    Uploaded by

    mediadroid2018
    This document discusses strategies for managing software design complexity. It defines complexity as anything related to a software's structure that makes it difficult to understand or modify. Complexity can be evaluated based on how design decisions propagate changes, the cognitive load on developers, and unknown factors that impact a task. The document contrasts deep and shallow modules, noting deep ones have simple interfaces but powerful functionality, while shallow ones have complex interfaces but limited functionality. It provides guidelines for combining or separating modules based on information sharing, interface simplicity, and resource duplication. Comments are discussed as a way to capture design rationale not evident in code. Naming conventions recommend longer names for entities referenced over greater distances in code. Both tactical and strategic programming approaches are examined, noting tactical

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    A PHILOSOPHY OF SOFTWARE DESIGN by John Ousterhout

    Uploaded by

    mediadroid2018
    87 views1 page
    This document discusses strategies for managing software design complexity. It defines complexity as anything related to a software's structure that makes it difficult to understand or modify. Complexity can be evaluated based on how design decisions propagate changes, the cognitive load on developers, and unknown factors that impact a task. The document contrasts deep and shallow modules, noting deep ones have simple interfaces but powerful functionality, while shallow ones have complex interfaces but limited functionality. It provides guidelines for combining or separating modules based on information sharing, interface simplicity, and resource duplication. Comments are discussed as a way to capture design rationale not evident in code. Naming conventions recommend longer names for entities referenced over greater distances in code. Both tactical and strategic programming approaches are examined, noting tactical

    Original Description:

    A PHILOSOPHY OF SOFTWARE DESIGN by John Ousterhout

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses strategies for managing software design complexity. It defines complexity as anything related to a software's structure that makes it difficult to understand or modify. Complexity can be evaluated based on how design decisions propagate changes, the cognitive load on developers, and unknown factors that impact a task. The document contrasts deep and shallow modules, noting deep ones have simple interfaces but powerful functionality, while shallow ones have complex interfaces but limited functionality. It provides guidelines for combining or separating modules based on information sharing, interface simplicity, and resource duplication. Comments are discussed as a way to capture design rationale not evident in code. Naming conventions recommend longer names for entities referenced over greater distances in code. Both tactical and strategic programming approaches are examined, noting tactical

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    87 views1 page

    A PHILOSOPHY OF SOFTWARE DESIGN by John Ousterhout

    Uploaded by

    mediadroid2018
    This document discusses strategies for managing software design complexity. It defines complexity as anything related to a software's structure that makes it difficult to understand or modify. Complexity can be evaluated based on how design decisions propagate changes, the cognitive load on developers, and unknown factors that impact a task. The document contrasts deep and shallow modules, noting deep ones have simple interfaces but powerful functionality, while shallow ones have complex interfaces but limited functionality. It provides guidelines for combining or separating modules based on information sharing, interface simplicity, and resource duplication. Comments are discussed as a way to capture design rationale not evident in code. Naming conventions recommend longer names for entities referenced over greater distances in code. Both tactical and strategic programming approaches are examined, noting tactical

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 1

    A PHILOSOPHY OF SOFTWARE

    DESIGN
    Authors John Ousterhout

    DESIGN COMPLEXITY DEEP VS. SHALLOW


    Complexity is anything related to the <Interface>

    <Interface>
    structure of a software that makes it hard
    Functionnalities
    to understand or modify. It can be defined Functionnalities

    as:
    (a) Shallow module (b) Deep module
    Õ
    C= c p · tp
    p

    Where p is the number of components, cp Deep modules have a simple interface


    the complexity of each component, et tp and powerful functionnalities, shallow
    the fraction time accorded to it. modules have complex interface, not
    much functionnality and hide does not
    NATURE OF COMPLEXITY hide complexity.
    Depedencies and obscurity causes
    complexity. It can be evaluated by TOGETHER OR APART ?
    questionning the 3 points: Modules, classes or functions should be
    together if:
    I Change amplification: amount of
    code affected by each design decision; I information is shared,
    I Cognitive load: how much a devel- I it simplifies interface,
    oper need to know to complete a task; I it avoids ressources duplication.
    I Unknown unknows: obviousness of
    which piece of code must be modified Keep a separation between specialized
    to complete a task. and general entities.

    STRATEGIC VS. TACTICAL COMMENTS


    Tactical programming Comments should capture information
    ic

    that was in the mind of the designer and


    g

    make things work,


    te
    ra
    St

    quickly. Strategic could not be represented in the code.


    Progress

    al
    Tactic
    programming invest
    time on design.
    NAMING
    Time
    “The greater the distance between a
    name’s declaration and its uses, the
    longer the name should be.”
    At the beginning, a tactical approach to
    programming will make progress more
    quickly than a strategic approach. Andrew Gerrand
    However, complexity accumulates more
    rapidly under the tactical approach, wich
    reduces productivity.

    You might also like