构建之法 04

第三章:阅读到这章,让我学到了软件工程师的成长的历程,软件工程师在各阶段的能力,同时让我感到很困惑的是怎样才能让自已成为一个好的软件工程师?

那么,我们为什么要用软件工程呢?因为软件工程把开发,运营,维护的过程中的技术,做法,习惯和思想结合到一起(软件开发流程)提高了软件开发,运营,维护的效率。同时,运用软件工程,也减轻了我们的工作量,避免不必要的返工。

怎么提高技能?通过不断的努力,把那些低层次的问题都解决了,变成不用经过大脑的自动操作,然后才有时间和脑力来解决较高层次的问题。我们要精通低层次问题(int[] arr还是int arr[],ArrayList 还是 Array<T>),中层次问题(使用何种架构),高层次问题(效能优化。。。。。。).在学校,我们需要学的知识,语言太多了。往往给我们一种杂而不精的感觉,但是平时在校期间几乎是没有多余的时间去将所学知识学精的。这个时候,我们该怎么办?坐等毕业之后就职公司给我们培训吗?我觉得,参加比赛是对付学而不精的好方法,比赛会让你控制好你的每分每秒,也可以以比赛的形式逼着自己去学一些东西,若是得了奖,可以丰富简历,若是没得奖,那我们也从中学到了很多。重在参与。像书上52页所描述。我们在平时的作业里,很多都是通过上网找资料得来的。因为有上网这个“东西”,我们也没有体会到要去记牢一些最基本的事情。所以此后,我们也养成了习惯,一碰到不会的,马上百度,却从来不记住。当下次再遇到同样的问题时,我们可能还会再一次向百度伸出请求援助之手。此时,我也意识到问题的严重性了。某些低级的问题确实不值得我们一而再再而三地百度,这些最基本的东西本就该稳稳地沉淀在脑海里面,可以不经大脑就自然一气呵成。

时间: 2024-07-29 23:22:20

构建之法 04的相关文章

构建之法04

阅读了构建之法第十.十一.十二章的内容后,了解到了典型用户(Persona)和场景(Scenario).软件设计与实现.用户体验等内容. 第十章主要告诉我们典型用户的分析及场景分析.在开始写程序之前我们要和典型用户的代表交流,理解用户,理解他们的工作方式和需要.然后再修改,细化典型用户.典型用户会强迫我们在考虑问题时从用户的角度出发.只有把自己置身于用户的角度,才能发现程序的不足与需要改进的地方.典型用户和典型场景.大概就是非专业的程序员.专业的程序员.项目经理这三种人吧!典型用户很大的作用就是

《构建之法》阅读笔记04

今天,我阅读了构建之法10-12章.总结出了自己以前一些不对的思想和做法. 以前认为对软件需求最大的人肯定就是我们的典型用户了呀.于是就可以为这些人打造一款软件就等于软件成功了.可是大多数时候我们软件已做完发现这些人根本不用我们的软件.为什么呢?因为不会用.所以我们定义典型用户的时候首要条件就是会用这款软件,然后和需求有关系的用户. 以前认为工程师做软件就是先把要做的任务分分类,然后大家把自己的任务文成,最后链接起来就可以了,可是这样做出来的软件真的解决了需求了吗?软件设计是首先要把需求先搞清楚

《构建之法阅读笔记04》

构建之法的一核心就是“做中学”,所以在上次做软件需求分析后,我学习了软件需求分析这一章节内容.竞争性需求分析的框架 1.N(Need,需求)我们开发软件时为人服务,因此很大一定程度上,我们必须了解客户需求和市场需求,找到该产品的市场前景和需求人群如果,前景渺茫的话,项目产品就没有意义.因此需求是最重要的. 2.A(Approach,做法)这是我们与其他相似软件的独特之处,可以使我们的软件更加突出,用这个独特的招数来解决用户的痛苦,这不仅是技术上的,也可以是商业模式上的,人脉方面的,行业方面的或者

阅读《构建之法》P384~391

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

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

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

《构建之法阅读笔记02》

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

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

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

构建之法阅读笔记05

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

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

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