美丽再度来袭—软工实践美丽全回顾

这个作业属于哪个课程 2021春软件工程实践 W班 (福州大学)
这个作业要求在哪里 软件工程实践总结&个人技术博客
这个作业的目标 课程回顾与总结
其他参考文献 过往发表过的博客

目录

为啥我要起这个标题

  • 本人曾在团队展示说过
    • 本美女要slay软工这条街，靴靴
    • 注：slay指一个人非常的厉害，带有秒杀的意思，软工这条街指软工实践。
    • 我觉得本美女可以改成本小组了，因为软工实践能取得这么好的成绩并不是我一个人的事，每个人各司其职，胜利便近在咫尺。
  • 美丽再度来袭指软工实践很好的完成了所以很美丽，再度是我调皮加上去的。
  • 软工实践美丽全回顾，有回顾、反思、怀念的意味。

问题回顾

寒假作业二要求你在快速阅读《构建之法》后，列出仍然不懂的5到10个问题。现在的你对这些问题有什么新的看法吗？

问题一

过早优化、泛化是思维误区，但是我感觉等整个项目代码都敲完再去优化的话会有一种牵一发而动全身的感觉（优化了某一部分的代码导致其它地方出现问题），那么优化最好的时机是什么时候？

  • 在实践过程中，我认为只要把代码规范和注意事项列清楚，就很少会出现低质量的代码需要去优化，那么就说明了其实优化最好的时机就是在前期准备工作阶段（需求说明、概要设计、详细设计）。毕竟常言道：好的开始是成功的一半！
  • 的确有时候难免会出现一些错误，但我的答案是等整个项目代码都敲完再去优化！（不是太严重的缺陷，例如规范、报错不影响使用）。功能优先！！！

问题二

就一个团队而言，每个人的工作都应该是要并行的吗？

  • 是，假如前端都要等后端接口写完了才去写页面的话（ 面向接口编程），效率会大大降低。
  • 正如老师所说(详见评论区回复)：
    • 要接口定好了，才能并行。前端也是如此，现在前端也有三层框架，跟后端的接口确定好，UI设计的改变不影响后端的实现，可以去了解一下。
      • 之后在结对作业二的时候就用上了接口文档和上述老师提到的解决方法啦！
  • 参考结对作业二感想:
    • 我的收获在于，我记得我在寒假作业中提过前后端如何并行开发的问题，这次也是实践写了接口文档解决了一下，提升了一下效率。

问题三

想在程序里加点需求没有提出的功能是否妥当？

  • 其实提出这个问题是偶尔在编写程序的时候会有各种奇思妙想。
  • 个人现在认为不妥当，不要平白无故给自己加工作量，不然最后反而会拖慢开发进度，而且客户也未必想要这个功能。

问题四

互联网行业发展十分迅速，在进行技术选型的时候，我们应该选择稳定的技术还是有小风险的最新的技术？

  • 参考alpha冲刺总结：
    • 技术选型很重要，遥想起我在寒假作业一曾提过“互联网行业发展十分迅速，在进行技术选型的时候，我们应该选择稳定的技术还是有风险的最新的技术？”这个问题，现在我能很肯定的能回答了，就是选用稳定技术......
    • 选用稳定的技术意味着能找到很多相关的资料，遇到问题很容易就能解决，而且不容易出错，这次就踩了坑，选用了highcharts没有使用echarts（现在已经部分替换过来了）。
  • 万万没想到在beta冲刺的时候再踩了同样的坑：
    • 使用videojs的时候，NPM包安装后，里面的一些依赖文件找不到路径，去不同的地方找解决方案都找不到。
    • 考虑到如果在这一部分太耗时间的话会拖慢开发进度，所以我决定改用以前使用过的hls.js。
  • 我的结论：
    • 新的技术可以尝试，根据项目进展和总开发时间给自己一个合理安排规定的时间（例如一天到两天）去学习，如果在这段时间没搞懂或者有BUG解决不了的话，最好使用自己经验丰富（稳定）的技术去替代（为了不拖慢开发进度），有余力才去考虑新技术。

