构建之法1、2、16章观后有感

第一章 概论

问题一:如何看待软件团队或者企业谋利的的商业模式?

教材内容:第一章概论中关于企业商业模式的论述 P3、P4

思考:其实我觉得对于一些软件企业来说,商业模式的选择,往往不是用户能够去改变和影响的,毕竟用户是站在自己的立场上去看待问题的,而企业的眼光会更加的长远。因为没有什么特定的法律法规,所有对于一些企业的软件绑定、或是广告绑定什么的,往往我们也是无可厚非的。就拿我经常用的WINRAR解压软件来说,本身是一款特别好的软件,但是最让人诟病的一点就是,每次打开他,总会弹出一页广告,虽然只是这一处地方有广告,但是也的确实很影响用户的体验。当然和迅雷的广告数量还是没法比,而且迅雷手机APP里面的广告还特别容易点进去,一不小心就下载了什么什么软件,而且中途还没办法停止下载。但是你又不得不用迅雷,这或许就是一家独大的自信力吧!

当然上面两例只是说明部分企业的商业模式合理性有待商榷。一些别的企业还是非常非常人性化的,就拿现在很受编程人员欢迎的java开发工具,JetBrains公司的IntelliJ IDEA(简称idea),想要用到专业版的idea,可得花不少钱。一年的使用费大概300美元。当然,为什么说JetBrains公司非常人性化,就是你会发现,他们有一个学生免费使用计划,你可以通过你的学校邮箱去认证,然后免费下载使用。

综上所述,我觉得企业的商业模式需要灵活而变,在不同的情况下,可以适当的改变一些商业策略,一些小改动,可能就会给企业带来很好的口碑。

第二章 个人技术和流程

问题一:简单的项目是否有必要进行单元测试?

教材内容:第二章中关于测试单元代码覆盖率的部分 P25、P27

思考:之前其实一直不太清楚测试单元有什么用,今天看过课本之后,发现作者一直在强调测试单元的重要性,可是我们无论是平时做项目,还是老师讲课,似乎都没有特别的去强调单元测试这部分的重要性,所以我不免对此产生了质疑,单元测试是否真的那么重要?

或许是因为我还不太了解单元测试的好处 ,也可能是我现在所接触的东西都比较浅,还没有涉及到单元测试的这个层次。但是看完书,我觉得或许真的有必要去认真的体会一下单元测试的重要性。

问题二:大学生和工程师的对比?

教材内容:第二章中PSP数据比较 大学生VS工程师 P35

思考:我其实想说的不单单是对于写代码所花时间的比较,而是大学生在学校所学习的东西和工程师在公司学到的东西的区别,这也是我最近一直在思考的问题,因为这个问题其实关系到是考研还是就业的选择。

有人说本科毕业就去找工作,想在公司磨炼,增加自己的工作经验。其实也不能说不对,但是我还是想继续读书,因为我觉得研究生阶段才是真正接触和学习真本领的时候。而且研究生毕业找工作的话,应该会更有竞争力,反正对于我来说是这样的,因为我觉得我拿着我的本科毕业证和不算特别强的专业技能,很难去找到一份中意的岗位。而且我觉得大学期间所学的基础课程也是为了你以后深造而打基础的,所以我觉得我需要接着锤炼。可能有点跑话题了,但是细细想来,大学生做项目,更多的是去学习、探索、研究,而工程师做项目可能会考虑多一些用户的需求和体验等现实的问题。但其实这并不适合拿来比较,因为不同的阶段我们所要学习的东西和关注点是不一样的。

第三章 IT行业的创新

问题一: 创新者和先行者的区别?

教材内容:第十六章迷思之四:创新者都是一马当先 P345

思考:书上面写到“大部分成功的创新者都不是先行者”,并且举了Google的例子,以此证明了什么叫做后来居上。但是我觉得先行者和创新者的关系是,其实先行者是最先发现和思考问题的,但是为什么被后来者反超,究其根本还是因为后来的人才是真正的创新者,他们可以沿着先行者的道路,但却是以一种新的方式。举个例子,先行者发明了一道新的菜肴,让大家尝到了一种新的美味。但是创新者能够将这道菜肴做的更加营养,不仅美味而且健康。所以说,因为先行者,我们的生活方式在改变;而因为创新者,我们才越来越适应这种新的生活方式。

问题二:企业的要想长久发展需要哪些方面的创新?

教材内容:第十六章迷思之七:成功的团队更能创新 P350

