观往知来

这个作业属于哪个课程 2021春软件工程实践|W班(福州大学)
这个作业要求在哪里 软件工程实践总结&个人技术博客
这个作业的目标 回顾与总结课程、分享技术
其他参考文献 《构建之法》

目录

第一部分：课程回顾与总结

以前提问题的博客链接

https://www.cnblogs.com/c---jx/p/14460056.html

对以前问题的解答

  • 问题一

    • 问：如何保证PSP估计数据准确呢？
    • 答：当时我的想法是根据不同的项目，适当修改PSP的表格的项，毕竟一张PSP表格并不能使用在每个项目中。现在看来，这种方法确实有效，但在后面的alpha、beta开发过程中发现，每天的任务都有详细的规划，可以使用自底向上的方法，之前对任务进行PSP估计是对一整个任务进行估计，并不能很好的掌握各个部分的时间，但将一整个大任务分成一堆小任务，再对每个小任务进行PSP估计，最后再合并，估计出来的数据就会更加准确。

  • 问题二

    • 问：过早优化是不好的吗？
    • 答：在之前的寒假作业中，感觉似乎过早优化并没有什么不好的，当时并没有体会到书中所说对一个模块大量优化，无视这个模块对全局的重要性，但到了后面结对、alpha、beta就感觉到过早优化的弊端，比如在beta阶段，我做了一个检验网络状态的提示框，我花费了很多时间去让他的动效看起来更加的流畅、舒适，但到了用户调研的时候，大家对这个模块的评价并不高，认为并不是很有必要，而且很消耗网络资源，最后只能删除了这个模块。我觉得过早优化确实没有必要，尤其是在你没有认清这个模块在全局的重要性时，过早优化可能会让你花费大量时间去做了无用功。

  • 问题三

    • 问：怎样可以避免组员“摸鱼”而导致团队项目开发进度被拖慢或者说怎样提高组员的积极性？
    • 答：这点我觉得我们小组做的还是不错的，在alpha、beta阶段没有出现团队成员脱后腿的情况，我们团队是通过将总任务划分出各个小的子任务，根据团队成员的自身能力，自己来挑选任务，并且任务的多少也会影响最后的贡献度评分，这样每个组员不会因为自身实力不足，而消极怠工拖慢进度，而且我们前端组、后端组也有分组长，可以帮助实力较弱的组员解决困难，贡献度制度也能很好的提高组员的积极性。

  • 问题四

    • 问：怎么能判断出深度面谈所获得的需求一定会适用于大多数人呢？
    • 答：这点在当初还挺疑惑的，认为每个人对于需求的感觉是不同的，可能有的人觉得这个功能好，有的人却觉得这个功能很碍事，但到了beta阶段的用户调查时才发现大家的需求其实都是比较类似的，往往大部分人都会有着同样的需求，比如在问卷、一对一私聊中，很多同学都反馈检验网络状态的提示框比较碍事，而且很消耗网络资源，而在我们团队成员评估后，也觉得这个功能应该删除，我觉得用户的需求都是有一定共性的，将深度面谈中出现概率比较高的需求解决了，这些需求也基本上适用于大部分人。

  • 问题五

    • 问：如何能更好平衡产品质量和用户体验呢？
    • 答：我觉得网上的这句话说的很好，用户需求是根本，在用户体验这个问题上，还要特别考虑到短期刺激和长期影响，在必要的时候我觉得可以牺牲软件质量去追求用户体验。，而《构建之法》P260的这个例子我在beta阶段深有体会，一开始在做用户头像的上传功能时并没有对图片进行限制、也并没对头像进行压缩，导致在后端返回图片时，图片太大，在加载的时候加载太慢，每次显示一张图片都需要好久，往往一个页面里有五六张头像，一加载都是一半一半的，极大影响了用户的体验，后面为了解决这个问题，将图片上传的大小进行了限制，并且上传完还进行了压缩，图片加载速度得到了很大的提升。