问题五

关于结对编程，这会使得参与的成员压力过大，导致反作用吗？

  • 虽然我在寒假作业的回答有表达自己的一些顾虑：
    • 结对编程有全天候注视自己的队友，会感到压力，灵感也会少很多。
    • 有时候我编程的时候遇到难题，我会让自己离开电脑一段时间，如何就会有灵感，茅塞顿开了。
    • 而且俗语也有说一山不容二虎，队员可能会因为一些问题产生矛盾。。
  • 但总体来说，实际结对起来真没啥压力，一直谈纸上谈兵可不行，要实践之后才能有发言权！
  • 参考第一次结对作业感受：
    • 我认为结对十分有趣，以往都是单独独斗，现在多了一个人在身边给意见让我轻松很多，遇到困难的时候我并不是一个人，因为我有伙伴可以交流

问题六

要怎么避免项目上线前一天要通宵的现象？该现象是一种没有效率的表现吗？

  • 是的，毫无疑问是一种没有效率的表现。
  • 因为这次软工分alpha冲刺和beta冲刺都没有熬过夜，归功于PM（琨琨）的合理安排时间和任务才让这个团队顺畅的运转起来，效率最大化，火力全开~！！

问题七

团队中有能力很强的人，一个人能顶所有人的活（明星模式），导致其它人无事可做、积极性低，如何解决这种问题？

  • 能力强的人更加应该要知道什么工作是难的，什么工作是容易的。如何去分解任务给组员去做，而不是一个人埋头苦干，也是对能力强的一种体现。
  • 就拿我这次软工实践为例，我自己是前端组长，说实话组员能胜任的工作我全部都能搞定（我没有自己夸自己！！！），但是我需要把组员们动员起来，自己把工作全部包揽起来让组员划水是极其不负责任的表现。给不同能力的组员分配不同的任务，让他们成长起来，提升开发效率和参与感才是首要目的。

做中学

软件工程这门学问有很多 “知识点”， 这门课强调 “做中学”——在实践中学习知识点。

请问你在项目的需求/设计/实现/测试/发布阶段（一共5个阶段）中，每个阶段收获最大的知识或能力是什么？

需求

  • 其实最初要做电动车停车识别是我的奇思妙想。这门课程让我学到了在需求分析的时候并不是写完需求分析报告就可以收工，还要进行需求评审（比如答辩）。邀请专业的评审员（老师、助教、其他组）可以更好的帮我们发现需求分析中的错误，避免后期进行测试或验收时的出现问题再改。
  • 如果上述的过程要用一个专业名词去形容的话，我会用我在《软件质量和测试》学到的W模型去描述。的确，软件实践这么课程就是实现了软件测试的W模型，符合了”尽早地和不断地测试的原则“（每个阶段都有对应的答辩）。

设计

  • 在没上这门课之前，我认为设计只指原型设计（觉得只要把界面做出来就差不多设计完了，其他细节编码阶段再想），没想到也包含了项目系统设计、数据库设计。这能让我做软件项目的时候有更好的工程化思想、更好的”大局观“。
  • 另外我也做了大胆的尝试，针对Vue这个框架每个组件都可以拥有属性和方法的前提下画出了类图，在编码（实现）阶段的时候跟着类图一个一个去实现是十分舒服的事情。要类比的话，可以是做房子中的蓝图，只需按部就班就能有很好的效果。

实现

  • 在实现过程多了很多对以前寒假作业提出的一些问题的反思（详看上面问题回顾）
  • 在这次的软工实践我也明白了团队协作的重要性，以往的我都是在前端自己一个人单打独斗，有了伙伴，他们得意见使我可以知道自己哪里可以做得更好，也提升了开发效率。
    • Git这方面我也学会了冲突解决和合并，以往我都是commit、push就完事了，现在多学了一些，相信以后工作肯定会用到！
  • 一些在《设计模式与软件体系结构》课上学到的知识也派上用场了，比如说接口整合起来成为一个类就是外观模式。

