我的第一次博客作业-阅读《构建之法》所思所想

这个作业属于哪个课程 <课程的链接>
这个作业要求在哪里 <作业要求的链接>
我在这个课程的目标是 提高自己的代码编写能力;能够将软件工程理论化的思想运用到实际的代码编写中
这个作业在哪个具体方面帮助我实现目标 系统地阅读了一本关于软件工程思想的书籍;在学习过程中学会更多融入自己的思考

一、自我介绍

西南石油大学软件工程卓越班唐金玉;我的博客地址https://www.cnblogs.com/sparrowchengyu/

简单的自我介绍:作为一名学习计算机的女生,首先我感觉自己的逻辑能力不是特别强,一直很想通过各种方式来提升自己的逻辑能力(希望读到这篇博客,也有过同样困扰的朋友能在留言中和我分享一些经验和方法)。我的个人爱好呢,首先比较喜欢读书(喜欢当年明月写的《明朝那些事》),然后呢,我觉得自己的记忆力还行,但我觉得这也不是什么优点吧,因为我感觉只要愿意花时间,记忆的东西人人都可以很好的呢。

扫描二维码关注公众号,回复: 7260933 查看本文章

二、阅读与思考

(1)回想一下你初入大学时对你所在专业的畅想

  • 当初你是如何做出选择你所在专业的决定的?

其实我是首先选择的学校,本来想选一个不是工科的专业,但是分数不够,软件工程呢其实我当初也并不了解(最初也还算一个电脑小白,就是感觉这个专业名字听起来就很高级吧),所以这个专业算是在很懵懂的情况下作的选择了。

  • 你认为过去一(两)年中接触到的课程是否符合你对你自己所在专业的期待,为什么?

说实话因为对软件工程这个专业在选择的时候并不了解,所以我可能并不像有目标的选择这个专业的同学那样有很多的期待。但是在大一大二两年的学习过程中,我也有一些思考和困惑:比如我们是软件工程专业,但是在过去两年,我们学习的《C语言程序设计》、《数据结构》、《离散数学》等课程好像都不属于我们专业特有的课程,但是现在我也渐渐的明白了这些课程的重要性。就好像修建一幢高楼,外人关注的可能是眼睛能够看见的,比如大楼的外形设计好不好看等;而工匠更关注的是每一块砖石是否契合。我认为我们过去学习的这些课程就是那些砖石,是不可或缺的。

  • 你觉得你所在的专业是你喜欢的领域吗,它是你擅长的领域吗?

在我的认知里,要擅长某种东西,才会更加喜欢它吧。真实的情况是我感觉自己真的不擅长,有时候代码是真的写得很头疼,就是没有办法理解它的逻辑。但是我会不断试着让自己喜欢上它,因为只有更喜欢才能更有动力去学习。(自己选择的路,再难也要走完吧。)

  • 将来你会选择从事和你专业相关的工作吗?是的话给出你想去的城市、公司和岗位,否的话给出原因

我还是很希望从事专业相关的工作的,但我不确定自己是否真的能够将这个专业学得很好,但我会一直努力的。如果可以的话,我希望可以在上海工作,至于公司,现在技术太菜,都不敢想;至于岗位,可能会更喜欢软件设计方面的岗位吧。

(2)对照前人们走过的路和描述未来发展,现在的你

  • 自我感觉你已经具备的专业知识、技能、能力有哪些?已经写过的代码量是多少?描述你做的最复杂的项目/作业。

专业知识,过去两年学习了C语言、C#以及设计网页的html/css;至于代码量,真的不多,也没有系统地统计过,但我觉得真的是不够;最复杂的项目作业,今年暑假学习的JavaWeb吧,但是我负责的也只是界面设计的部分,底层的东西我还是有点吃力,难以上手。

  • 离成为一个合格的本科毕业生,在专业知识、技能、能力上还差距哪些?

感觉自己距离成为一个合格的本科毕业生还有很长的一段路程。首先专业知识是不够的,代码量也远远不足,独立思考的能力也不强。我会努力让自己一步步成长的。

(3)目前是一个人生选择的十字路口,考研、工作、考公、出国,不同的选择在大三就有不同的努力方向。而无论考研还是工作的每条路径,也有许多不同的分支。

  • 对照以上你阅读的前人们的经历,你的选择是什么?
  • 在这种选择下,你认为你相比其他同学来说有何优势,有何劣势?