思考:教材上面清楚地告诉我们,成功的企业还能创新!但是我觉得成功的企业创新也是有讲究的,企业赖以生存的维持性技术可以适当改进,但是不能直接颠覆,因为这可能直接影响着企业文化和特色。但是建议利用自己的手上的平台和资源进行领域扩展,在新的领域大胆创新,我觉得完全可以成为一个出色的后来居上者。举个例子,大家都知道商务笔记本和游戏本几乎是两个完全不可能和谐的元素,而且在现在的市面上还找不到一款既具备商务本的美观便携,又具备游戏本强悍性能的笔记本。或者说没有一个主流笔记本厂家愿意这样做,其实不难理解,这样其实相当于自杀式创新,想想如果自己做出一款商务游戏兼备的笔记本,那自己家的游戏本和商务本怎么办,销量会不会下降呢?答案是肯定的。但是据说现在国内一家手机厂商在自家的笔记本扩展领域大胆创新,即将打破这一局面,发行一款商务范的游戏本。我觉得这一定会是一个成功的创新,也正好说明了我的观点。

以上问题和观点仅仅是本人看过教材后的所感所想,如有不当之处,欢迎老师批评指正~

原文地址:https://www.cnblogs.com/xdhou/p/8586328.html

时间: 2024-10-17 15:59:24

构建之法1、2、16章观后有感的相关文章

构建之法1,5,17章读后感触

看了构建之法1,5,17章的内容,我对团队有了新认识.在一个团队中,不同成员来自五湖四海,为了一个目标,走到了一起.所以,需要的是全身心的投入.但人资历,成绩,口碑有差别,这就有了好/中/差,三等待遇,所以付出的努力不同,得到的待遇自然而然也就不同. 在我们这次软工中,我们需要一个真团队,高效的团队,来互相提升帮助我们完成这些任务.在这过程中,我们需要负担起身上的责任和要对伙伴负责.这样才能让团队走向成功

构建之法第15,16章

15稳定和发布阶段 在稳定阶段的初期,团队只要决定需要修复哪些缺陷,然后团队成员就会进行必要的设计.实现.测试工作,并签入代码修改.但是,随着项目进展和发布日期的临近,团队还要保证修改方案不会给产品带来负面的影响.这时,还要对修改方案进行会诊,包括以下三个方面: 第一步:开发者提交参加会诊的Bug和修改方案 第二步:会议决定是否同意修改方案 第三步:执行 16IT行业的创新 创新有时候只是一瞬间的想法,如果付诸行动,那么就有可能变成事实.创新并不是指一昧的抛弃前人的思想,进行前无古人的创造,有时

读《构建之法》第四章 、第十七章

第四章    两人合作 通过对于<构建之法>第四章的阅读使我对代码规范 . 代码复审 . 以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:简明 . 易读 . 无二义性,代码书写的形式,变量命名的方法,注释程序如何工作都有详细的介绍,令我受益颇多.代码设计规范不光是程序书写的格式问题,而且牵涉到咸亨需设计 . 模块之间的联系 . 设计模式等方方面面,函数的设计,语句的使用,错误的处理,这些都是我们在进行程序设计的时候需要注意的地方.

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始

构建之法读后感----第1章 绪论

首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理

《构建之法》第十七章读后感

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

《构建之法》第三章学习心得

这周我学习了<构建之法>第三章,讲述了软件工程师的成长.软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下. 1.通过交流.实验.快速原型等方法,理解问题.需求或任务 2.提出多种解决办法并估计工作量 3.其中包括寻找以前的解决方案,因为很多工作是重复性的 与相关角色交流解决问题的提案,决定一个可行的方案 执行,把想法变成实际中能工作的代码,同时验证

阅读《构建之法》第四章感想

课下阅读<构建之法>第四章,自己有以下一些感想. 1.我们写的代码最终都是要给人看的,所以代码规范化是一个优秀编程员必备的良好习惯,而且若是在团队里工作,那么代码规范更加重要.编程人员要遵循的代码风格的原则是:简明,易读,无二义性.以后自己要养成规范代码的习惯. 2.复审也是不可缺少的一个步骤,软件工程中最基本的复审手段就是同伴复审,找熟悉代码,有经验的人来进行复审. 3.当今时代,一个人能发挥的力量越来越小,团队的力量日渐重要,因此,如何合作,很关键.两个人合作,如何影响对方,要因人而异,因

《构建之法》第四章

<构建之法>第四章讲的是两个人的合作.结对编程.结对编程往往只需花费大约一半的时间就能编写出质量更高的代码. 代码规范方面,在给函数或者类取名的时候要严谨,不能写一些没意义的名称:在一些代码后面可以加些注释来说明此行代码的作用,在复审方面,我觉得自我复审时最好的,刚写好的代码脑袋里印象深刻,能很好的解决逻辑错误和算法错误. 结对编程方面,书中生动形象的说明了开发者的搭档关系,在结对的时候怎么分配任务,怎么通力合作.互相帮助,在两人的合作过程中,怎么磨合.互相提高水平,在遇到问题或者矛盾的时候,