终章 - 软件工程实践总结作业
终章 - 软件工程实践总结作业
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
当时正值酷暑，快开学了，在家里也是无所事事，就花费了一些心思写下了那份第一次作业。现在看来，当时的想象还是蛮符合预期的——一门丰富软件工程实践经验、从零经历合作冲突百般荆棘使一个项目开花结果的课程。
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
当时写下的目标主要是：
- Git、IDE 等工具的大量实践；
- 丰富实战经验；
- 丰富合作经验；
- 确立前端 / 后端 / 移动端方向并专精一门语言；
- 可能的话找一份实习，进一步实践；
其中，「Git、IDE 等工具的大量实践」、「丰富实战经验」、「丰富合作经验」充分达到了我的期待和目标（确实是很多个难忘的深夜啊🤔），而「确立前端 / 后端 / 移动端方向并专精一门语言」还是没能有所结论，当时的想法是：
目前有许多思考，较为偏向移动端的 iOS，因为前端革新太快，框架繁复，后端兴趣较低一些，移动端的 Android 也是可选项，但可惜没有报上这学期的 Java 课程，要么得自学了。但 iOS 也有一些弊端，比如 Swift 是世界上最好的4种语言😏。所以综合来说，将来想从事的工作可能是一名 iOS 开发工程师。
现在看来，前端还是不是我的优先选择，一是个人喜好，二是它「革新太快，框架繁复」。
移动端方面，这学期的接触就只是在 Alpha 开始阶段的时候用让我电脑疯狂蓝屏的 Android Studio 做了一个小组要求的小练手，然后觉得 Java 这门语言不够简洁，对 Android 兴趣渐失（可以说是个偏执狂了）。而 iOS 没有任何接触，但网上的风声和讨论都显示这条道路在当下异常困难，看来只能是保留选项了。
这学期主要专注的后端方面，我认为无论是 PHP、Java、Python 或者其他，停留在会使用框架，精于使用框架实现业务逻辑都是不行的，要往前走，更关注那些底层的、繁复的、真正衡量一个项目效率和价值问题，例如：MySQL 命名、设计及使用规范、MySQL 索引原理及慢查询优化。当时在建立 Gravel（我们项目后端的名字）的数据库的时候，虽然已经学过数据库这门课，但是面对 MySQL 的字段类型、长度、索引等等的设计，还是十分心虚——怎么做才是最好的呢？经历一番搜索后，上述文章使我受益匪浅（后来发现有 MongoDB 这样适合快速迭代开发的数据库，希望下次有机会能实践一下）。再例如，当时一个项的 id 设计也有一点问题，我找到了这篇文章：Leaf——美团点评分布式 ID 生成系统，虽然我们杀鸡不需要用到这么大的牛刀，但同样拓宽了我的视野，促使我思考。往更深了说，一个厉害的后端工程师，应当对分布式、数据挖掘、安全性、可用性等等比较玄学的名词有一些自己的理解，而我还只是停留在皮毛而已。
基于上述讨论，我不敢说能够「确立前端 / 后端 / 移动端方向并专精一门语言」。
「可能的话找一份实习，进一步实践」，实习大概是在大三暑假，有了软工课程的收获，到时候会更加努力的。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
1、统计一下，你在这门软件工程实践中，完成了多少行的代码
手动计算器统计结果：
- 数独项目，约 393 行
- 部门与学生数据生成及智能匹配项目，约 912 行
- Beta 阶段结束，除去框架行数，约 2429 行
共计约 3734 行，删除与修改无法计算。
2、软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业序号 | 内容 | 估计时间（分钟） |
|---|---|---|
| 1 | 回顾与展望的博客 | 240 |
| 2 | 数独项目 | 1385 |
| 3 | 第一次结对作业：学生和部门互选产品原型设计 | 1083 |
| 4 | 第二次结对作业：部门与学生数据生成及智能匹配算法 | 1200 |
| 5 | Alpha 个人技术博客 | 210 |
| 6 | 华为云软件产品案例分析 | 240 |
| 7 | 软件工程实践总结 | 380 |
| n | 团队作业——Alpha、Beta、团队展示、选题报告、需求规格说明书、预则立 && 他山之石、系统设计、UML 设计、团队 Alpha 项目课堂展示、团队项目测试报告与用户反馈…… | ??? |
3、哪一次作业让你印象最深刻？为什么？
如果是所有作业中，无疑地，肯定是 Alpha 冲刺，那种通力合作、共同努力建立一个项目的感觉当然是最令人印象深刻和回味的。
如果是个人作业，我觉得应该是 Alpha 个人技术博客。相比其他作业可以借鉴和参考、趋向一些固定的模式来说，这个个人博客更加要求自己思考和总结出一些经验，其中思考和组织逻辑的过程是很奇妙的。
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
之前博客预计的时候说的是「由于上述的目标宏大，承载的事物又多，软工又是主要学习的途径，所以我打算每周投入大量时间。但我无法预测其他科目和其他事务的所需时间，所以无法给出具体平均小时，只能说尽量和加油」，现在而言，到今天是 15 周结束，我觉得至少平均每天 5 个小时，也就是平均每周 35 小时，如果是共 16 周，也就是 560 小时。
5、学习和使用的新软件；6、学习和使用的新工具
Markdown：Yu Writer、Typora、Visual Studio Code with Markdown Preview Enhanced and markdownlint
Markdown 导出 PDF：PhantomJS
协作：Teambition
原型设计：Mockplus
绘图：ProcessOn
文档协作：石墨文档
接口文档：DOClever、ShowDoc、apiDoc
IDE：Visual Studio 2017、PhpStorm
编辑器：Visual Studio Code
Git GUI：GitKraken
虚拟机：Virtualbox、Vagrant
数据库管理：Navicat Premium
MySQL 数据库设计：WWW SQL Designer
测试：OpenCppCoverage、PHPUnit、Apache ab、Postman、Apizza
终端：iTerm
快速命令：Shuttle
SFTP 工具：Transmit
文件比较与同步：FreeFileSync
图片快速上传图床：iPic
云服务：腾讯云、七牛云、华为软件开发云
7、学习和掌握的新语言、新平台
仅进一步学习 C++、PHP、Linux（Ubuntu、macOS），不能算掌握。
新接触的语言：Java
8、学习和掌握的新方法
NABCD 法需求分析、原型设计、单元测试、团队协作方式、API 测试方式等。
9、其他方面的提升
- 文档查找、阅读
- 项目文档编写
- 逻辑思维
- 原型设计
- 数据库设计
- 绘图
- 测试
- 协作
- 人际沟通
- 熬夜
- 抗冷
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结 + 实例 / 例证结合的分析
个人作业给我的感受是，打铁还需自身硬，代码能力是实打实的，算法、数据结构对一个程序影响很大，例如在数独作业中，DLX 算法相比 DFS 是更好的，但我算法能力有限，只能堪堪完成 DFS，最后还完成的不好，测试点都没跑出来几个😑。
结对作业告诉我，使用一些必要的工具可以提升效率，不能懒、嫌麻烦、怕「磨刀误了砍柴工」。我在结对作业里第一次尝试了和「对友」使用 Teambition，它规划任务、时间、文件，使要做的事情清晰、一目了然。
团队开发给了我四点启示。
A. 预估的能力十分宝贵，我在之前的 Alpha 事后诸葛亮里说「整体来说，最匮乏的是预估的能力，缺少一些有效的方法来确认什么时候能写完这部分逻辑、什么时候能学完这些知识、服务器的瓶颈如何估计」。现在再想，的确如此。刚上手 Laravel 框架的时候，还带着以前看过几眼文档感到太过复杂的恐惧，只是一点一点地啃，完全没办法预料什么时候能看完且应用到实践中去，所以直到 Alpha 中期我还沉浸在技术文档和开发文档中时，晨瑶问我什么时候能开始实际的代码工作，我说我没办法估计，这可能是一个厚积薄发的过程。因此，预估前进道路上的阻碍十分困难，我觉得可能的解决方式有：
- 问问前人
- 反思做事的方法
- 使用下述的开发计划表格
- Just Do It
B. 在项目初期筹划的时候，虽然我们做了很多工作，比如需求文档，UML 图等等，但是这些材料不够「实用」，令人依然感到难以下手，不知道从何做起。当时看到另一个小组需求文档里的测试表格十分详实，就想着要是我们也有这样的东西就好了。然后就在 Alpha 前期花了大量时间着手做了一个扩充版的开发计划表格：
这虽然耗时很大，但极大程度帮助了我。它是经过大量思考后的结果，能较好地保证业务逻辑上没有问题，开发时依照这个表格将使开发变得有迹可循，快速而有章法（Beta 阶段时间所限没有这个表格就只能上去就是一把梭了）。同时构造这个表也是一个详细的预估过程，能一定程度上解决上面第 1 点提出的问题。再者，API 文档基于这个表格来写也是十分容易。
C. 考虑应当全面周到、不厌其烦。例如，想让一个接口可用十分简单，只要去关注他的正确输入 / 返回情况即可，不考虑它的健壮性。但是如果这个接口在之后的迭代改动较大，现在又耦合太高，怎么办？如果有人基于你提供的 API 对你的服务器发起攻击，影响你的正常业务怎么办？这样的一些「小问题」，我们大可说现在不会遇到，不去考虑解决，又或者时间不够，没办法处理。但我觉得这样不厌其烦的思考和对应的完善措施才是「更上一层楼」的境界。
D. 沟通是第一要义。我觉得，代码能力差，协作不紧密，队员不上心，都不是最根本亟待解决的问题，最重要的事情是沟通。如果一个团队间没有碰撞出来什么思想的火花，那我觉得不如一个人自己开发效率更高。我们进行团队开发的过程中，唯有沟通能让我们及时交流想法，同步进度，定义逻辑，增进情谊。队内要是一片死气沉沉，各做各的，那最后怕是会演变成推锅大会 / 大腿一人 Carry 的场面，项目也一定是难以做好的。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
其实无论对下一届、开学初的我、大一的我，想说的建议意见上面已经长篇大论了很多了。这里再说一个时间的问题，时间肯定是没办法那么充裕的，要抓紧，尽量别狂赶 Deadline，熬夜一般是必须的。
希望下一届的学弟学妹能做出更棒的产品吧。
中途换队员的问题，我很赞同邹欣老师说的换队员是在「追求理想的结果」，这样的做法初衷是好的，但恕我认为它并不够「理想」。这学期换队员的做法是，每个组必须出一名队员和其他组交换，如果没有则强制踢出一个，如果被踢出的队员最后没有队愿意要他，则强制分配。「理想」应该是工作中的样子，工作的确有时候需要你或者队友调换岗位甚至离职，这样的模拟是好的，但是没有人能离职了还能被强制分配到新岗位。同时，工作中你的大部分时间不会被大学里大量的其他课程和活动所占据，你有更多的精力来处理「换人」这件事。另一个角度来说，基于这是一门课的前提，还是选修，如果有人抵触这样的「换人」，觉得接下来的事自己难以完成 / 没有成就感或者其他原因而置之事外，那就得不偿失了，没办法要求他「丢了工作还必须找下一个工作来养活自己」，因为这只是一门课而已。因此这并不够「理想」。
当然，不能说收效甚微，就我们组来说，新进来的队员实力强悍，时间充裕，上手快速，对整个项目裨益很大，同时也相处融洽。
我更赞同的做法是抽签（或者其他方式）选取一些组来强制换队员，剩下的组自愿原则，这样能避免全自愿最后都不愿意换的结果。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了 “创造” 阶段了么？（参考《构建之法》第 17 章 人、绩效和职业道德）
我所处的团队可以说是非常典型的一个团队了——
萌芽阶段，组队时凭着一些随机和兴趣，互相都不了解；
磨合阶段，信任、冲突、承诺、责任、结果，我们都或多或少地经历了，特别是其中的冲突还被记录了下来。。。；
规范阶段，Beta 的团队是较为「规范」的；
创造阶段，有所欠缺，但挺符合的，大家各司其职，井井有条。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量（3 天后能保持 10 - 100 个用户）；而不是:做没有用户使用的软件
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划 / 需求 / 设计 / 实现 / 发布 / 维护，有定时的进度发布；而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有 task/bug 等项目的发展资料
请在随笔中用数据证明上述内容或侧重选择之一。
1. 研发出符合用户需求的软件
当然，我们的 Stardust 是公开发布的、现有 339 个用户（包括测试）、1245 条日记的软件。
2. 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
项目的规划、需求、设计、实现、发布、维护都是作业中的规定并且按时去做的，以及团队合作的过程，在各个记录的博客或者项目主页中可查，Alpha 和 Beta 都还算按时发布了，符合上述要求。
3. 通过数据展现软件是可以维护和继续发展的
