Begin of SE·

作为一个在北航计算机学院摸爬滚打的普通学生，由于6系丰富的资源，笔者接触了一些软件项目，包括OO课程网站维护，学者数据爬取平台，航送app，数据库的电商平台等等，还有一些网站小程序等等，然而做了这些项目之后，自己的实际项目管理和软件素养并没有得到完全显著的提升，原因一个是要么网站过于复杂仅仅是维护和更新部分代码，要么就是课程或者项目用完即扔。这也是我最终选择敏捷开发课程的原因，希望能够在大三下这个最后的黄金学习时间，向老师和助教以及同学们学习到尽可能多的具体技术和软件开发、项目管理的思想方法，让自己的开发和团队协作能力都上一个档次，软工，我来了！！！

《构建之法》阅读提问·

阅读中记录的琐碎疑问·

看的过程随手记录了一些不成形的问题，选择了几个进行深究，其他的就留存于此作为记录

• 没有银弹未来是否可有实现？现在有低代码平台等等
• P47 团队对个人期望，专业人士不需要灵感与激情？
• P80 结对编程的要求，似乎有点过于拘束死板？
• P85-86 的中间层和最内层的例子中的表述似乎都相当负面且情绪化，为什么这两个就不能有一些柔和的处理以及表达呢？
• P116 scrum对团队人员的要求 PM vs Scrum leader ? ?
• 敏捷开发不了AI算法软件或者技术背景强的软件？？ P121
• P159 人类学调查 走到真实世界会不会太泛泛而谈了，实际的生活我们到底应该以什么样的方式和频率介入哪些生活？
• P184 有没有可能借鉴去中心化网络架构ring AllReduce，即两个人之间进行交流，并将他们组成环？
• P357 赢者通吃 如何看待如今的天猫京东拼多多 以及美团外卖和饿了吗？
• P371 当下的低代码平台或者云速建站服务也只需要很少的代码 似乎与只能手工相悖？

1.专业软件开发师仅需要按照流程理性地工作？·

原文·

内容参见原书第3章 P47-48

理性地工作∶软件开发有很多个人的、感情驱动的因素，但是一个成熟的团队成员必
须从事实和数据出发，按照流程，理性地工作。很多人认为自己需要灵感和激情，才能为宏大的目标奋斗，才能成为专业人士。著名的艺术家 Chuck Close 说∶“ 我总觉得
灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作，最终你会有所成就 ”

问题·

• 仅仅按部就班地理性工作，真的能保证大部分工程师有所成就吗？

解释·

• 个人认为对于著名的艺术家或者成功人士来说，他们本身就已经具有了很高的天赋或者很高的热情，因此对他们来说，也许只要按部就班进行工作就已经可以完成很高质量的代码，但是对于一般的工程师来说，每天重复差不多低质量的工作，没有任何激情和推动，可能最后只能带来较低质量的产品。而且对于一些重大复杂的算法问题或者架构问题，很多时候依赖于突发奇想或者灵机一动，如果单纯仅仅是机械做一样的工作，能解决这样的问题吗？同时这样的工作模式也很难催生新的问题发现和技术创新
• 因此这一点我个人认为更适合的是大多时候理性，但该有激情的时候需要热情投入。

2.结对编程能更加灵活吗？·

原文·

内容参见原书第3章 P81

4.5.4 如何结对编程

1. 驾驶员∶写设计文档，进行编码和单元测试等 XP开发流程。 
2. 
领航员∶审阅驾驶员的文档;监督驾驶员对编码等开发流程的执行;考虑单元测试的覆盖
率;思考是否需要和如何重构;帮助驾驶员解决具体的技术问题。领航员也可以设计TDD中的测试用例。 
3. 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息 15分钟。
领航员要控制时间。
 
4. 主动参与。任何一个任务都首先是两个人的责任，也是所有人的责任。
 
5. 只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不
管在分析、设计或编码上，双方都拥有平等的决策权利。
 
6. 设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如
果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好。

问题·

• 能否有两个人先讨论好然后再一起写不同模块或者同一个文件中不同代码，之后再互相测试？
• 形式能否更加灵活？

解释·

