构建之法 02

第一章:打开第一章时,我想到的是:什么是软件和软件工程是什么,在阅读中让我感到很困惑,但经过仔细阅读之后我大概地了解,最后我还不太明白的是怎样才能做更好的软件?

在读此书之前,我一直以为当一个团队确定了负责一个项目之后,他们的成员不会再有所修改,会对所负责的项目负责到底。但实际上,软件团队是会流动的。为什么要有人员的流动呢?是出现了现有团队解决不了的技术困难,需要新技术新知识的支持,还是现有团队身担多职,需要人手帮忙?另外,不止是软件程序会有bug,团队也会有bug。处理好bug是创造“足够好”的软件的基础,但在校园学习过程中,我们常常会忽视bug,甚至把它留在最后处理。用户体验,很多时候我们会在软件商店下载各种功能相似的应用,比如,我们曾经下载过无数个背英语单词的app,而能留到最后的只有“百词斩”。软件的用户体验的好坏就在于他是否与同类型的软件比起来更好用。用户体验对一款软件的考验很大,市场上也有许多新开发的软件,这些软件有的一夜之间下载量飙升,有的却不了了之,也有的在一段时间内飙升后再被淘汰。比如像素鸟,前段时间很风靡,现在也逐渐退去光环。我觉得这也和用户体验有密切相关的关系,作为一款游戏,前一段时间因为游戏有难度而风靡,而后来听说有些大神通了关,但我相信大部分人都是没过几根柱子就game over了的。这样没有奖励又屡战屡败的游戏,用户大概也不太想要坚持玩下去。但游戏的有创意又容易上手,就是太容易game over。

百度百科解析:API(Application Programming Interface,应用程序编程接口)是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。

时间: 2024-10-10 21:41:16

构建之法 02的相关文章

《构建之法阅读笔记02》

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

构建之法阅读笔记(02)

这一周,通过对构建之法的阅读,对软件以及软件开发有了更加深的体会,一个好的软件工程师,首先要学会与别人合作,要能够包容别人的过失,同时能够发挥自己的长处,个人单枪匹马开发软件,已经很少见了.一个好的软件工程师,要有好的编程习惯,代码的风格与规范,缩进,行宽,以及变量的命名,大小写,能使代码结构清晰,看起来好看,并且简明易读,同时也要有注释,可以让阅读代码的人能够读懂. 在好的编程开发人员,也有犯错的时候,这时候进行代码复审就显得尤为重要,一方面可以学习编程思路,另一方面也能够及时检查出错误,学习

《构建之法》读后感02

通过阅读这一章的构建之法,让我感受最深的一个道理就是一个真正的软件是由多人完成的.虽然个人能力非常重要,但是团队之间的配合却是更为重要.而我们现在最缺少的就是这种团队之间的沟通交流.因为我们从小学开始被教育的就是要独立完成作业,大多数老师更为关注的也是个人能力,所以团队之间的沟通交流也被老师们给忽略.但是在我们进入公司时,必然免不了与其他人的沟通,所以在我们刚进入公司时都会有一些不适应,这对我们来说可以说是一种缺陷.软件是有多人完成的,不同人员的工作互相有依赖关系.所以要能配合好就要学会使用单元

阅读《构建之法》P384~391

通过阅读<构建之法>P384~391以及参考阅读杜老师给出的链接,得出一个重要的结论:软件工程师的职业道德至关重要. 软件工程的动态性和需求的前后关系,要求一个规范能对出现的新情形有较强的适应性和适用性.但是即使在这种一般性原则下,本规范也只对那些以文档记录职业道德态度并采取积极行动的软件工程师提供支持:即提供相应开发组中的个人以及整个开发组都可以求助的道德基础.本规范也帮助定义哪些是对软件工程师提出的道德上不适当的要求. 原则1  公众 软件工程师的行为应与公众的利益一致. 原则2  客户与

构建之法1、2、16章阅读感想

这本书可以说是我进入大学以来读过的最容易理解的一本有关于软件工程的书,语言平易近人容易理解,让我对软件工程在原有基础上有了翻新的认识,让我重识认识了软件工程"知行合一"的思想,加深了我对软件工程行业整体的理解.阅读的同时,我也产生了一些疑惑,以下是我在学习过第一.二.十六章后提出的一些问题和我的思考! 第一章:概论 问题:在软件工程发展的短短几十年中,人们整理了许多原则和规律,有些是比喻,例如"大教堂和集市",描述了两种大规模团队构建产品的方法,这种比喻让读者有各种

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

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

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

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

构建之法阅读笔记05

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

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

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