2021S软件工程——个人阅读作业2

2021S软件工程——个人阅读作业2

项目 内容
这个作业属于哪个课程 2021春季软件工程(罗杰 任建)
这个作业的要求在哪里 个人阅读作业#2
我在这个课程的目标是 了解并熟悉软件开发的具体流程,与团队共同开发一款实用的软件。在实践中增强自己的工程能力。
这个作业在哪个具体方面帮助我实现目标 快速浏览了《构建之法》,对软件开发的具体过程及可能会遇到的问题有了初步的了解,在即将到来的项目中可以借鉴书中的经验。对代码管理及CI/CD工具做了初步的尝试,以便在未来的完整项目中使用。

1 阅读疑问

1.1 在一个项目开始前,代码规范该如何确立?

大家都知道用单个字母给有复杂语义的实体命名是不好的,目前最通用的,也是经过了实践检验的方法叫“匈牙利命名法”。

还有一些地方不适合用“匈牙利命名法”,比如,在一些强类型的语言(如C#)中,不同类型的值是不能做运算的,对类型有严格的要求,例如C# 中,if()语句只能接受bool值的表达式,这样就大大地防止了以上问题的发生。在这样的语言中,前缀就不是很必要的,匈牙利命名法则不适用了。Microsoft .Net Framework就不主张用这样的法则。

一个通用的做法是:所有的类型/类/函数名都用Pascal形式,所有的变量都用Camel形式。

——《构建之法》第四章

​ 在《构建之法》的第四章中,提到了有关代码规范的内容。代码规范是一个一直困扰着我的问题。首先,关于变量命名,文中提到了较为通用的匈牙利命名法,但同时也指出它有不适用的地方。文中还提到了Pascal形式Camel形式这篇博客较为具体地介绍了这几种命名规范,同时也提到了下划线命名法

​ 然而,介绍这些命名法的博客很多,但好像都没有指出一个项目中,我们该如何确定用哪种命名规范。是根据不同的编程语言(比如在Python项目中用下划线命名似乎较多...)?根据项目组中大部分人的编程习惯?根据领导者个人的编程习惯(比如OO中就是课程组下发CheckStyle文件)?......

​ 还有括号是否换行这个千古争论,如果大家都习惯同一种还好,但总有几率恰巧有一名成员跟其他人习惯都不一样。我觉得万一我是这个“异类”,强迫症会让我在初期编码十分不舒服。

​ 这可能是一个细枝末节的问题,但我在阅读以后并没有得到一个较为明确的答案。我十分想了解实际的项目开始前,代码规范究竟如何确定。

1.2 绩效如何量化?

贡献度 = 工作量 × 工作的影响力 × 工作的不可替代性

这个等式给我们的评测提供了一个方向。与直接估计贡献度相比,分别估计三个分量显得更可操作,准确性也更高。

——现代软件工程 10 绩效管理

​ 在《构建之法》第十七章中,讨论了绩效管理的问题。同时,在邹老师的博客中,提到了上面的文字,是以往课程小组的绩效计算办法。上面的等式看起来的确很合理,但我认为仍然存在问题。虽然看起来是把贡献度分为了三个分量,但是并没有避免最根本的问题——无法量化。这个等式只不过是将一个无法量化的贡献度,拆分为了三个无法量化的指标。那么,就会存在个人主观因素对指标的影响。

​ 书中提到了多种绩效管理办法,但每一种方法都存在不合理的地方。所谓“天下没有绝对的公平”,我认为是不是存在一种相对合理(完全公平不可能实现)的量化方法考察个人绩效,而不是使用“工作影响力”、“不可替代性”这种较“虚”的指标衡量?

1.3 作为学生,开发软件是不是无法避免“边翻书边动手术”?

作为一个软件工程师, 你觉得自己表现如何? 有没有这样的体会:

看书的时候觉得“技止此耳”,开发项目的时候才觉得实际情况和书上讲的都有一些出入,一些重要的细节书上没有提。我们很多人是边看asp.net的书, 边开发asp.net 的项目,这相当于一边看医学书一边动手术……如果你是病人,你希望你的医生是下面的哪一种呢?

a)刚刚在书上看到你的病例,开刀的过程中非常认真严谨,时不时还要停下来翻书看看……