每个阶段收获最大的知识或能力是什么

  • 需求

    • 学习了使用NABCD的模型进行需求分析，进行分析N时，应当记住用户并不是需要产品，用户需要的是解决痛点的方案；在分析C时，应当综合市面上的同类产品，要看清楚自己产品的优势在哪、劣势在哪，使用自己的产品相较于竞品好处在哪。这些都需要综合的考量，并适当更改自身产品的需求。

  • 设计

    • 在系统设计中，对于功能模块的划分可以采用自上而下的层次化的划分方式，可以根据需求分析所得到的结果，先确定几个基本的功能模块，再根据具体的需求，例如原型设计中的UI，来确定其中每个大的功能模块下更小的子功能模块。

  • 实现

    • 学习了使用react + antd-mobile 进行web移动端的编写，对react的使用和web移动端的编写更加熟练了，尝试了许多自己之前没有接触过的技术。对于时间管理、沟通能力都有了比较大的提高。

  • 测试

    • 因为我们小组做的是web移动端，所以要兼容不同机型，在这个阶段收获的最大的知识就是不要只在浏览器测试，多真机测试，比如项目中在页面中使用了vh这个单位，在浏览器测试是不会弹起手机软键盘的，而在部分机型中，弹起的软键盘会更改视口高度，由于设置了vh会导致页面被压缩，但这只有在真机测试的时候才能发现。

  • 发布

    • 团队作业的部署不是由我完成的，但在结对作业项目的部署中，第一次学习了服务器的部署，学习到了在部署服务器、配置环境时一定要认真一步一步的按照教程了，稍有不慎，就很容易前功尽弃。而且一定要给自己预留时间，毕竟感觉自己每次部署都会遇到不同情况的bug。
    • 接触学习了用户调研，也第一次体验了根据调研得到的用户反馈，对项目的功能进行修改。

理解与心得

  • 个人项目

    • 通过PSP表格的预计耗时和实际耗时能很清楚让自己认识到预计与实际的差距，以便自己对项目开发进行审视，方便自身的提高。
    • 要认真理解项目的需求，对每一个要求都不能马虎，比如要求的输出格式等，不然就很容易前功尽弃。
    • 在这个阶段学习了单元测试，之前并没有体会到它的优点，进行单元测试可以让自己的代码更为可靠，更好的减少bug，并且通过观察覆盖率可以优化自己代码，减少冗余代码。
    • 就像老师所说的，对于每个函数、功能要尽量考虑它的扩展性，说不定就能用到以后的项目中去。

  • 结对编程

    • 第一次正式的进行结对编程，两个人一起进行讨论，一起编程，明显能感受到1 + 1 > 2，更多的是良性的作用。
    • 结对两个人实力有差距时，实力强的同学可以多帮助实力弱的同学，实力弱的同学遇到问题也应该积极讨论，这样能使项目计划能更好的稳步推进。
    • 在使用git进行代码管理并不熟练时，最好在每次进行操作前，将代码复制一份，避免因为操作不熟练而导致代码被覆盖，一天的努力白费。

  • 团队项目

    • 对于项目的某些模块，一定要评估好它的优先级，避免浪费太多时间到优先级不高的模块，导致项目进度被拖慢。
    • 前后端之间的沟通是很重要的，若是后端接口需要修改，应该第一时间通知前端并修改接口文档，避免后面找bug浪费太多时间。
    • 还是前后端沟通问题，相较于打字沟通，通过语音沟通能更好的解决问题。
    • 一定一定要给每天的任务留下预留时间，毕竟有的时候出现的bug，可能需要很久的解决时间，这样能有效防止项目进度被拖慢。
    • 如果做的是web移动端项目，一定要记得在调试时，不仅仅需要在浏览器中调试，更需要进行不同机型的真机测试。也许在浏览器上没问题，但在不同机型的手机上就会出现各种奇奇怪怪的问题。
    • 项目做一点就应该部署一点，不要等到写了很多才开始进行部署，本地测试可能没问题，部署上去就会出现一些bug。
    • 网上博客讲的不一定是对的，即使很多讲的都是一样的，尽量多去看看官方的文档，不要因为全是英文就产生抵触心理。

第二部分：个人技术总结

博客链接

react-cropper + lrz 实现头像裁剪压缩上传

技术概述

市面上的大多数社交软件在进行头像上传时都有裁剪的功能，通过react-cropper可以对用户上传图片进行裁剪，通过lrz来对用户上传的图片进行压缩。

posted @ 2021-06-28 09:44  AAAdmin  阅读(121)  评论(7)  编辑  收藏  举报