软工里的学问——个人阅读作业2
软工里的学问——个人阅读作业2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人阅读作业#2要求 |
| 我在这个课程的目标是 | 通过团队协作使用软件开发工具按照软件工程方法开发高质量并且可用的复杂软件系统的能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 初步了解软件工程的工作流程、任务分工、合作模式；了解代码版控软件与持续集成方法 |
阅读提问
Q1：在广泛使用智能IDE的今天，我们是否还有必要“精通”低层次问题？或者“精通”的要求是否有变化？
出自：《构建之法》 3.3 技能的反面
"problem solving"是技能的反面，但是如果这一步骤被自动化IDE替代了呢？
IntelliJ IDEA被广泛认为是最智能的IDE之一，对于一些最基本的代码，程序员甚至只需要打出第一个字母就可以在对应的自动提示中找到想要的选择。
*以上动图出自你认为IntelliJ IDEA是最智能的IDE吗？ - hahawhy的回答 - 知乎
有了这样的工具，许多最最基本的语法还有程序中”事务性“的代码，很多程序员都只能记个大概、写个大概。就算在学习过程中会清晰记得，但是在实践过程中使用了长时间的智能IDE，往往也会生疏。更不要说现在流行的许多框架，使用者根本无需关心它们底层是如何实现的，只管调用就完事了。
在这样的时代背景下，似乎精通最基础的语法变得越来越不重要，只有在学生时代，需要考试，不让使用智能IDE或者只能在CLI环境下编程的情况出现时才会对此有很高的要求。那么我们是否还有必要“精通”低层次问题？或者“精通”的要求是否有变化呢？
Q2：在敏捷流程中，开发团队会不断快速开发出新的增量版本反馈给用户，是否考虑过用户对频繁更新的反感？
第四步：得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进。
出自：《构建之法》6.1.2 敏捷流程概述
我的手机上有一百五十多个APP，几乎每天都会弹出需要更新的提示窗口，不胜其烦！有的时候马上要线上开会，点开腾讯会议，却提示更新，耽误时间、造成恐慌。为了使用户得到更优质的体验，及时修复软件漏洞是重中之重，但我们是否应该去了解用户真实的想法？他们真的希望更新这个版本吗？这样的更新造成的是便利还是麻烦？有的软件更新之后也看不出来变化（比如bug修复的更新，尤其是针对其他型号手机的更新），有的更新甚至会降低用户的体验：
开发者应该如何权衡更新的发布？Alpha版和Beta版更新的频率应该如何掌握？是改完就发布还是积累足够的更新才发布？如果发布太晚是否又会造成反感？这中间的度难以衡量......
Q3：无论是敏捷开发还是MSF，都有复杂而具体的流程与约定，它们对于小团队是否具有普适性？如果强行实践是否会给团队带来疲劳与负担？
二柱：软件工程讲的净是一些奇妙玄幻的概念，拗口的专业名词加上纷繁复杂的流程，其实做软件完全没那么难，主要靠的还是程序员自身的修养和完成工作的素质。
出自：《构建之法》 7.7 练习与讨论
在阅读第六第七章时，丰富的概念给我带来了一些困扰，成熟的大企业总会有很多价值观、方法论、行为框架和工作模式。对于一个入职这些大企业的员工，可能只能不断调整自己，适应公司的节奏，与这些方法论产生默契。但是对于初创公司或者像软工课上的六人小组而言，如此复杂的繁多的概念是否有点大材小用？对于年轻的充满激情的团队而言是否有点繁文缛节？如果总是强调规范，会不会给团队带来疲劳与负担？如果一个六人小组还要像下图一样分工是不是有点过分😂？
在学习软工之前，我们的开发并没有那么多流程。比如以前开发的队友招募平台，我们三个人，一个人负责前端，一个人负责后端，一个人负责数据库，大家都在自己电脑上独立完成自己的部分，独立进行测试Debug，开发一个新页面或者新功能就merge一次，最终完成开发，整个过程欢快和谐，也达到了目标，如果应用了敏捷开发，我也不认为会有什么质的提升，反而会很累，那么对于我们这种初出茅庐的新手，这些方法论是否合适呢？
Q4：如何发掘用户“尚不存在”的需求？如何将其实现？
软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。不同的项目需要不同的手段，这一步骤也被叫做“需求捕捉”，形容真正的需求稍纵即逝，需要靠火眼金睛和敏捷的身手来发现并抓住它们。另外，很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。
出自：《构建之法》 8.1 软件需求
书中在讨论发掘用户需求时提到了这样一种情况：用户对于他们不熟悉的事物（例如全新的市场、颠覆式的创新）未必会贡献很有价值的想法。
而乔布斯就是具有“创造需求”这种能力的人：
有些人说：“消费者想要什么就给他们什么。”但那不是我的方式。我们的责任是提前一步搞清楚他们将来想要什么。我记得亨利·福特曾说过，“如果我最初是问消费者他们想要什么，他们应该是会告诉我，‘要一匹更快的马！’”人们不知道想要什么，直到你把它摆在他们面前。正因如此，我从不依靠市场研究。 ——《乔布斯传》
知乎用户多多滴春天说：用户喜欢做选择题，不喜欢做简答题。
那么，身为开发者，应该如何创造出用户将来想要的呢，如何给用户提供市场中没有的"更优解"呢？
我们是否只能依赖像乔布斯一样的天才才能不”穿新鞋，走老路“呢？
我们能否通过经验积累，厚积薄发输出用户喜闻乐见的创新呢？应该如何从成千上万成熟的想法中总结出新点子呢？
Q5：PM作为Program Manager是否需要时刻补充自己的编程知识？
PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解。
出自：《构建之法》9.5 PM的能力要求和任务
PM，作为一群程序员开发者的粘合剂、客户需求的Decoder，团队目标的规划者等等角色，虽然十分重要，但似乎并不需要什么编程能力，从其任务中可看出：PM最重要的还是组织规划能力。在本书9.6 练习与讨论中也提出：
有人说，PM既不懂开发，也不太懂测试，但是他们似乎指挥了团队的行动——就像乐团的指挥一样。那么，那么乐团的指挥凭什么能让几十号人的乐团都听他的呢？他们到底懂多少乐器，他们写过音乐么？乐团指挥是怎么培训，怎么培养的呢？他凭什么就能拿一根筷子就在台上指手划脚？
实际上，乐队指挥需要对乐队中的乐器十分了解，他们不仅仅需要高水平的鉴赏、听辨能力（他们所必要的，独有的能力要求），还需要很丰富的乐器演奏经验，据知乎用户王一兵的回答：
“每多精通甚至是掌握一门乐器，对指挥而言都是一笔无上宝贵的财富”
······
“无所不能”的汉斯里希特（某次排练中，被圆号手告知指挥的乐句处理方式不可能演奏出来，大叔冲上前去，一把抄过法国号，自己完美吹奏了一遍，直接镇住乐团）
因此，我想知道，在技术日新月异的今天，程序员必须通过不断学习新技术保证自己不被淘汰，那么如果PM的编程知识仅停留在ta毕业时，ta如何与团队沟通？如果在讨论项目实现时，不了解新的技术，如何把控项目周期，了解实现难度？但是话说回来，如果PM也持续学习编程知识的话，PM似乎只是善于沟通的程序员？并且学习成本如何控制，又要管事又要学技术也太累了，PM又不是超人。
调研源代码版本管理软件
Github
GitHub 是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务，是目前全球最大的开源社交编程及代码托管网站。除基本的服务以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。
GitLab
GitLab 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的Git项目仓库，可通过 Web 界面进行访问公开的或者私人项目。GitLab 且具有wiki以及在线编辑、issue跟踪、CI/CD 等功能。
Bitbucket
BitBucket 采用 Mercurial 和 Git 作为分布式版本控制系统，同时提供免费账户和商业计划。2010 年被 Atlassian 收购，与 Atlassian 的其他服务(Git GUI SourceTree、HipChat、Cloud9)顺利集成，主要面向慈善企业和企业用户/其主要市场是大型企业。
Coding
Coding 是一个面向开发者的云端开发平台，目前提供代码托管，运行空间，质量控制，项目管理等功能。此外，还提供社会化协作功能，包含了社交元素，方便开发者进行技术讨论和协作。也许是目前国内体验最接近 github 的产品。
团队协作流程：基于gitlab的Git团队协作流程、超详细！Github团队协作教程（Gitkraken版）
项目管理：基于gitlab的项目管理流程、github团队项目管理入门
调研持续集成/部署工具
Gitlab CI
Maven Build
Maven Test
Github Action
Maven Build
Maven Test
不知道是不是这几天开两会的缘故，不开代理我完全登不上Github，所以体验极差，就算登上了也总是push不了，导致在最基础的操作上浪费了大量时间。两者操作有点不同，Gitlab只需要在仓库里上传 .gitlab-ci.yml 文件，就会自动运行CI/CD工具，而GitHub则是在Action里（半自动）创建yml文件，最终这个文件会在workflow文件夹下。总的来说Gitlab操作更简单，但是Github有Market生态会更好。所以感觉Gitlab CI可能更适用于轻量的开发，而Github Action则更适合大项目。
Gitlab有一篇文章系统地比较了Gitlab CI和Github Action。还有一篇也很完整，由于没有在这些工具上进行过完整的开发，所以无法亲自给出详细的体验。
