码迷,mamicode.com
首页 > 其他好文 > 详细

老师的问题和《构建之法》笔记

时间:2017-09-17 13:37:00      阅读:137      评论:0      收藏:0      [点我收藏+]

标签:行业   linux   line   项目   用户体验设计   兴趣   网页   工作流程   难度   

谈构建之法之前,先回答老师的几个问题~

  1.我本科专业是物联网工程,四年间的学习内容一直处于软硬件间摇摆,一度使我怀疑人生。这种学习方式最大的好处是可以从底层理解整个计算机的运作,循序渐进,而最大的缺点是,体系太过于庞大,低效,冗杂。当我到了大三的时候,我依然不能够独立编写一些软件,也不能处理有意义的硬件问题,所以当务之急便是做出取舍,否则我的大学可能就止步于C语言和单片机了。几经周折,最后还是选定了偏向软件的方向,原因众多,硬件的学习难度和深度让我苦不堪言,对数模电,通信原理,高频电路亦有较高要求,而周边同学也大多偏软,大环境下,软件是占有优势的,所以最终还是选择了偏向软件的计算机专业读研。自认为本人资质普通,但对生活兴趣高涨,有生之年如若再有机会,还是愿意将丢掉的硬件知识再次捡起,毕竟当年学的很痛苦...

  2.在做出一个大方向的转折之后(选择偏向软件方面),问题依然重重,一个具体的专业是很重要的。计算机发展史虽短,但也体系庞大,门类众多。兴趣任然是生活的导向,本科实习期间有过一个Unity的小的项目,让我对图像,游戏方面有兴趣,最后读研也是选择了图形图像方面。至于擅不擅长计算机领域,怎么说呢,我学了四年物联网,也算是计算机相关吧,加上平日的一些积累,相比于其他的技能,应该是蛮擅长的吧...

  3.对一名合格的计算机专业的硕士研究生,我们的培养方案里是这样说的:

技术分享

关于差距,我自己的看法是,在专业知识方面不够深入,目前还不具备独立从事计算机应用工程的开发能力,对专业前沿的信息不够清楚,外语能力也需提高。相信通过三年的学习情况会大为改善。

  4.初来不久,同学们卧虎藏龙,我对他们还是不够十分的了解。只能谈谈我的自以为是,我本科期间我还算兴趣广泛,学习过C/C++,写过几个小的项目,用Unity做过简陋的游戏,了解一点C#,写过静态网页HTML/css,了解一点js,但没有用过,毕设开发一个APP,所以懂点Java和Android,用Python写过内涵网的爬虫,看过鸟哥的Linux私房菜,能简单操作Linux系统,能在Linux在进行简单的网络编程,和多线程/进程编程。若日后能用到这技能,那可能也是我的一点小小优势,然而劣势是,我会的都不太深入,与有深入学习的同学相比,我可能还没有入门。。。

  5.三年规划:学习所需课程;完成一些项目,延伸学习项目中的一些技术;多读一些前沿论文,发表论文,顺利毕业;找个实习,毕业后找到个回报好点的工作。。。

 

 

以上信息纯手打(图片除外),真实可靠,人艰不拆,不喜勿喷,谢谢!

 

 

《构建之法》笔记

  诚实守信是科学严谨和求真务实,这书我没全部看完。

  从简单的编写一段代码,到一个软件工程,隔着一本《构建之法》。软件工程的目标是创建“足够好”的软件,在开发流程中又有5点特别的难题:复杂性,不可见性,易变性,服从性,非连续性。

    复杂性:现代软件的规模都非常巨大,动辄超百万行代码,上万个文件,用以满足大规模用户的不同的复杂的要求和良好的用户体验。软件的各个模块之间有各种显性或隐性的依赖关系,随着系统成长和模块的增多,这些关系的数量往往以几何级数的速度增长,而理解这些复杂性的人却没有太大变化。软件团队的成员每天都在修改各种源码,在维护软件修改过程中维持和提高质量是一个很大的挑战,需要高效的源码管理和软件测试。

    不可见性:软件以机器码的形式在计算机上运行,还可能在多核上运行,工程师是根本无法看到自己的源码是如何被执行的,一旦出现错误,只能看到出错的一瞬间留下的蛛丝马迹(错误代号,目标代码的大致位置,错误信息等),几乎无法完整重现程序的错误。

    易变性:软件的更新迭代速度也在随着用户需要快速改变而进行,同事软件还要适应新的硬件基础,正确的修改软件也十分的困难。

    服从性:软件并不独立,它必须服从于系统,硬件,用户甚至行业要求。

    非连续性:人们比较容易接受连续性系统,增加输入,就能看到相应的输出增加。但要保持这样的特性越来越困难,大多时候,输入上很小的变化,就会引起输出上极大的变化。

  在个人开发中,必须要遵循一定的流程来管理开发活动,这也是软件工程师在软件生命周期所做的工作流程。软件是由各种模块组成的,各个模块之间需要定义尽量明确,模块内部的改变不会影响其他的模块。单元测试是这些模块的质量稳定的,量化的保证。单元测试是指对软件中最小的可测试单元进行测试和检查,在最基本的功能上验证程序的正确性。好的单元测试标准为:由程序作者来编写测试代码;测试过后,机器状态保持不变;测试过程要快;测试结果为一致的,可重复的;保持独立性;测试覆盖所有代码路径。在单元测试的基础上,就能够建立这一模块的回归测试。当模块在构建一个新的功能时,有时会出现从稳定状态到不正常工作的“退步”,在一个模块功能完善的同时,与此的测试用例也在完善。而一个模块的单元测试便是这个模块最初的基准线(Baseline)。例如模块A的123测试用例通过了,打在新的版本中,改测试用例失败了,这便是一个“退步”,工程师们应该在新版本上测试所有已通过用例,验证是否“退步”。这个过程便是回归测试。然后便是软件的效能分析,以使自己的程序更加的高效。在效能分析中,通常采用抽样和代码注入来检测和分析代码在运行中的各项参数(运行时间,运行次数,内存开销等),对代码进行优化。
  在多人合作中,代码的规范变得很重要,在开发的初期,便要代码风格,设计规范做出详细讨论,最后还需代码复审来增强程序的鲁棒性。在开发流程中我推荐也是普遍采用的敏捷流程,敏捷流程的开发原则是:

    尽早持续的交付有价值的软件满足客户需求

    欢迎需求变化,以此调高竞争力

    经常发布可用的软件

    业务人员和开发人员共同工作

    项目核心为有进取心的人

    面对面交流

  步骤为:找出产品的当下所需,冲刺所需解决的问题,然后冲刺,最后得出软件的一个增量版本。

  一款真正的软件,要经历需求分析,确定项目经理,确定典型用户和场景,软件设计与实现,用户体验设计,然后通过软件测试进行质量保证,直到稳定然后发布。这一整套的流程当需依据确定的项目来进行设计和调整。而这些思路正是《构建之法》教给我们的。

老师的问题和《构建之法》笔记

标签:行业   linux   line   项目   用户体验设计   兴趣   网页   工作流程   难度   

原文地址:http://www.cnblogs.com/howkewayne/p/Construction-method.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!