读后
《大道至简》读后感（2）
在第一章中，作者通过愚公移山典故说明软件工程中的各个问题。软件在编程之外还有许多的事情要去做：确定目标、方案，需要的技术人员、管理人员以及其他外协人员。有的时候，也需要明白折中的道理。过去，我很少去具体的确定一个目标，与他人的协作更是很少。有事情大多是直接去做，不成便是不成。一直以来这样做，我有许多 ......
《大道至简》读后感
《大道至简》读后感 读完了《大道至简》这本关于软件工程的书，让我对软件工程有了新的了解，虽然在此之前我对软件工程没有太深的了解，一直以为就是写程序，读完了这本书我对软件工程的认识更进一步。 这本书中蕴涵了许多哲学大道理，还有我不太了解的专有名词，但使我对工程有了新的认识。 大一上学期，学习了C语言， ......
《大道至简》读后感
《大道至简》是一本揭示简洁之美的书籍。它引导着我们认识到，在这个信息爆炸的时代，简单并不意味着表面上的简单，而是一种精炼、纯净、精确的表达方式。读完这本书，我深受启发，产生了一些感悟。 首先，我认为这本书的重要性在于，它为我们揭示了一种新的美学。传统上，我们认为美是繁复的，需要精细的细节和复杂的组合 ......
人月神话读后感3
对于工作量和工作时间的估算，对于所有的设计者来说都是一个难题。因此我们也在思考一个问题，对于产品的设计，第一次可能因为经验不足出现各类问题和各种错误，第二次会不会比第一次好一些。毕竟我们默认一个人在某个领域的深耕会获得大量的经验，从而有助于他将工作做好。然而《人月神话》的结论却兜头给我们浇了一盆冷水 ......
人月神话读后感2
“人月”难道真的无法换算吗？添加人手对于项目的进展难道一点作用都没有吗？对此，书中也是予以了解答“人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。”上述的条件在编程领域几乎是不可能的，可以想见，在实际的工作中也极少存在有这些既可以分解，又不需要交流的工作 ......
《人月神话》读后感（二）
第七章的主题是为什么巴比伦塔会失败？书中写道巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。在日常编码中我们要明白团队的重要性，团队在一个完美的项目中是不可缺少的存在，在团队中要学会交流，不要“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假 ......
人月神话读后感1
为什么“人月”是“神话”。小学的时候我们都做过这样的应用题：“工厂需要加工一批零件，安排5名工人的话需要10小时完成，那么安排25名工人加工，多少小时可以完成”之类的。对于这类题目，小学一二年级的学生都可以轻松得到答案。也正是如此，如今的工作中，仍有不少同仁秉持这样的小学生思维来衡量工作量，跟进工作 ......
人月神话读后感3
人月神话的观点：是与非这一章，也是20周年版本新增的内容，20年的发展让初版的一些观点变得过时，但是仍然有不少观点仍然适用，因而作者在这一章里把之前的每一章的主要观点都抽离出来，并对已经过时了的观点做了说明，可以说这一章是整本书的精华了吧。 20年后的人月神话这一章很长很长，算是一篇单独的文章，讨论 ......
《人月神话》读后感（一）
听到名字，如果不观看内容的话，我还以为是一本关于神话的小说，在读了《人月神话》这本书之后才知道《人月神话》这本书主要讲的是软件工程中人于团队关系的。 第一章的主题是焦油坑。主要讲的是编程系统产品开发的工作量是供个人使用的、独立开发的构建程序的九倍，我估计软件构建产品化引起了三倍工作量，将软件构件整合 ......
软件工程日报——《人月神话》读后感三
最近读了一本叫做《人月神话》的书，这本书是由软件工程大师Fred Brooks所著，是一本关于软件开发的经典之作。在这本书中，作者通过自己多年的实践经验，深入浅出地阐述了软件开发中的一些基本原则和方法，对于我们软件开发人员来说，是一本非常有价值的参考书。在这本书中，作者提出了一个非常有名的观点，就是 ......
2023.3.30-构建之法-3月份读后感3
最近，我阅读了构建之法的下一部分，有了一定的感受。 过去，我对于开发阶段的日常管理的了解不够。自己的团队可能出现很多种情况：闭门造车、每日构建、构建大师、宽严皆误、小强地狱等。对于这些情况，我们都应该考虑如何解决这些问题。在以后，在面对这些情况时，可以认真考虑如何解决这个问题。 过去，我在编写程序的 ......
构建之法读后感1
第三章内容：软件工程师的成长。 其中讲了“技能的反面”，作者由开始的“精通玩魔方”到“精通玩魔方，只到第二级。”再到“能够独立地还原一面，其他看口诀可搞定。”到最后，技能上不了台面。 巴克斯顿说技能的反面是“Problem Solving”——“解决问题”，例子：一个IT专业的大学生来面试，简历上写 ......
3.29博客（构建之法读后感2）
软件开发是一种集体活动，其中必然面临各成员间的协调、统一问题。银行每天都要对各网点进行清算结账，软件开发也是一样的，必须找到一种方法来衡量每天的工作，保证每天的工作能够有效的持续下去，最终把软件开发的过程变成一种内在的过程。这种方法就称为每日构建或是持续集成。每日构建构建的过程是完全自动化的，通过预 ......
《人月神话》读后感
书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流 ......
人月神话读后感2
这两天把人月神话的每一个章节都读了一下，可能是因为没有做过大项目的原因吧，有很多地方都不是很懂，所以也谈不上是读后感，只能说是阅读笔记吧。 人月神话这一章，作者主要介绍了软件开发项目在进度安排上经常出现的问题。首先，由于我们对项目开发的进度估计过于乐观，我们估计出来的工作量通常会低于实际需要的工作量 ......
《人月神话》——读后感3
过去是怎么做的： 我只经历过两人组队和三人组队，我无法分辨当时的组队情况分工什么的是好是坏。 为什么这样不好： 所以，这个问题我无法回答。我只能说，我们将各个题目分开成细化的部分，然后分成员去解决。 解决办法： 还是要多学习基础知识，在组队交流编程中，可以明显的感受到自己与其他人的差距，从而更加激励 ......
人月神话读后感1
这本书虽然有做过一些细小的修订，用更新的思想进行扩充，但我还是认真阅读了这本书的第一版序言。其中，作者提到在很多方面，管理一个大型的计算机编程项目和其他行业的大型工程很相似，这一点虽然我没有亲身经历过，却能感同身受作者的思想和态度，我想，任何一件或大或小的完整工程都是有相通之处的，甚至是每一件事情。 ......
2023.3.28-构建之法-3月份读后感2
最近，我阅读了构建之法的下一部分，我有了一些感受。 过去，我在编程时没有重视团队的重要性，对于团队的认识还不够。团队有一致的集体目标。团队成员有各自的分工，互相依赖合作，共同完成任务。软件团队的模式有一窝蜂模式、主治医生模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐模式、爵士乐模 ......
构建之法读后感三
通读完全书后，我对书中介绍的软件行业相关内容有了更深刻的理解，文章采用大量幽默生动的语言进行讲解，通俗易懂，并且在每个章节的最后还有项目题型供我们去加深记忆，做软件一定要注重用户的体验和需求，只有满足这一点，软件才能交付完结，例如ui界面的设计，要多从用户的角度去思考问题，初次之外，软件的测试也很重 ......
《人月神话》——读后感2
过去是怎么做的： 我总是写完全部的代码再进行测试。 为什么这样不好： 如果bug很多，就会导致最后的提交时刻，要一次次的重复查找bug并解决，甚至推翻重写代码，这是致命且让人感到十分枯燥的。 解决办法： 最好按照书中的编程习惯，制定一个恰当的解决测试办法和时间进度安排，避免出现最后时刻才测试的状况， ......
《人月神话》——读后感1
过去是怎么做的： 我认为编程的乐趣小于苦恼，似乎痛苦的事情更多。而且编程中找bug是更令人烦恼的事情。 为什么这样不好： 会使我丧失掉编程的兴趣，让我失去动力。 解决办法： 更仔细写代码，不要写太多bug，并且一开始就注重代码的规范性，避免日后看不懂，从而丧失编程动力与乐趣。 具体读后感： 焦油坑： ......
《人月神话》——读后感1
焦油坑： 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题 ......
2023.3.27-构建之法-3月份读后感1
最近，我阅读了构建之法的一部分，我有了一些感受。 过去我对于软件工程的了解不够深入，对于“程序=数据结构+算法”这句话的理解不够深入。构建管理、源代码管理、软件设计、软件测试、项目管理相关内容是软件工程的核心部分。广义上的软件工程也包括用户体验、用户界面设计等。所以，“软件=程序+软件工程”、“软件 ......
《构建之法》读后感3
个人能力的衡量与发展 把每个人的工作有序地组织起来，就是团队的流程。通俗地来说，流程就是节奏。在家里每个家庭成员按照自己的生活节奏有序地生活，在单位里每个员工按照自己的工作节奏工作，他们每个人都有自己的节奏，但都在遵守着一个家庭、一个单位（一个团体）的节奏，这就是一个软件团队的软件开发流程。 尽管软 ......
《构建之法》读后感2
单元测试 单元测试是一个合格的软件必备的流程，就像运动员在比赛之前的热身，活动身体的每一块肌肉，检查它是否处于紧绷状态，确保比赛时的完全发挥。 那么一个好的单元测试的标准是什么？ 1.单元测试应该在最基本的功能上/参数上验证程序的正确性 一个软件的基本功能是用户最常用的功能。比方说一个MIS系统，它 ......
构建之法读后感二
两人合作这一章中，主要对与代码规范以及设计规范，代码复审进行了阐述，代码首先要保证简明，易读，无二异性，其次还要注意 缩进，行款，括号，断行与空白的{}行，分行，下划线，大小写，注释等等，设计要考虑函数，goto出口，错误的处理也很重要，代码复审的工作是不可或缺的。 团队和流程这一章节主要讲述的是团 ......
《代码大全》读后感（3）
读《代码大全》有感 又一次进行博客的阅读更新了，这次还是对《代码大全》这本书的分析，在这次的阅读中，我又有了很多的感触。这次我看了第六模块，第六部分是系统考虑，这部分是对软件管理方面的考量，具体包括程序规模对构建的影响，如何去管理构建过程，如何集成模块，以及介绍软件构建的工具。这部分内容像是给Man ......
《代码大全》读后感（2）
读《代码大全》有感 又一次进行博客的阅读更新了，这次还是对《代码大全》这本书的分析，在这次的阅读中，我又有了很多的感触。这次我看了第六模块，第六部分是系统考虑，这部分是对软件管理方面的考量，具体包括程序规模对构建的影响，如何去管理构建过程，如何集成模块，以及介绍软件构建的工具。这部分内容像是给Man ......
《代码大全》读后感（1）
读《代码大全2》有感。 1.软件的构建： 软件开发的核心活动，唯一一项必不可少的工作。 构建活动（详细设计、编码、调试、集成、开发者测试）包含：1）验证有关的基础工作已经完成，因此构建活动可以顺利地进行下去。2）确定如何测试所写的代码。3）设计并编写类 和子程序。4）创建并命名变量和具名常量。5）选 ......