终章 - 软件工程实践总结作业

一、请回望暑假时的第一次作业,你对于软件工程课程的想象

当时正值酷暑,快开学了,在家里也是无所事事,就花费了一些心思写下了那份第一次作业。现在看来,当时的想象还是蛮符合预期的——一门丰富软件工程实践经验、从零经历合作冲突百般荆棘使一个项目开花结果的课程。

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、ShowDocapiDoc

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,它规划任务、时间、文件,使要做的事情清晰、一目了然。

团队开发给了我四点启示。

  1. 预估的能力十分宝贵,我在之前的 Alpha 事后诸葛亮里说「整体来说,最匮乏的是预估的能力,缺少一些有效的方法来确认什么时候能写完这部分逻辑、什么时候能学完这些知识、服务器的瓶颈如何估计」。现在再想,的确如此。刚上手 Laravel 框架的时候,还带着以前看过几眼文档感到太过复杂的恐惧,只是一点一点地啃,完全没办法预料什么时候能看完且应用到实践中去,所以直到 Alpha 中期我还沉浸在技术文档和开发文档中时,晨瑶问我什么时候能开始实际的代码工作,我说我没办法估计,这可能是一个厚积薄发的过程。因此,预估前进道路上的阻碍十分困难,我觉得可能的解决方式有:
  • 问问前人
  • 反思做事的方法
  • 使用下述的开发计划表格
  • Just Do It
  1. 在项目初期筹划的时候,虽然我们做了很多工作,比如需求文档,UML 图等等,但是这些材料不够「实用」,令人依然感到难以下手,不知道从何做起。当时看到另一个小组需求文档里的测试表格十分详实,就想着要是我们也有这样的东西就好了。然后就在 Alpha 前期花了大量时间着手做了一个扩充版的开发计划表格:

开发计划表格

这虽然耗时很大,但极大程度帮助了我。它是经过大量思考后的结果,能较好地保证业务逻辑上没有问题,开发时依照这个表格将使开发变得有迹可循,快速而有章法(Beta 阶段时间所限没有这个表格就只能上去就是一把梭了)。同时构造这个表也是一个详细的预估过程,能一定程度上解决上面第 1 点提出的问题。再者,API 文档基于这个表格来写也是十分容易。

  1. 考虑应当全面周到、不厌其烦。例如,想让一个接口可用十分简单,只要去关注他的正确输入 / 返回情况即可,不考虑它的健壮性。但是如果这个接口在之后的迭代改动较大,现在又耦合太高,怎么办?如果有人基于你提供的 API 对你的服务器发起攻击,影响你的正常业务怎么办?这样的一些「小问题」,我们大可说现在不会遇到,不去考虑解决,又或者时间不够,没办法处理。但我觉得这样不厌其烦的思考和对应的完善措施才是「更上一层楼」的境界。

  2. 沟通是第一要义。我觉得,代码能力差,协作不紧密,队员不上心,都不是最根本亟待解决的问题,最重要的事情是沟通。如果一个团队间没有碰撞出来什么思想的火花,那我觉得不如一个人自己开发效率更高。我们进行团队开发的过程中,唯有沟通能让我们及时交流想法,同步进度,定义逻辑,增进情谊。队内要是一片死气沉沉,各做各的,那最后怕是会演变成推锅大会 / 大腿一人 Carry 的场面,项目也一定是难以做好的。

三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,你有什么想建议和告知的呢?对于后来人的期许。 特别地,特别地,下一届要不要中途换队员?

其实无论对下一届、开学初的我、大一的我,想说的建议意见上面已经长篇大论了很多了。这里再说一个时间的问题,时间肯定是没办法那么充裕的,要抓紧,尽量别狂赶 Deadline,熬夜一般是必须的。

希望下一届的学弟学妹能做出更棒的产品吧。

中途换队员的问题,我很赞同邹欣老师说的换队员是在「追求理想的结果」,这样的做法初衷是好的,但恕我认为它并不够「理想」。这学期换队员的做法是,每个组必须出一名队员和其他组交换,如果没有则强制踢出一个,如果被踢出的队员最后没有队愿意要他,则强制分配。「理想」应该是工作中的样子,工作的确有时候需要你或者队友调换岗位甚至离职,这样的模拟是好的,但是没有人能离职了还能被强制分配到新岗位。同时,工作中你的大部分时间不会被大学里大量的其他课程和活动所占据,你有更多的精力来处理「换人」这件事。另一个角度来说,基于这是一门课的前提,还是选修,如果有人抵触这样的「换人」,觉得接下来的事自己难以完成 / 没有成就感或者其他原因而置之事外,那就得不偿失了,没办法要求他「丢了工作还必须找下一个工作来养活自己」,因为这只是一门课而已。因此这并不够「理想」。

当然,不能说收效甚微,就我们组来说,新进来的队员实力强悍,时间充裕,上手快速,对整个项目裨益很大,同时也相处融洽。

我更赞同的做法是抽签(或者其他方式)选取一些组来强制换队员,剩下的组自愿原则,这样能避免全自愿最后都不愿意换的结果。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了 “创造” 阶段了么?(参考《构建之法》第 17 章 人、绩效和职业道德)

我所处的团队可以说是非常典型的一个团队了—— 萌芽阶段,组队时凭着一些随机和兴趣,互相都不了解; 磨合阶段,信任、冲突、承诺、责任、结果,我们都或多或少地经历了,特别是其中的冲突还被记录了下来。。。; 规范阶段,Beta 的团队是较为「规范」的; 创造阶段,有所欠缺,但挺符合的,大家各司其职,井井有条。

五、怎样证明你学会了软件工程?

1)研发出符合用户需求的软件 必须公开发布,有实际的用户,一定的用户量和持续使用量(3 天后能保持 10 - 100 个用户);而不是:做没有用户使用的软件 2)通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件 有项目规划 / 需求 / 设计 / 实现 / 发布 / 维护,有定时的进度发布;而不是: 通过临时熬夜,胡乱拼凑,大牛一人代劳,延迟交付等方式糊弄 3)并且通过数据展现软件是可以维护和继续发展的。 而不是 找不到源代码,代码无文档,代码不能编译,没有 task/bug 等项目的发展资料 请在随笔中用数据证明上述内容或侧重选择之一。

1. 研发出符合用户需求的软件

当然,我们的 Stardust 是公开发布的、现有 339 个用户(包括测试)、1245 条日记的软件。

2. 通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件

项目的规划、需求、设计、实现、发布、维护都是作业中的规定并且按时去做的,以及团队合作的过程,在各个记录的博客或者项目主页中可查,Alpha 和 Beta 都还算按时发布了,符合上述要求。

3. 通过数据展现软件是可以维护和继续发展的


本文发布于 ladit.me/posts/final-chapter-of-software-engineering-lesson


comments powered by Disqus