A Philosophy of Software Design读后感100字

《A Philosophy of Software Design》是一本由John Ousterhout著作，Yaknyam Press出版的Paperback图书，本书定价：GBP 14.21，页数：190，特精心收集的读后感，希望对大家能有帮助。

《A Philosophy of Software Design》读后感(一)：太抽象了

在线的中译本，草草的看了一遍，也没有太多code经验，所以体会不够。

1. 架构是迭代的，没有一开始就能完美的架构。

2 复杂性定义=>小的复杂性会累加。复杂性的根源，耦合，依赖？

3 复杂性针对的是读者而不是作者，读者和使用者和维护者是一回事吗？时间久了，自己也变成了读者。

4 权衡要封闭什么，暴露什么

5 之前有观点：函数或类不能太长太大，但是本书讲要深，太浅没有意义，我觉得有道理。太浅的抽象没有意义。

6 先写注释。后写注释感觉只是为了写而写，先写注释，写的过程是思考的过程，强迫自己去把一些问题提前想清楚。

7 一致性，想习惯，养成自己的习惯，遵循行业的习惯。

《A Philosophy of Software Design》读后感(二)：减小软件设计过程中的复杂度

最近刚读完的一本书，书名里面带有philosophy，其实大可不必惊慌，这本书的核心就是关于软件设计中的复杂度。

作者开门见山提出了本书的两个目标，一个是讲述复杂度的各种特点，另外进一步的目标就是介绍减小软件设计复杂度的各种方法和技巧。

这本书页数不多，一个周末就读完了，前半部分1-11章是精华。从12章讲关于注释的地方开始，如果在别的书中读过类似的内容，那么完全可以跳过。

对于任意一个函数，类，模块来说，都包含接口和实现两部分。接口应该尽量简单，通用；而实现应该尽量包含更多的独立内容。作者提出了deep module的概念，我简单类比一下，就是如果你的module是一个瓶子，那么瓶子口应该尽量小，而瓶子的容积应该尽量大。从视觉上看就是一个很“深”的瓶子。

这其实是面向对象设计的基本原则，如果你的工程经验丰富，肯定已经在实际工作中这么做了。当然作者在明确的提出这一点，并且创造了一个deep module 的概念，对于加深印象，和以后跟别人忽悠还是很有用的。

除了deep module之外，还有几章精华覆盖了general和special module，information hiding，异常处理的一下常见误区。这些都是非常有用的内容。

总结来说，推荐花时间读这本书，投入的时间绝对是值得的，不论你是学生还是0-5年经验的程序员。

《A Philosophy of Software Design》读后感(三)：代码设计的新视角

减少软件复杂度是本书的主题，为此作者提出了模块深度的概念，并从该角度对编程中的种种进行了分析。

第四章 Modules Should Be Deep是比较核心的一个章节，我把它的主要内容翻译成了中文，文章是《 软件设计之Deep Module（深模块）》，欢迎阅览和指正。

Module Depth

有人说书中不少内容是老调重弹，在其他书上也可以看到。这诚然不错，但也并不代表本书的价值不高，一般来说任何书籍只要有10%的创新就已经不错，要求样样都新，未免太苛责。作者能够从模块深度这一新角度提供软件复杂度处理的方法论，已经十分不错。书中语言浅白流畅，也有充足的例子，对英文苦手来说很友好。

下面是几个印象比较深的地方，记在这里。

1，注释：注释不仅仅是对程序语言无法描述的部分进行拾遗补缺的工具，同时也是一种设计工具。在写代码前先写注释，可以保证注释有效反映了编写代码时的思路，也有助于提高代码设计的水平。注释过多往往意味着接口复杂、耦合度高；注释占代码的比例高，意味着模块浅。

注释先行的另一个好处是可以给人带来快乐和自豪感，因为这样的注释记录了程序员的的创作过程。

2，异常：异常是接口的一部分，它的增加会增加系统的复杂度。要控制异常的数量，办法之一是从概念上消除异常，比如把“删除”模块变化为“确保不存在”模块；办法之二是隐藏异常，比如TCP协议通过重传将包丢失隐藏在低层；办法之三是在高层进行统一的异常管理；最后的办法是通过不处理异常来避免增加额外的异常。

3，敏捷：迭代和增量的开发方式有利于产生好的设计，但“快速”的要求容易催生战术式的编程，而非战略性的编程。需要将抽象而非特性作为增量的对象，这样才能避免它的弊端。

《A Philosophy of Software Design》读后感(四)：软件开发复杂性解决作者之见

概述

本书2020年炒的太热，是一本好书，但是书中几乎没有提出什么新的思想以及新的方法。可以理解为作者对软件研发的一份个人思考总结。

本书主要围绕软件开发的复杂性来展开，如何定义复杂性？如何识别复杂性？如何降低软件的复杂性？

系统的总体复杂度是由每个部分的复杂度乘以开发人员在该部分上花费的时间总和。而复杂性的症状主要体现在三个方面：一个是在做修改的时候工作量很大，另外一个就是代码阅读认知很困难，最后一个就是修改让开发者者恐慌，不知道会导致什么问题。而对于复杂性的原因，则是依赖性和模糊性导致的。另外，复杂性并不是突然出现的，而是经过日积月累的技术债务累计而产生的，只关注功能，不经过思考，没有设计是复杂性产生的过程。

《A Philosophy of Software Design》读后感(五)：前言

前言

