• 代码大全2阅读笔记 9~1


    第一部分 打好基础

    第一章 欢迎进入软件构建的世界

    软件构建是软件开发的核心活动;构建活动是每个项目中唯一一项必不可少的工作。

    软件构建的主要活动包括:详细设计、编码、调试、集成、开发者测试(developer testing)(包括单元测试和集成测试)。

    构建也常被称作“编码”和“编程”。
    构建活动的质量对软件的质量有着实质性的影响。

    第二章 用隐喻来更充分地理解软件开发

    通过把软件的构建过程比作是房屋的建设过程,我们可以发现,仔细的准备是必要的,而大型项目和小型项目之间也是有差异的。

    通过把软件开发中的实践比作是智慧工具箱中的工具,我们又发现,每位程序员都有许多工具,但并不存在任何一个能适用所有工作的工具,因地制宜的选择正确工具是成为有效编程的程序员的关键。 

     

    第三章 三思而后行:前期准备

     

    准备工作的中心目标就是降低风险:一个好的项目规划者能够尽可能早的将主要的风险清除掉,以使项目的大部分工作能够尽可能平稳的进行。目前,软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划,因此准备工作就倾向于集中改进需求分析和项目计划。

    你所从事的软件项目的类型对构建活动的前期准备有重大影响--许多项目应该是高度迭代式的,某些应该是序列式的。

    如果没有明确的问题定义,那么你可能会在构建期间解决错误的问题。(找到需要打的靶)

    如果没有做完良好的需求分析工作,你可能没能觉察待解决的问题的重要细节。(瞄准靶,选择好箭的飞行路线)

    如果没有做完良好的架构设计,你可能会在构建期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加,因此,也要确认“架构”已经到位了。(根据距离的远近以及环境,选择适合的弓箭,安排每支箭的力度角度策略,力求最少的箭枝射中靶心)

    架构包括:程序组织(主要构造块)、主要类、数据设计、业务规则、用户界面设计(如果需求阶段没有)、稀缺资源管理、安全性、性能、可伸缩性、互用性、国际化本地化、输入输出、错误处理、容错性、架构的可行性、过度工程(部分代码健壮,部分不健壮)、关于买还是造的策略、关于复用的策略、架构的总体质量、需求变更策略。

    (评价:系统分析--类图静态、业务顺序图状态;业务类图--数据存储;通用类业务--平台框架组件)

     

     

    第四章 关键的“构建”决策

     

    本章关注的焦点是程序员和技术带头人必须(直接或间接)负责的准备工作。在向工地进发之前,如何选择合适的工具别在你的腰带上,你的手推车里该装哪些东西。

    在高质量的软件中,你可以看到“架构的概念完整性”与“其底层实现”之间的关系。“实现”必须与(指导该实现的)“架构”保持一致,并且这种一致性

     

     

    是内在的、固有的。这正是变量名称、类名称、子程序名称、格式约定、注释约定等这些针对“构建活动”的指导方针的关键所在。

    假如没有一种统一的规则,你创作出来的东西将会充斥着各种不同的风格,显得混乱而邋遢。这些不同的风格将使你的大脑承受沉重负担--而这仅仅是为了理解不同编程风格之间的(本质上是随意的)差异。 

     

    大多数重要的编程原则并不依赖特定的语言,而依赖于你使用语言的方式。

     

    在开始编程之前,做好一些约定。“改变代码使之符合这些约定”是近乎不可能的。 

     

     

    第二部分 创建高质量的代码

    第五章 软件构建中的设计

     

    无论是以何种方式来进行设计,小型项目也能和大型项目一样从精心的设计之中获益,而如果能认识到设计是一项明确的活动,你就更会获益匪浅。

     

    5.1 设计中的挑战

     

    设计是一个险恶的问题。你必须首先把这个问题“解决”一遍以便能够明确的定义它,然后再次解决该问题,从而形成一个可行的方案。

    设计是个了无章法的过程(即使它能得出清爽的成果)。因为在此过程中你会犯很多的错误。还因为优劣设计之间的差异往往非常微妙。还因为你很难判断设计何时算是“足够好”了。设计到什么细节才算够?有多少设计需要用形式化的设计符号完成,又有多少设计可以留到编码时再做?什么时候才算完成。

    设计就是确定取舍和调整顺序的过程。

    设计受到诸多限制。

    设计是不确定的。

    设计是一个启发式过程。

    设计是自然而然形成的。他是不断的设计评估、非正式讨论、写试验代码以及修改试验代码中演化和完善的。

     

    5.2 关键的设计概念

     

    软件的首要技术使命:管理复杂度

    作为软件开发人员,我们不应该试着在同一时间把整个程序都塞进自己的大脑,而应该试着以某种方式去组织程序,以便能够在一个时刻可以专注于一个特定的部分。

    所有软件设计技术的目标都是把复杂问题分解成简单的部分。子系统间的相互依赖越少,你就越容易在同一时间里专注问题的一小部分。精心设计的对象关系使关注点相互分离,从而使你能在每个时刻只专注于一件事情。在更高汇聚的层次上,包(packages)提供了相同的好处。

    保持子程序的短小精悍也能帮助你减少思考的负担。从问题的领域着手,而不是从底层实现入手去编写程序,在最抽象的层次上工作,也能够减少人的脑力负担。

    一个程序中的设计层次。系统1首先被组织为子系统2子系统被进一步分解为类3然后类又被分解为子程序和数据4每个子程序的内部也需要进行设计

     

    5.3 设计构造块:启发式方法

     

    找出现实中的对象。在确定设计方案时,首选且最流行的一种做法便是“常规的”面向对象设计方法,此方法的要点是辨别现实世界中的对象以及人造的对象。

    形成一致的抽象。

    封装实现细节。当继承能简化设计时就继承。

    隐藏秘密(信息隐藏)。信息隐藏中所说的秘密主要分为两大类:隐藏复杂度;隐藏变化源。问题“这个类需要隐藏些什么?”正切中了接口设计的核心。在设计的所有层面上,都可以通过询问该隐藏些什么来促成好的设计决策。

    找出容易改变的区域。

    预料不同程度的变化。

    保持松散耦合。

    查阅常用的设计模式。

    下列的启发式方法有时也很有用:高内聚性、构造分层结构、严格描述类契约、分配职责、为测试而设计、避免失误、有意识的选择绑定时间、创建中央控制点、考虑使用蛮力、画一个图、保持设计模块化

     

    5.4 设计实践

     

    分而治之

    自上而下和自下而上的设计方法

    建立试验性原型

    合作设计

    要做多少设计才够

    记录你的设计成果

    要点

    软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对此最有帮助。

    简单性可以通过两种方式获取:一是在同一时间所关注的本质性复杂度的量,二是避免生成不必要的偶然的复杂度。

    设计是一种启发式的过程。固执于某一种单一方法会损害创新能力,从而损害你的程序。

    好的设计都是迭代的。你尝试设计的可能性越多,你的最终设计方案就会变得越好。

    信息隐藏是个非常有价值的概念。通过询问“我应该隐藏些什么?”能够解决很多困难的设计问题。 

     

     

     

     

     

       文章参考https://wenku.baidu.com/view/d856fb1ba8114431b90dd859.html#

  • 相关阅读:
    docker国内镜像地址
    springBoot+websocket集群系列知识
    多个idea项目使用同一个tomcat
    nginx+tomcat遇到的https重定向到http问题
    设置常用错误页面自定义显示
    mysql关于索引的一些零碎知识点(持续更新)
    Idea使用Lombok简化实体类代码
    mysql索引分类及实现原理
    使用SpringSession和Redis解决分布式Session共享问题
    HashMap ConcurrentHashMap解读
  • 原文地址:https://www.cnblogs.com/ltw222/p/13752590.html
Copyright © 2020-2023  润新知