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文件

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

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

3.3 使用感受

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