• 原文中的结对编程描述貌似必须有一个人是领航，一个人是驾驶，但是事实上对于太复杂的需求，驾驶员在写代码的时候被监视就好比是面试中做算法题一样难受，甚至发挥失常（虽然这个和人的心理素质和代码能力密不可分）。而面对过于简单的需求，大部分时候不太需要领航员一直检查和review或者帮助理解文档，这个时候领航员似乎就无所事事了
• 结对编程能不能采用两个人先一起研究需求，并行编程，写微小的模块，之后一起检查测试代码的模式？这样似乎也可以提高效率，而且每个人负责的微小部分代码更精细，同时两个人互相测试也能测试效率更高。

3.团队的强弱与scrum·

原文·

内容参见原书第6章P116页

如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反，往往需要经历多次失败/总结/改进的过程才能让 Scrum 走上正轨。换句话说，如果你的团队已经有这么厉害（自主管理、自我组织、多功能型）的一帮人，那么用不用 Scrum 都能写好软件!

问题·

• 如何衡量一个团队的强弱？从技术角度还是从努力角度还是综合起来？如果是参差不齐的队伍呢？
• 强大的个人组合成的队伍就不需要scrum来开发软件了吗？

解释·

• 首先这里的团队的强弱本身是一个很主观而且很难给出答案的定义。比如一个队伍可能每个人技术上都很强，甚至每个人都做过全栈开发。但是他们的团队合作能力和意识不一定好，以及可能有些人在这次开发中与团队愿景不一致，那又如何定义这样的队伍的强弱呢？同时一个队伍可能技术比较平均甚至平庸，但每个人的学习能力较强，愿景类似，而且能投入的精力都很多，那这个团队是强还是弱呢。同时参差不齐的队伍又该如何计算？个人认为大多数队伍都可以实现scrum，只是可能对于不同队伍，目标和具体细节做出相应改动罢了。
• 假设已经满足了作者关于强的team的定义，那这个scrum流程就不需要了，那大家敏捷开发就一锅乱炖，看心情来完成代码吗？显然不太合理吧，所以要么有相应的简化处理，要么就换一种方法论，但显然似乎也不是完全不需要scrum了

4.敏捷仅仅适用于简单的应用？·

原文·

内容参见原书第6章P121页表6-3

问题·

• 只有简单的变化多的网站适合敏捷，而复杂且稳定软件就不适合甚至不需要吗？

解释·

• 当下的很多项目都需要开发者在短时间内开发集成了众多AI算法且质量很高的软件，这时候如果不使用敏捷思想的话难道需要磨洋工吗，显然也不太可能。这个时候如果单纯用本书提到的scrum不行的话，能不能采用相似的或者以本书的敏捷方法为内核的稍加修改后的方法呢？笔者认为可以分配更多的角色，比如算法工程师，模型部署测试等角色来扩充现有的模型。
• 像开发底层正则表达式解析模块其实也需要不断做测试以及迅速交付，如果恰恰有项目需要做一个底层的库而用户还需要定期检查呢？那似乎这个时候敏捷也没什么不好。而且很多bug都必须在真实的大量场景测试才能找到问题

5.人类学调查的具体方式？·

原文·

内容参见原书P158-159

大学生们如果能暂时放下自己所学的许多高端技术，走到真实的世界中去，也许会看到并理解来自普通用户的真实需求

问题·

• 真实世界这么大，我们该走到哪，走多深呢？

解释·

• 很多时候我们进入生活就迷茫了，这么大的世界，随便走走就眼花缭乱了，具体的真实需求可能就找不到了。具体操作时似乎不能泛泛的撒网了解真实世界，而是寻找其中的若干个有意思的点深入挖掘探索才会更有效率一些。而具体应该探索哪些行业，做哪些具体的事情呢？我个人认为最好的方式是和真实世界中的用户或者客户直接对话或者体验他们的应用场景，这样似乎比出去走走要更加具体实在一些。

6.赢者真的能通吃吗？·

原文·

内容参见原书P357

赢者通吃
这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身家倒贴进去。

问题·

• 软件行业赢家真的可以通吃吗？

解释·