我应该会选择考研,相比于更早地工作,我还是想多读一点书。优势的话,晚一点进入职场,能够多一段潜心学习技术的时间吧;劣势的话,就是实战经验不多吧。其实在我看来,并不是说哪一条路就是更好的选择,适合自己的就是最好的吧,我认为考研比较适合我目前的情况,我也会为做的这个选择付出自己的全部努力。

  • 针对你的选择,你给自己的大三设定的规划安排是什么?

至于大三的规划与安排,大三上学期专业课还比较多,我打算好好学习每一门课程,抓住时间提升自己的编程能力;大三下学期就好好复习准备考研,争取考上自己心仪的学校。

  • 你对于实现自己的梦想已经做了或者计划做什么样的准备?

我已经做好了迎接繁忙而充实的学习的准备了。在阅读了辜新星的《时刻调整方向 找到人生的蓝海》后,我觉得他在文章中所提到的每天对自己的事情规划的方法十分有用:“要把每天把要做的事情分成A、B、C、D四类: 

A——紧迫且重要;B——重要不紧迫;C——紧迫不重要;D——不重要不紧迫。”在今后的学习中,我也打算将自己每天的任务做一个划分,这样可以让自己完成事情更有效率,而不是一味拖延。

 


三、阅读《构建之法》后我的问题

 问题1:第三章:3.4节“技能的反面”

原文:  那什么才是“技能”呢?技能的反面是什么?技能的反面是“problem solving”---“解决问题”

疑问:  真的可以完全将解决问题定义为技能的反面吗?这样的说法是否太过绝对?

我的理解:文中作者通过魔方的例子做了阐述,还将问题分成了舒适区、学习区和恐慌区三个层次,以此提供给读者提升技能的方法。但我有不同的看法,我认为解决问题的过程也算是一种技能,在解决问题的过程中,我们需要分析、比较、贯通,所以我认为并不能绝对认为它是技能的反面,只是说,我们在解决问题的过程中要运用合适的技能。

问题2:第五章:5.2节“软件团队的模式”

原文:  一窝蜂模式可能是一个欢乐而随意的模式,但这是一个好的团队形式么?当然不是。

疑问:  一窝蜂模式也会经历成长,就此否定是否太苛刻?

我的理解:首先“一窝蜂模式”可能是很多团队最初的模样,不可能有哪一个团队大家聚在一起就不必契合,都需要经历一个互相磨合的过程,所以我认为并不能就此否定它。一窝蜂模式往积极的方向发展,最终也能成为分工明确、积极合作的团队形式。

问题3:第八章:8.3节“获取用户需求-用户调研”

原文:   这一调研方式要求用户记录自己日常工作生活中与所用软件相关的行为,供软件团队分析。

疑问:   此处所提到的“用户日志研究”这种方式是否不太实际。

我的理解:我查询了一些与日志研究相关的资料:“日志研究是一种收集用户行为、活动和体验的定性研究方法。日志研究需要研究的参与者在一段很长的时间段内(几天、一个月甚至更长)进行自我报告。在这段时间内,研究参与者被要求保留日记并记录有关正在研究的活动的具体信息。为了帮助参与者能记得去写他们的日记,有时会定期提示他们(例如,通过每天定时的通知或在白天一些的特定时间通知他们)。”可以看到,虽说日志研究可以很好记录用户行为活动,但是需要投入大量的时间精力和人力,而且按照如今的现状来看,繁忙的工作生活下,应该没有太多人愿意花费来填表记录,在我看来,普通用户对于某种软件产品的态度就是不好用换一款就好了,所以此方法并不实际。

问题4:第九章:9.4节 “领导力---高效的团队讨论”

原文:   很多人认为“创意”是一种天生的才能,或者需要大智慧才可有创意,其实不然。创意是一种可以后天获得并不断提高的技能。

疑问:   要通过怎样的后天努力才能获得此技能呢?

我的理解:通过查询相关资料,对创意的解释是“创意是创造意识或创新意识的简称,亦作“剙意”。它是指对现实存在事物的理解以及认知,所衍生出的一种新的抽象思维和行为潜能。”在我的认知里,好的创意需要有好奇心以及善于发现与思考的能力,还需要能提出新的有想法的点子,如今科技的迅速发展使得新的思想能够快速传播,感觉后天获得还能不断提高真的很难。