b)富有创新意识,开刀时突然想到一个新技术、新的刀法,然后马上在你身上试验……

c)已经处理过很多类似的病例,可以一边给你开刀,一边和护士聊天说昨天晚上的《非诚勿扰》花絮……

d)此医生无正式文凭或正式医院的认证,但是号称有秘方,可治百病。

事实上,很多软件项目就是用a)或者b)这样的方法搞出来的。当然 也有一些人走d)这条路。

——《构建之法》第三章

​ 说实话,我并没有上文提到的那种体会,看书的时候只会觉得尽是些“奇技淫巧”,自己需要学习的东西还有很多很多。但是开发项目时的的确确是有类似的感受。比如之前在数据结构课程中手写B+树,自己上手时才发现书上说的过于简明,实现时还有很多细节需要查阅网上的资料。网上的资料质量又参差不齐,甚至还有混淆B树与B+树的......我经常跟舍友说,我是面向百度、Google、CSDN、Github编程。

​ 那么,在即将到来的课程项目中,我们能避免这种情况吗?或者说,作为学生,我们是否有能力避免这种情况?我们本身就是在学习的过程中,很难要求每一个人对技术都精通以后再进行开发,这是不是也算是某种意义上的Learning by Doing

​ 再往远了看,技术是一定会更新迭代的,那在实际工作中就有可能遇到需要使用新技术的时候,这时候好像不可避免地要翻着“说明书”来敲代码。所以在开发软件时,真的能做到总是上文中的c吗?作为学生,或者说在我们推进课程项目时,是否不可避免地成为“a类医生”呢?

1.4 结对编程的两人需要水平相近吗?

两人结对,尽管可能大家的级别资历不同,但不管在分析、设计或编码上,双方都拥有平等的决策权利。

——《构建之法》第四章

​ 在以往的课程中,我并没有结对编程的经历。就算是三四人组队的大作业,大家也都假装“分工明确”,然后各干各的去。第一节课上老师就提到了我们要进行结对编程,构建之法也用了很大篇幅去讲结对编程,但我还是有些疑虑。结对的两个人水平该如何?《构建之法》中似乎并没有明确说明,只说最终两人需要平等地进行结对编程。这靠谱吗?

​ 如果是一个大佬带领一个新手,是不是会不可避免地变成师傅带徒弟的模式?新人磕磕绊绊,大佬花费了更多的精力,也影响了整体的进度。更极端的情况有可能是,大佬对新手终究失去了耐心,难以忍受他的低级错误,两人不欢而散。

​ 如果两人水平相近,听起来合理一些。但这样会不会出现“菜鸡互啄”?两人都难以有突破性的提高,只是隅于低水平的结对。又或者是两人想要平等,当出现分歧时谁也无法说服谁,最终引发矛盾。

​ 如何结对,才能使结对编程较为可行?

1.5 领域的专家没有领域外的创新者那么有创意?

但是统计数据表明,70%的创新者说,他们最成功的创新,是在他们的拿手领域之外发现的。

——《构建之法》第十六章

​ 在《构建之法》第十六章中,提出了有关IT行业创新的几个迷思。迷思之五中提到了上面这一句话。这一小节给我的感受是,作者可能想说,创新不一定要是领域的专家。我对这个观点持保留意见,我认为想要在一个领域创新,或许是不需要成为专家,但也必须对领域有所接触,不能是完全的门外汉。

​ 文中提到了万维网之父蒂姆·伯纳斯·李的例子,作者将其定义为“物理学家”,以作证上文的观点。但我认为不然,在查阅了一些资料以后,我发现蒂姆·伯纳斯·李并不是对计算机领域一无所知的门外汉。在MBA智库中,我找到了蒂姆·伯纳斯·李的人物经历:

  1955年6月8日,伯纳斯·李出生在英国伦敦的西南部,他的父母都是英国计算机界的名人,曾参与了英国第一台商用计算机的研制工作,他从小便耳濡目染。在牛津大学的女王学院学习期间,他就用从花7美元买回的电视机,与M6800处理器、烙铁、电路板组装出了自己的第一台电脑。

  1976年开始蒂姆在私人公司里做编程员,1978年他在另一个公司里研究排编程序和操作系统。