• 比如：360vs电脑管家vs鲁大师，饿了吗vs美团外卖，腾讯视频vs爱奇艺vs优酷，至今都没有分出胜负，而最近的统计似乎也显示这些公司互有胜负，所以赢者通吃这种说法似乎有待商榷，这个游戏的合理性似乎也需要讨论。似乎很多时候并不能做到作者说的赢家通吃。

7.手工写代码和银弹·

原文·

内容参见原书P371

一些人士批评"很多企业还处于手工式的开发生产阶段"，我不知道软件除了用手工，还可以用什么别的来写。也许有人说，是不是那些CASE（Computer Aided Software Engineering》工具，或者是代码向导（Code Wizard），用右键一点，然后继续点【下一步】、【下一步】就可以产生出很多很多代码?这些固然好，但是你可以点一下产生很多代码，另一个公司也可以点一下产生很多同样的代码。你的核心技术在哪里呢?
本文之后提到的各种编程牛人做的有价值的软件，都是自己动手写代码，而不是用什么代码生成器搞出来的。

问题·

• 自动代码平台与软工似乎越来越普及，如何看待？
• 随着AI发展，未来自动写软工的机器人和低代码甚至0代码平台会成为银弹吗？

解释·

• 似乎在当下2022年和未来非手工写代码或者自动软件工程渐渐成为现实，包括腾讯和华为在内的很多公司的云服务都提供了低代码甚至自动部署的云建站服务，这些服务很多时候已经可以满足用户的需求了，那么这是不是认为就可以取代手工写代码了呢？
• 最近 Alphacode 在很多算法平台获得了突破，以后的AI是否也可以在软工领域取得突破呢，包括甚至有机器人模拟scrum的过程，完整地进行高效编码，那这会不会成为软工领域的银弹呢？

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

版本控制系统分类·

一般来说，版本控制系统有三种主要类型，即：

• 本地：所有开发人员都在同一个文件系统中
• 集中式：团队在中央服务器上是最新的项目版本，成员需要先从中央服务器拉取最新版本，然后开始自己的修改开发，之后再传到中央服务器上
• 分布式：开发人员每个人都有一个自己的代码存储库，需要更改时在存储库之间推送共享

一般来说，最有效率的是Git Repos，也就是目前最成功的分布式版本控制系统，本次调研也主要针对Git的几个软件GitHub、GitLab与BitBucket

Git 版本控制管理软件的共同特点·

• 拉取请求 Pull Request
• 代码审查 作为拉取请求的后续机制，可以在Pull Request中夹带针对指定代码行的注释，或者要求他人对拉取的请求做修改
• 内联编辑
• 问题跟踪
• Markdown支持
• 双向认证
• 高级权限管理
• 托管的静态网页 github pages 等等
• 功能丰富的API
• Fork / Clone Repositories 克隆和复制
• 代码段
• 第三方集成

GitHub、Gitlab、Bitbucket、Coding·

调研持续集成/部署工具·

Gitlab CI·

说明·

本次Gitlab使用了OO的gitlab的CI进行测试，由于相关服务器刚刚迁移到校内，因此需要重新配置runner，这部分除了CI部分顺便记录一下创建个人项目和配置runner的过程

创建Group与Project·

首先gitlab是基于group进行操作的，因此第一步首先需要建立group才能在内部进行项目创建，为了方便组员的CI测试，我单独创建了一个setest group并拉进了所有的软工小组成员，截止目前有两个项目，其中Setest是我的项目，里面有一个python文件实现了快速排序

配置runner·

网上很多博客内容太杂了，其实就简单的几行命令和一个服务器就可以

先在左侧栏的Settings里找到CI/CD，进入之后将Runners旁边的Expand点开，之后点击里面的安装指导，按照里面的命令在任意的服务器上装好服务并完成register就好了

笔者使用的是linux amd64服务器，命令参考如下：

Download and install binary·

1
2
3
4
5
6
7
8
9
10
11
12

# Download the binary for your system
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Give it permissions to execute
sudo chmod +x /usr/local/bin/gitlab-runner

# Create a GitLab CI user
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

# Install and run as service
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

Command to register runner·

1

sudo gitlab-runner register --url $URL --registration-token $REGISTRATION_TOKEN

注意这里的$URL和$REGISTRATION_TOKEN替换成相应的url和token就好了。同时可以参考选择 ruby2.7 的 docker 进行部署