问题5:第十六章:16.1节“创新的迷思”

原文:  谁不喜欢创新呢?然而细细想来,创新就是做和以前不一样的事,并不是所有的人都喜欢“不一样”。不但大众不喜欢创新,甚至连创新者自己都不例外,有些创新者甚至恨创新。

疑问:  大众不喜欢创新或者创新有反对的声音,是否并不是创新本身的问题,而是创新的事物还存在瑕疵?

我的理解:我承认大众对创新的接受度需要一定的时期,但是我认为不是创新本身的问题。马云的电商最初也是一种创新,很多反对、质疑的声音,但是当它发展成熟,真的给人们带来了便利,我们还会坚持最初的否定吗?我认为不会,只是人们会关注自己的利益是否受损,创新的事物对原有的事物冲击太大,也就出现了反对、怨怼。


四、源代码管理工具

1.Git

 优点:

        i.  适合分布式开发,强调个体

        ii. 公共服务器压力和数据量都不会太大

        iii.速度快、灵活

        iv.任意两个开发者之间可以很容易的解决冲突。

        v. 离线工作。

缺点:

        i.  资料少(起码中文资料很少)

        ii. 学习周期相对而言比较长

        iii.不符合常规思维

        iv.代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息

(参考链接:https://www.cnblogs.com/bgwhite/p/9403233.html)

2.GitHub

优点:

       i.   适合分布式开发,强调个体

       ii.  公共的服务器压力和数量都不会太大

       iii. 速度快, 成熟的架构,开发灵活

       iv. 任意两个开发者之间可以很容易的解决冲突

       v.  离线工作,管理代码成本低,不需要依赖服务器

       vi. 部署方便。基本上下个命令就可以用

       vii.良好的分支机制,可以让主干代码保持干净

       viii.对程序源代码进行差异化的版本管理,代码库占极少的空间,易于代码的分支化管理
缺点:

       i.  资料少,学习成本比较大,学习周期比较长,要求人员素质比较高

       ii. 不符合常规思维

       iii.代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息

       iv.不支持中文,图形界面支持差,使用难度大,不易推广

(参考链接:https://blog.csdn.net/weixin_40783315/article/details/84981875)

3.Microsoft TFS

 

优点:

       i.  任务版上能将需求、项目进度一览无余

       ii. 对于小团队而言,比甘特图更有用

       iii.集成了项目管理、版本控制、BUG 跟踪,能有效实现 SCRUM,能与 VS 无缝接合

缺点:

        搭建、维护tfs比较复杂,硬件要求也比较高

(参考链接:https://www.cnblogs.com/yuyue1216/p/5281544.html)

4.Trac

优点:

       i.   Trac做一个SCM配置管理平台,意味着它有良好的扩充性

       ii.  Trac的权限体系是比较完备的设计

       iii. 非常灵活,可以随心所欲的定制,可以和TortoiseSVN集成

缺点:

       i.   不支持多项目

       ii.  需求和缺陷没有分离

       iii. 用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了

       iv. 中文化不完整,美术人员接触起来困难重重

       v.  不显示中文名,本地化做得很差

       vi. 核心功能很少,不安装插件基本上没法用

(参考链接:https://www.cnblogs.com/yuyue1216/p/5281544.html)


 五、一些收获

这是第一次写博客,但感觉还不错,就是需要花很多时间。我认为写博客的过程就是将自己脑中零散的东西变得更有条理。当然这也是一个向他人学习的过程,通过他人的故事,寻找自己在学习中与之相似的困惑,找到适合自己的解决问题的方法。我很喜欢阅读材料里刘帅所说的在失望中寻找希望,王小波也说过:“生活就是一个不断受锤的过程”,这跟学习的过程很贴切,会有迷茫、困惑、失望的阶段,但是要在失望中寻找希望,受锤后站起来继续向前。我希望自己能够像那些优秀的人一样,一路前行。毕竟宇宙山河浪漫,生活点滴温暖,都值得前进。

猜你喜欢

转载自www.cnblogs.com/sparrowchengyu/p/11486973.html