目录

第一部分

再次思考

原问题思考博客链接

问题1:如何区分一个好的程序员和不好的程序员呢？

原回答：

我认为，一个足够优秀的程序员至少要具备独立解决问题的能力与与他人协作的能力。独立解决问题体现在他可以通过查找搜索引擎等方法来解决当前面临的未知的或较困难的问题；与他人协作则是可以将自己的问题暴露出来、不懂就问的能力。

再思考：

作为组长，审视一个组员是否优秀，没有想象中的那么容易。因为我不是他，他是否具备独立解决问题的能力还真不好考察──真说不来他解决问题是完全靠自己，还是问了 ChatGPT 得到了一个看似合理，但存在漏洞的答案。相较来看，和其他人协作的能力比较好考察，在开会时他的态度、在群里的发言等都可以反映出来。目前，我认为一名合格的程序员应当能融入团队，积极参与每一次讨论，贡献自己的想法；按时完成分配的任务，并及时向组长汇报完成情况。

问题2:单元测试中，如果每次做修改都需要覆盖所有的代码路径带来的维护成本是否会过大？

原回答：

在我的体验中，由于单元测试具有高度自动化的特性，在一次编写之后，无需人员干涉便可自动对代码进行测试，可以有效地防止修改/新增代码带来新的 bug。

假如项目过于庞大，我会考虑将项目切分为几个互不干涉（解耦）的模块，对每个模块分开编写单元测试。这样在修改某个模块的代码之后，仅需运行对应模块的单元测试即可发现问题，并节约时间。

再思考：

按照项目开发的结果来看，单元测试确实可以检查出程序潜在的 Bug，有效提升代码的健壮性。但是，倘若追求代码覆盖率接近 100%，对于经常变动的代码，单元测试的代码也许要跟着其一起改变，代价确实是比较大的。

我们最终的解决办法是，不追求 100% 的代码覆盖，而是尽可能达到敏捷开发的最低要求──80% 的语句覆盖率，在此基础上保证覆盖所有的 API，我认为是比较合理的。

问题3:单元测试应该谁来写？

原回答：

我认为单元测试还是应该由编写这段代码的人来完成。

可以参考“测试驱动开发” 的思想，在编写函数之前先写函数的单元测试。

再思考：

到现在我依旧认为单元测试应该是编写这段代码的人来完成，但现实也很骨感，负责代码编写的同学将测试的任务推给了其他人，自己放飞自我的写，测试人员也在一脸懵逼的情况下，尽力完成了测试。这样的结果，我认为是不可取的。

我们计划采用的 TDD 测试驱动开发，也只是停留在纸面上，一再强调但组员就是不遵守......对他们来说太过于困难了吗？

问题4:对于一名工程师而言，究竟应该是更”专“一点好，还是更”广“一点好呢？

原回答：

作为当今社会的程序员，其任务早已不是局限在我所负责的那一小块内容里。由于敏捷开发的推广，程序员经常变动岗位，可能今天做开发，明天就去做测试了，对知识的需求量很大。

我认为学习开发应当以广为主，并一某一方向专精为辅，才可以更好地发挥作用。

再思考：

想法有一定的改变。我意识到了如果只是以广为主，而没有在某个方向有所专精，是很难在某个行业站住脚的。

所以我将目标改为：以专精某个方向为主，以广为辅，这样才能在某个行业有所建树。

这是我这几个月实习的体会。

问题7:敏捷开发中是否有必要解决所有bug？

原回答：

在我看来，敏捷开发要求产品迭代速度快、成员压力较大，并没有太多经历关注当前版本下的所有 bug。

可以将一些不太影响用户体验的 bug 留到之后的小版本中修正，而此刻先专心于开发手边的事情。

再思考：

从 Alpha 到 Beta 来看，Bug 必定是伴随开发左右。在 Alpha 阶段我们尝试去解决所有的 Bug，最后落得有些功能都没来得及做完。

在 Beta 冲刺阶段，我们开始为 Bug 和 Feature 加上优先级，先完成高优先级的任务，确实可以保证核心的功能能及时完成，但势必有一些不是很急的 Bug 会不断地延后，被更紧急的任务所挤压。

在我看来这是可以接受的。

新知识

需求分析阶段

用户的需求究竟是什么？这是在需求分析阶段一直困扰着我们的问题。

在曾经做过的项目里，我很有幸地拿到了一份项目需求分析书，在此基础上进行开发，省略了需求分析的过程。

而这次，通过软件工程课程的学习，我掌握了 NABCD 模型，并在项目的需求分析阶段进行了实践，有效地帮助我们梳理了需求。

设计阶段

通过设计阶段的实践，我复习了曾经学习过的 UML 类图、时序图、活动图、用例图等知识，还使用了曾经从未使用过的原型设计工具：Figma 和墨刀。（曾经，好一点的是使用画板写写画画，一般都是将设计放在脑海里，很快就忘掉了）

实现阶段

在之前做过的几个项目里，我都是从事前端开发，这次也是依旧。

这次，我们使用的依旧是 Vue 框架，但是尝试了从未使用过的 Element-Plus UI 框架，以及 Vue-Router 等辅助框架，还有 typing.js 等 JS 库。

通过这次实战，我对 Vue 开发有了更加深刻的认识，这也是我头一次从零搭建一个 Vue 的项目。

测试阶段

前端的测试任务不多，主要在手动测试编译后的界面。

这次，我们做到了每日构建，每天都可以拿到最新的成品进行测试，对测试和 Debug 都有很大的帮助。

发布阶段

我们将测试与发布紧密的结合在了一起，构建了 CI/CD 系统。在完成 CI/CD 的部署之后，每日发布新版本变得异常地简单──仅需发布一个新的 Release，CI/CD 系统就会自动地将最新的代码构建并部署到服务器上。

心得体会

本次项目也并不都是一帆风顺的，我想分享一下在分配贡献度时于组员的一些意见的不合。

我们小组考核一向比较严格。从需求分析阶段一直到 Beta 冲刺，我们尝试过各种量化贡献度的方法：

显示由组长来为每个组员打分（比较不客观）；然后尝试根据每个人完成的代码行数来换算分数（很难执行）......

在 Beta 冲刺我们完成了整套开发流程工具的建设，因此我打算使用 Teambition 完成任务的数量和 GitHub Issue 完成数量来作为贡献度的量化指标。

我在先前的会议上有强调过我们应当如何以合适的粒度提交 Commit，每天也有督促大家在 Teambition 上将自己完成的任务打勾。

但有一个组员，我确实看到他完成了不少的测试工作，（虽然项目前期有些摸鱼）在项目后期确实也投入了时间做开发，但他顺手就将所有代码更新提交为一个 Commit 传到了仓库里，Teambition 中的任务也没有做细分，了了一个 “后端测试” 就定义了整个 Beta 的工作。按照我们小组拟定的贡献度计算公式，他的贡献度很低。

在公布贡献度之后，他立刻向我表达了不满。我也很理解他的心情，毕竟他确实做了不少的工作，但是他的工作量确实没有体现在 Teambition 和 GitHub 上。最后，通过不断地解释，他也理解了我们的计算公式，也认可了自己的贡献度。

只能说，我认为量化这东西很蠢，但是又不得不用。

七大目标掌握程度

第二部分

个人技术总结博客：

使用 GitHub Actions 与 Docker 构建 CI/CD 系统

概述：

CI/CD 即持续集成/持续部署，是一种软件开发实践，通过自动化的软件流程来构建、测试、部署软件。通过使用 CI/CD，开发团队可以更快地构建和交付出高质量的软件。