品读《构建之法》及几个问题的提出

《构建之法》这本书拿来第一印象就是包装精美,拜读此书,我这本书看似轻松幽默,其实是通过一个个人物对话,阐述了很多重要的理论性的概念。譬如它解释了什么叫做软件,软件=程序+软件工程。这本书每一章都有主要的方向,对于书中说的开发员的成长印象很深,它的告诉了迷茫中的我,程序开发人员的职业规划是怎样的。并强调了写出规范代码的重要性,一个规范的代码可以让合作者和审读者看懂,对于软件开发过程是十分重要的。代码还需要有总体的框架,否则后来需要一修再修,得不偿失。

写程序需要有合作意识,要看别人写的,明白别人的思路,同时也需要多交流。否则可能造成做出很多重复性内容,自己写的模块需要作出详细的解释,让别人调用的时候能够理解。程序员在团队中成长的速度才是最迅速的,一花独放不是春,百花齐放春满园。只有团队协作才能做出一个界面友好,质量过硬的优秀软件。每个分工明确,共同努力的team是保证软件顺利开发的关键。

第二章讲单元测试的概念,单元测试不但需要测试模块完成的程度如何,还有从用户的角度出发,去查实用完成度如何,并把之前找到的BUG全部在找出来,一一验证,每个建构需要自动化的回归测试,尽快尽早的发现问题、看看是否有漏洞和落下的地方,统一进行回归测试。确保BUG不会在最后版本中复发,不仅需要保证每个模块的稳定和高内聚,更保证了软件的功能与质量。

我在读《构建之法》中想到了如下几个问题:

1.代码复审的时候如果新的人员的加入有新的想法,要增加或改变功能,那是究竟是效率优先,还是创意优先呢,还是折中处理呢?

2.结对编程的时候总觉得怪怪的,担心出错,这样编程效率就会降低,结对编程如何解决这个问题?

3.代码的规范性,国内国际每个公司都一样吗?有的规则太多,如何做到全部检查出来?

4.《构建之法》应该适用于所有程序语言吗?我想学Java,现在已经买了Java的书,学习java是通过看视频好还是看书好?

5.开发程序员可能到一定岁数就要转行了,如何看待国内这一现象?

时间: 2024-08-29 16:31:33

品读《构建之法》及几个问题的提出的相关文章

初读《构建之法》小感

本人今年大三,软件工程专业,学校是在大三下开始推荐这本书.本学期我们上了<软件测试>这门课,结合翠娟老师课堂和书里的内容,让我印象深刻的是在代码开发中结对编程和团队合作的重要性.在此之前,老师一遍遍的跟我们强调软件工程的重要性,但在整个课程的学习过程中,只背了些晦涩难懂的概念.看了几章<构建之法>之后,不敢说瞬间打通任督二脉,但真的很让我着迷.作者的思路很清晰,文字也很有趣,让人欲罢不能.目前看了一部分还没看完,但我已经从中学到了很多,作者关于软件开发的流程介绍以及程序员生涯的理解

初入《构建之法》

开篇章先是提到了软件测试方向的内容:软件=程序+软件工程,几乎所有的程序猿都知道这句名言,而且我们在学习软件工程时老师也向我们强调了这点,老师还说过软件=程序+数据+文档. 软件学科现在已经成为比较独立的一个专业学科,虽然相对计算机专业学科的会年轻很多.但很多人还是把软件类归结于计算机类,向我们介绍说是软件金融服务专业,很多人的反应是问计算机系的?反到忽略了软件学院专业的.书中提到了托尼·霍尔(Tony Hoare)比较了计算机科学与软件工程的不同侧重之处,像计算机科学注重发现和研究长期的.客观

构建之法感悟

观<构建之法观>感悟 当第一看到构建之法的时候会以为它是一本关于架构之类的书,觉得会是很枯燥无味的,但是,当你翻开第一页的时候,看到目录的时候你就会觉得这是一本内容丰富的书,当你翻开第一章,开始看里面的内容的时候,你不会觉得枯燥无味,从一开始名词的解释开始就会吸引的目光,会不自主的跟随作者的思绪一步一步向前做,通过作者极具说服力的观点,再通过简单但极具说服力的例子向你进一步解释阐明内容. 构建之法向是一本带你走进软件工程的指导之书,从个人技术的提升开始,各阶段测试,让我们对个人技术的方面有了清

Week2-作业1 -阅读《构建之法》

首先,<构建之法>这本书还是值得细细品读的. 这本书的优点在于,相关的重要术语都解释并加粗了字体,其次本书的内容不同于其它书本,采用更简洁更直白更贴近生活的语言讲述着软件工程的相关概念,便于理解. 第一章 在阅读第1.2.2节时,感受最深,记得开学初有老师就给我们分析过计算机专业和我们专业的区别,当时是给我们讲的是计算机科学注重的是理论,偏向于硬件方面,而软件工程则注重实践,偏向于软件方面.然很蒙圈的问题,在阅读此节又加深了对二者的了解. 书中的概括: 计算机科学与软件工程的不同侧重点 计算机

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

简读《构建之法》,所想问题展示

1,<构建之法>这本书全局语言通俗,学生很容易读懂,但是存在一个隐患:学过软件工程,我们只是笼统的理解,而对这方面的专业知识很少了解,该怎么办? 2,书中提到的软件结构,软件设计与实现具体是怎样的?怎么理解它们之间的关系? 3,软件在不断更新和增加功能的负担下,一定程度下会崩溃.若有一个软件,即将考虑添加下一个功能,但是在添加这个功能之后,系统一定会崩溃,但是这个功能对这个软件的市场前景起着至关重要的作用,这是该怎么办? 4,软件设计和软件构建有区别吗?不同之处是什么? 5,当软件中的依赖关系

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着

《构建之法》学习(5)——团队和流程

<构建之法>学习(5)--团队和流程 1.非团队和团队   团队共同的特点: 团队有一致的集体目标,团队要一起完成这目标 团队成员有各自的分工,互相依赖合作,共同完成任务 2.软件团队的模式       一窝蜂模式       主治医师模式 有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作.       明星模式 主治医师模式运用到极点,可以蜕化为明星模式,在这里,明星的光芒盖过了团队其他人的总和.       社区模式 社区由很多志愿者参与,每个人参与自己