《构建之法》 第一次作业
《构建之法》 第一次作业
| 这个作业属于哪个课程 | 构建之法|
| – – – – | – – – – |
| 这个作业要求在哪里 | 作业要求 |
| 我在这个课程的目标是 | 学习以工程方式开发软件的方法,掌握软件开发步骤和流程 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过对书本的初步了解对软件工程有更多的认知,对自己有一个更明晰的方向的目标 |
| 个人博客主页 |个人博客|
1. 自我介绍
这是我人生中第一篇博客,虽然以前就有写博客的想法,但觉得写起来好复杂的样子而且又会浪费太多时间,但在尝试写这篇博客的时候感觉也还行,没有想象的那么麻烦。在未知的领域怕麻烦,作为一个程序员这是我的致命缺点。现在已经晋升为大三的软工学生,回顾前两年,在大一,我加入的学校的计算机团队,这让我还算有一个比较的基础,看到别人在开始学习应用层的知识的时候,我开始想我的目标是什么?听的最多的是学java后端,大一下期我就觉得学java试试看,虽然学起来没什么难度,但我感觉对这也没多大兴趣,因此并不想继续学下去,在大二的时候我学完web还没学框架的时候,感觉已经不感兴趣了,所以我觉得我应该学我感兴趣的,不然以后工作得有多枯燥。刚好安卓开发我还算比较感兴趣,因此我又学了大半学期的安卓开发,但团队没有人做安卓的,所以在带完新大一基础之后我退出了团队。在大二假期的时候因为一些事情中断了安卓的学习,空闲的时候经常在博客网站逛逛,这时我对计算机行业又有了不一样的认识,我对以后的工作更向往是应用一些新兴技术,因此我放下了app开发的学习,开始了解python、大数据、人工智能这些近年热门的话题和技术,最后我决定学习大数据技术,刚好有java基础,又有python的应用。现在我感觉自己学过挺多的的东西,虽然只是皮毛,但也学到很多不一样的思路想法,感觉浪费了很多时间,但也收获也颇多,至少感觉我学其他语言和使用新的工具都适应得很快。还有一年时间,不多也不算少,愿一年以后我能有不一样的收获。
2. 阅读与思考
(1)回想一下你初入大学时对你所在专业的畅想
初入大学时,我对软件工程这个专业学什么表示一脸茫然,虽然大一也有职业规划课程,但对未来的方向仍然没有比较清晰的路线,只知道我们是做软件的。在学习完一年以后我对学校的专业课程并不满足,感觉老师讲的太慢,因此已经有不依靠学校课程学习的想法了,反而是在网络上学的更多些。对我们这个行业,我感觉我并不是那种特别的热爱,我看到许多同学天天在实验室敲代码学学学,或许他们都有去PAT、阿里的梦想,但我没有,或许是家庭的耳濡目染,我对物质的追求没有那么强烈和对未来方向的迷茫,因此没有像他们这样强度学习的动力。但未来我应该仍然是做软件行业。工作地方的话,我非常希望能留在成都工作,对以后的工作我更对爬虫、数据挖掘、网络安全比较感兴趣,所以以后做大数据相关工作的可能性比较大,对公司虽没有阿里梦但也希望像他们靠齐。
(2)对照前人们走过的路和描述未来发展,现在的你
对比前人,我感觉我的算法需要再复习一下,技术上还不敢说对什么技术很擅长,学的东西太杂,现在还主要是java web了解比较多,做过最复杂的项目或许只是上次暑假写的酒店订购辅助系统,一个周不到了解完SSM框架,一个周敲完代码,只是任务我没有分配好导致代码百分之七八十都是我一个人写的。难度不大,就是时间紧技术了解浅。代码量的话应该七八千是有的吧,都是偶尔做些小项目不好估计。我认为我离一个合格的本科生在计算机系统和网络方面知识储备还不够,对一个方向的专业技术还有待提高。
(3)目前是一个人生选择的十字路口,考研、工作、考公、出国,不同的选择在大三就有不同的努力方向。而无论考研还是工作的每条路径,也有许多不同的分支。
大学毕业直接工作这是我进大学就已经决定好了的,因此在大三我已经做好了对某一方向深度学习的准备,同时课堂上学习计算机系统的知识和网络知识,在软件工程课上认真学习软件开发流程,积极参与团队合作编程中,提前了解工作时的任务安排的软件开发流程。相比较考研的同学,提前进入社会工作,对当下的新技术肯定有更好的了解和更多的学习的机会,但同样几年后,他们相对我来说文凭要高一点,但我并不认为他们大多数的能力能有我强。两年下来,我发现我自学能力相比较大多数学生来说是比较强的。因此我们提前进入公司学习能快速积累工作经验,如果发现学习的技术或者干的岗位不合适我,我还有时间和机会换工作,但读研出来,基本上方向应该是比较确定的,但实际的工作效果和工作预想并不一定是自己想象的那样,那么换岗位的损失太大了,而且程序员在一些方向上是吃青春饭的,并没有那么多时间去耽误。所以我选择早点工作适应环境早点进入工作状态。
3. 提出有质量的问题
1.在第三章《软件工程的成长》中
3.3中关于专和精的讨论。有人说一个人就可以快速成长一名全栈工程师,这让我想起街头卖艺的单人乐队,他们什么都会一些,可以很快的演奏一些曲子。与之对立的,是只研习某一乐器的乐手,你愿意花钱听哪种演奏呢?
我对这个讨论也感到疑惑:因为我认为在懂更多技术的人会有两方面优势,一是在团队开发中如果能了解更多方面的技能,那将减少技术人员的沟通成本。其二,了解更多技能也会在未来也有更多的选择机会。但如果专攻一门技术,意味着会将更多时间放在一个方向上,但与人沟通成本较高,知识面狭窄,所以怎样调节专与广的平衡依然比较迷惑。
2.在第四章《两人合作》中
在4.7的讨论中有提到,“人和人不一样,……MBTI类型,讨论不同性格类型对合作有多大的影响,在合作的各个阶段应如何应对?”也就是说团队成员的性格可能会影响团队合作项目的质量,我也认为性格不同的人在做事风格和对待问题的态度都有较大的区别,那么是否应在成立团队前做MBTI测试从而更好的组合成一个团队
3.在第五章《团队和流程》中
在阅读5.2时,认识到很多经典的“软件过程模型”,比如“瀑布模型”、“统一流程 ”、老师上课也讲了增量模型等,但这些开发流程中都使用到了开发文档,也就是都是用文档驱动,很考验文档的表达能力,我认为这在软件开发的过程中显的比较繁琐,是否有一些更优的解决办法,或其他的没那么侧重文档的软件工程模型呢?
4.在第十章《典型用户和场景》中
在10.3.3中提到工程师的设计师如何体现下列原则的:程序模块对应运行环境、相关模块、输入输出参数有什么假设?这些假设验证过么?这在上次暑假的做项目的时候我就在考虑这个问题,当对输入输出参数的假设与真实数据有误差的时候该怎么调整?加入调整代码或许就要动很多的代码。如何有效避免假设数据与正式运行的数据不相容问题。
5.在第十三章《软件测试》中
在13.3.2讨论测试用例这里,书上说道一个软件有很多可能的输入和环境参数,我们没有能力穷举所有的可能,也没有必要。这里只介绍了等价类划分,边界值分析,决策表、因果表和功能图方法等方法,只提到了部分方法并没有说明怎样才算是符合有效测试用例这个标准。
4. 源程序版本管理工具
Git
优点:
- 适合分布式开发,强调个体
- 速度快、灵活、个人体验好。
- 任意两个开发者之间容易解决冲突
- 离线工作,项目不需要保存在本地或者服务器
缺点:
- 资料少(起码中文资料很少)。
- 学习周期相对较长,上手需要时间
- 代码保密性较差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
SVN
优点:
- 对目录的组织的管理更加方便。
- SVN不光对文件做版本跟踪,也会对目录做版本跟踪。
- 可以保证提交操作的完整性。SVN对提交操作的处理方式类似数据库的事务处理,要么全部成功,要么全部无效,保证了原子性。
- SVN允许一个文件有任意多的可命名属性,功能十分完全。
缺点:
- 不能离线工作。所有的版本信息都放在服务器上。离开网络就不能工作。
- 提交、更新的速度慢。代码不能及时提交。强迫使用者即时处理冲突,然后才能提交。
- 需手动“cleanup”。
Microsoft TFS
优点:
- 任务版上能将需求、项目进度一览无余,对于小团队而言,比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
- 能有效实现 SCRUM能与 VS 无缝接合。
缺点:
- 搭建、维护tfs比较复杂,硬件要求也比较高。
- 整个系统是用 asp 实现的,用浏览器访问相当慢。