人们已经为电子计算机写了80多年的程序了，但是令人惊讶的是，很少有关于如何设计这些程序，或者好的程序应该是什么样的之类的讨论。有很多与软件开发过程、软件开发工具相关的重要讨论，比如敏捷开发、调试器、版本控制、测试覆盖工具等。也有大量关于开发技术的分析，比如面向对象编程、函数编程、设计模式和算法。上述这些讨论都是有价值的，但是软件设计的核心问题仍然没有。David Parnas在1971年的经典论文“On the Criteria to be used in Decomposing System into Modules”发表，但是软件设计这门艺术的状态在文章发表的45年后仍然没有什么提高。

计算机科学最基本的问题是问题分解：如何处理一个复杂的问题，可以把它分解成可以被独立解决的部分。问题分解是程序员每天都要面对的主要设计任务，然而，不同于这里描述的工作，我没有在任何一所大学找到一门课程是以问题分解作为主要主题的。我们会教授循环和面向对象编程，但没有程序设计。

此外，程序员的质量和生产力也有着很大的不同，但我们没有试图去了解过为什么最好的程序员在变得更好，或者在课堂去教授这些技巧。我曾经和一些我认为的优秀程序员交谈，但他们大部分都很难明确的表达出给他们带来优势的特殊技巧。大部分人声称软件设计技巧是天赋，不能被教授。然而，有相当多的证据表明很多领域的卓越表现与高质量的练习有关，而不是天赋（例如Geoff Colvin的Talent is Overrated）。

这些问题多年来令我困惑和沮丧。我曾经怀疑过软件设计是否能被教授，我曾经猜测是设计技巧把优秀程序员与普通程序员区分开。我最终决定，回答这个问题的唯一答案是尝试教授一门软件设计的课程。最终在斯坦福大学的CS 190课程。在这个课程里，我提出了一组软件设计原则。这个课程的授课方式与传统英文写作课类似。在一个英文课程里，学生们使用迭代的过程进行学习:写草稿、收到反馈、改进重写。在CS 190课程，学生们从零开始建立了坚实的软件理论。然后我们进行了大量的代码审查去定位设计问题，学生们修正他们的项目去修复问题。这让学生们认识到他们的代码如何能通过设计原则来进行提高。

我目前已经教授过软件设计课程三次，这本书是基于课程里产生的设计原则。这些原则在哲学的层面来说很高水平和广泛（在存在之外定义错误），所以对于学生来说很难理解这些抽象的想法。学生们最好通过写代码、制造错误、然后理解他们的错误以及怎么使用原则来修正的过程来学习。

在这一点上你或许会质疑：我凭什么认为自己知道关于软件设计的所有答案？实话说，我没有。当我学习编程时，并没有关于软件设计的课程，并且也没从来没有人教导过我关于软件设计的任何内容。在我学习编程的时代，代码审查实际上是不存在的。我关于软件设计的想法来源于个人读写代码的经验。在我的职业生涯中，我已经写了大约250，000行代码，包括各种语言。我工作过的团队有的从头开始写了三个操作系统，有的写了多文件和存储系统，！！！！在这个过程中，我有了使用不同设计技术的大型系统、实验的问题的第一手的经验。此外，我阅读过大量的别人的代码，这让我看到了各式各样的处理方式，无论是好的还是不好的。

源于这些经验，我尝试提取一些共同的思路，包括应该避免的错误和使用的方法。这本书是我经验的沉淀：描述的每一个问题都是我自己经历过的，建议的每一个方法都是我在自己的编码中成功使用过的。

我不希望这本书成为软件设计的最后一本书；我相信我遗漏了有价值的方法，我推荐的一些方法长期来看可能被证实是不好的。相反，我希望这本书能开启关于软件设计的讨论。将这本书的想法和你自己的经验进行比较，并且自己判断这本书里的方法有没有真的减少软件复杂性。如果你有异议，试着理解这是为什么。我很想听到哪些方法是有用的，哪些是无用的，或者你有的关于软件设计的任何其它想法。我希望接下来的讨论会提高你对于软件设计的共同理解。我会在这本书将来的版本里包含我学习到的内容。

关于这本书，和我交流的最好方式是发送邮件到如下地址：software-design-book@googlegroups.com。我很想听到关于这本书的详细的反馈，比如错误、改进建议，以及和软件设计相关的想法和经验。我对将来的版本可以用到的令人信服的例子特别感兴趣。最好的示例不仅能解释一个重要的设计原则，也足够简单，能在一到两段里描述清楚。如果你想看到其它人在这个邮件地址说些什么并加入到讨论中，你可以加入software-design-book的Google Group。

如果因为某些原因，这个Google Group消失了，在网络上搜索我的主页，它会提供最新的关于这本书的交流方式。请不要向我的私人邮箱发送这本书相关的内容。

我建议你对这本书提供的建议持怀疑态度。首要目标是降低复杂性，这比你在这里读到的任何原则、想法都重要。如果你尝试了这本书的想法，发现它实际上并没有减少复杂性，

那就不要强迫自己去使用它（但是请让我知道你的经验，我很想了解哪些有用哪些没用）。

许多人已经提出了批评和建议，提高了这本书的质量。下列人员为这本书的各种草稿提供了有帮助的建议：Jeff Dean, Sanjay Ghemawat, John Hartmn, Brian Kernighan, James Koppel, Amy Ousterhout, Kay Ousterhout, Rob Pike, Partha Ranganathan, Keith Schwarts以及Alex Snaps。Christos Kozyrakis 建议使用“深”和“浅”来描述类和接口，而不是使用之前的更容易混淆的“厚”和“薄”。我很感谢CS190课程的学生，阅读他们的代码以及讨论代码的过程帮助我把关于设计的想法具体化。