测试

  • 《软工实践》这门课可以说是集大成之作，基本上所有软件工程专业课的知识都用上了，既然是这样，那就不得不得提《软件质量和测试》这这门课。
  • 《软件质量和测试》这门课教会了我们黑盒测试、白盒测试、集成测试、系统测试，没想到测试居然有这么大的学问。以往我的测试方法都是对GUI进行测试就草草了事，硬要说的话就是系统测试的一种手段。通过《软工实践》这门课，的确让我在《软件质量和测试》这门课知识得到了发挥。
  • 让我印象最深刻的是系统测试中的自动化测试，利用Selenium IDE进行Web界面的自动化测试。
    • 当时我在想居然会有这种操作？？！！看来程序员真是一个需要终身学习的职业，有很多领域的知识都需要我们去挖掘、去学习。

发布

  • 其实我觉得每次alpha答辩和beta答辩都像是一次“产品发布会”，要聆听同学和老师的意见，做出相应的改进。
    • 问卷调查也是一种非正式的软件评审方法，这是我在《软件质量和测试》这门课学到的，又派上用场了，哈哈！
  • 另外，部署这件事最好就是完成一个功能点就去做，这样可以让团队成员及时测试，把粒度控制得小一点，排错也比较容易。

项目经历之理解与心得

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

个人项目

  • 主要参考寒假作业2/2心路历程与收获：
    • PSP表格的应用。
    • 个人项目主要是学到了单元测试。
    • 一个很重要的概念就是客户的需求，一定要弄明白需求，才能进行后面的编码工作。
    • 那时候不知道为什么不用正则表达式去完成WordCount这个程序，反而是自己写很长的判定语句，现在看起来太笨了，不要做重复做轮子的事情！！！

结对编程

  • 首先很感谢老师和助教的宽容，结对二的时候我的小组deadline赶不及，完成度只有70%左右（个人认为），但仍然打了82.5多分，说明了只要用心做老师和助教一定不会亏待我们的！

  • 结果不重要，重要的是过程。

    • 结对一中，主要做的是原型设计，在这过程中，创新的使用了一人分享屏幕进行原型设计，一人观看并参与设计讨论，在工作一定时间后，交换双方角色。这样可以做到工作的无缝衔接，保证了双方的工作效率。（参考结对作业一)

      • 解决方法总比困难多，不要想着偷懒！虽受制于疫情，但也很好的完成了原型设计！

    • 结对二中，主要做的是编码实现，在这过程中，我学会了有些事情一定要有所取舍，做不到就要放弃或者找替代方案，不然会拖慢开发进度。

      • 没有任何事情是十全十美的，有时候有学会和自己和解，不要纠结太多。

      • 因为是我追求完美的态度反而导致了完成度不高，所以我对这个印象很深刻，下次不会再犯同样的错了！！！完整度优先！！

团队项目

  • 大多数的意见都在问题回顾和做中学提及，这里就不再复述。
  • 每个人各司其职，胜利便近在咫尺。
    • 团队中的每个成员都是不可或缺的，正正是因为PM承担了大部分文档和开发计划安排，前后端的组员才能安心、舒适地开发。
  • 一定要根据开发时间去构思一个项目，而不要反过来把项目架构弄得太大（比如说功能很多），或者俗称：饼画大了。
    • 其实一开始我也有去想多添加一些功能，但仔细考虑后，如果加入了的话很可能没法按时完成整个项目。
    • 根据我的观察有些小组好像有点烂尾，这就是饼画太大的下场。

个人技术总结

小程序地图(Uni-app)与前端缝合(Vue)的尝试
概述：鉴于组员已经在小程序端（Uni-app）写好了地图组件，我就想要拿来给后台的前端复用，没想到出现一些出乎意料的情况，最后只好使用高德地图复现一下小程序端上的地图。

posted @ 2021-06-26 17:33  CLH029  阅读(148)  评论(4)  编辑  收藏  举报