这样操作完之后，Runners展开的左侧就会有runners列表，这时需要点进你的服务器的编辑按钮，将内部的 Indicates whether this runner can pick jobs without tags 勾上就可以使用了

CI测试·

1. 主要是对一份快速排序的代码进行了评测，代码如下，正确的输出是 [1,2,3,4,5] ，仓库链接：http://gitlab.oo.buaa.edu.cn/setest/setest

2. 编写 .gitlab-ci.yml 上传并进行CI测试

Github Action·

1. 同样的代码上传至 github 上进行相同的代码测试 链接：https://github.com/BUAADreamer/Setest

2. 编写 .yaml 文件使用 action 的 overflow 进行测试结果

CI/CD 相关·

1.CI/CD工具定义·

CI持续集成，CD持续部署，这是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题

2.Gitlab CI特点，特性·

Gitlab CI/CD内置于GitLab，是Gitlab一个简洁好用的的持续集成/持续交付/持续部署的框架

• 多平台： Unix，Windows，macOS和任何其他支持Go的平台上执行构建。
• 多语言： 构建脚本是命令行驱动的，并且可以与Java，PHP，Ruby，C和任何其他语言一起使用。
• 稳定构建： 构建在与GitLab不同的机器上运行。
• 并行构建： GitLab CI / CD在多台机器上拆分构建，以实现快速执行。
• 实时日志记录： 合并请求中的链接将您带到动态更新的当前构建日志。
• 灵活的管道： 可以在每个阶段定义多个并行作业，并且可以触发其他构建。
• 版本管道： 一个 .gitlab-ci.yml文件 包含测试和整个过程的步骤，使每个人都能贡献更改，并确保每个分支获得所需的管道。
• 自动缩放： 可以自动缩放构建机器，以确保立即处理您的构建并将成本降至最低。
• 构建工件： 可以将二进制文件和其他构建工件上载到 GitLab并浏览和下载它们。
• Docker支持： 可以使用自定义Docker映像， 作为测试的一部分启动服务， 构建新的Docker映像，甚至可以在Kubernetes上运行。
• 容器注册表： 内置的容器注册表， 用于存储，共享和使用容器映像。
• 受保护的变量： 在部署期间使用受每个环境保护的变量安全地存储和使用机密。
• 环境： 定义多个环境。

3.Github Actions特点，特性·

actions可以用来作为CI/CD使用，但是它不只是CI/CD，因为它其实是一组docker容器所组成的Workflow，Workflow的触发条件，公共仓库目前仅支持push，私有仓库则支持check_run、create、delete、issue comment， commit comment, pull request等许多事件, 通过这些事件，可以完成包含CI/CD在内的许多自动化操作，例如接收到issue comment之后使用telegram bot发送通知等等

4.CI/CD工具作用分析·

• CI/CD主要运用了jenkins进行对后端的开发代码的拉取，经过自动编译，打包，测试后，自动发布到tomcat服务器上，实现自动化的产品上线。
• 持续集成注重将各个开发者的工作集合到一个代码仓库中，通常每天会进行几次， 主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。 通过持续集成，开发人员能够频繁地将其代码集成到公共代码仓库的主分支中。 开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。
• 持续部署的目的是最小化部署或发布过程中团队固有的摩擦， 它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布。 持续部署扩展了持续交付，以便软件构建在通过所有测试时自动部署。在这样的流程中， 不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。 此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容。

5.CI/CD工具对比·

Gitlab CI与Github Actions的系统对比在 https://about.gitlab.com/devops-tools/github-vs-gitlab/ci-missing-github-capabilities/ 非常详尽的展示了，其中CICD的对比大致用以下图来总结

可以看到，对于CD部署的第三方性，以及CICD的部署容器和底层配置架构，gitlab做的更加细致一些，而github的市场化和开源性更好。

总的来说，使用体验来看由于github过于庞大，对于CICD的关注度显然没有gitlab到位，但是actions的丰富功能确实也很吸引人，然而出于种种原因最后可能软工还是会选用gitlab或者coding平台。coding对于中国用户当然是更加友好，不过具体功能还有待调研。

• ← Previous Post
• Next Post →