​ 不得不说,这与作者提到了他是一个“物理学家”有一定的出入。并且,在学习了计算机网络以后,我了解到网络也有存在物理层面的构建,物理学家这一身份,我猜想会不会也对他提出万维网有一定的帮助?

​ 我个人认为领域内的专家似乎没有领域外的创新者那么有创意,有部分原因是,专家在提出创新时,需要考虑领域的现状,创新如何实施,能否落地。领域外的创新者缺乏相关知识,反而可以天马地想象。

2 源代码版本管理软件调研

Github

GitHub 是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务,是目前全球最大的开源社交编程及代码托管网站。GitHub 于 2008 年 4 月 10 日正式上线,除了基本的服务以外,还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱(报表)、代码片段分享(Gist)等功能。

​ 我个人使用比较多的就是Github,它最引人瞩目的是庞大的社区,在Github上能找到往年的作业、有趣的项目、各种软件的魔改版。看一个大佬有多强,看他的仓库有多少Star\(\star\)就知道了。

Gitlab

GitLab 是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的 Git 项目仓库,可通过 Web 界面进行访问公开的或者私人项目。

Bitbucket

BitBucket 是 2008 年创建的源代码托管网站,采用 Mercurial 和 Git 作为分布式版本控制系统,同时提供免费账户和商业计划。2010 年被 Atlassian 收购,与 Atlassian 的其他服务(Git GUI SourceTree、HipChat、Cloud9)顺利集成,主要面向慈善企业和企业用户/其主要市场是大型企业。


相同点

​ 这三个代码版本管理软件都有以下的基础特点:

  • 拉取请求

  • 代码审查

  • 内联编辑

  • 问题跟踪

  • Markdown支持

  • 双向认证

  • 高级权限管理

  • 托管的静态网页

  • 功能丰富的API

  • Fork / Clone Repositories

  • 代码段

  • 第三方集成

  • 在国内连接都比较慢......

    个人觉得使用Github与Gitlab时区别并不大,之前我甚至以为他们是一个东西,后来才知道是竞争关系。

不同点

  • 只有Gitlab本身的代码是开源的
  • Github、Gitlab有容量的限制,Bitbucket面向五人及以下的团队时,容量是无限的
  • Gitlab只支持Git,而Github还支持SVN,HG,TFS,Bitbucket还支持CodePlex,Google Code,HG,SourceForge,SVN

3 CI/CD工具初尝试

​ 对于Maven项目,我早有而闻,但从未尝试过。这次我不得不对它进行了一番探究。好在他的结构并不复杂,且上学期学习了XML的相关知识以后,xml文档对我来说不再是天书一般。总之,花了不少时间进行配置,跌跌撞撞地,我总算是完成了这次工具的调研。

​ 在这次工具链尝试中,我选择了OO第一单元的第一次作业(没有依赖包及代码较简单),写了简单的Junit单元测试。完整代码见如下仓库:

Gitlab

Github

3.1 Gitlab-CI

​ 仿照示例写了.yml文件
yml

​ 将Maven项目push到Gitlab上,触发CI,成功实现在线编译、在线运行、在线测试。

gitlab1 gitlab2

3.2 Github Action

​ 同样书写了简单的.yml文件并push,成功触发CI,yml文件如下:

name: GithubAction CI-Test
on: push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Build Project
        run: |
          java -version
          javac -version
          mvn -v
          echo "-----Build Project-----"
          mvn compile
      - name: Test Project
        run: |
          echo "-----Test Project-----"
          mvn test
github

3.3 使用感受

​ 在试用了这两种CI/CD软件后,我觉得它们跟课程时使用的评测机有点像。之前的课程中,我总是会“面向评测机DEBUG”,在有了这些工具以后,就可以大致实现这个效果。对项目自动做一些通用的测试,我认为能够减少很多bug。这次尝试只是初步学习了配置的过程,相信在未来对这些工具接触越来越多,我能够发现它们更强大之处。

posted @ 2021-03-16 10:40  WilliamHuang  阅读(53)  评论(2编辑  收藏