惟志惟勤,大气大器

| 这个作业属于哪个课程 | 2021春软件工程实践 S班 |
| :------------------- | :----------------------------------------------------------- | ---------------------------------------------------- |
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 | |
| 这个作业的目标 | 回顾课程、构建之法提问、技术总结 | |
| 其他参考文献 | 《构建之法》 | |

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


一、《构建之法》提问与回答

原博客链接

问题1 编码时间与分析、设计、测试时间分配

问题描述:

  • 为什么有工作经验的软件工程师比学生在“需求分析”和“测试”上所花的时间多,但编码时间短?我们应当怎么去安排“需求分析”、“测试”和“开发”的时间呢?

重新思考:

  • 这学期学习了《软件工程》和《软件质量与测试》这两门课,并且在软工实践中加以总结,我愈发明白了分析、设计和测试的重要性。
  • 对单老师上课所说的一句话印象深刻:好的软件是设计出来的,不是编码出来的。编码只是设计的实践,可能对应这不同的方法,只是设计的实现过程。一个好的设计应当达到以下标准:
    1. 是否能够完成预期的功能;
    2. 是否能够应对潜在的变更;
    3. 是否有很好的可读、可维护性;
    4. 是否具有很好的可测试性;
    5. 是否具有良好的可移植性;
    6. 异常发生后,是否具有良好的追踪、调试性;
    7. 是否在问题领域有非常好的抽象性,具备可复用性;
  • 代码是人写的,有人为的地方就难免有错误。测试能够发现程序的缺陷,获得系统的性能指标等等,是对程序的检验,能够及早发现问题,避免不必要损失。个人觉得,一个企业对测试是否看重,甚至可以作为该企业是否对客户负责,是否有行业道德的判断标准。

问题2、怎么才能避免“为了自己的角色而做绩效优化”?

问题描述:

  • 《构建之法》P321

  • 很多年前,我曾在一个软件团队里负责测试工作,职责之一是编写各种测试用例,以保证系统的代码覆盖率达到80%以上。做过实际项目的工程师都知道,程序里的很多语句是用来处理种种异常情况的,这些情况大多都不会发生。但是若这些语句未被覆盖的话,这个模块的覆盖率就会下降,我就达不到80%的目标。所以我花了很多时间构造各种奇怪的测试数据,把程序中的那些椅角昔兄都尽可能覆盖掉。至于这些椅角春晃在实际中是否会发生,对用户的影响如何,程序是否应该这样设计,我都不太关心。只要覆盖率达到80%,老子的活就干完了!

重新思考:

  • 首先感谢各位老师对此问题的评论点解,然我对这个问题有了更加全面的了解。
  • 每个人都得形成自己的价值判断标准,一件事情在你心中的重要程度,往往取决于这件事情在你心目中的价值地位。有了价值判断习惯,才能不断“回顾初心”,不偏离出发点。并且,需要重全局出发看待问题,避免把大量时间花在局部的最优解之上,而忘记了整体的最优解,典型的“捡了芝麻,丢了西瓜”。
  • 学会计划,大到项目计划,小到个人计划。学会将计划进行分解,才能更好地看出哪个过程是重要的,并分配更多时间;通软件开发一样,设置计划的里程碑,到里程碑要有明确的交付。

问题3、产品经理要不要懂技术?

问题描述:

  • P191

  • Product Manager :产品经理——正确地做产品。目前国内公司大部分PM都是指这个职位。产品经理对一个或多个产品或产品线负责,而互联网产品涉及到这些方方面面:产品定位、市场发展、需求分析、运营、营销、市场推广、商务合作。产品经理横跨这些部门,寻找资源,持续推进产品。随着产品的发展,不同公司,对PM要求会不一样。核心要求是,根据市场和用户需求,协调各部门资源,正确地把握产品定位和方向,解决用户的痛点,持续优化产品。

重新思考:

  • 首先感谢原博客评论区bettermorn大牛的评论、点解
  • 要弄清楚这个问题首先需要明确PM的核心竞争力是什么:"对产品有一种本能的热爱,善于从用户立场看产品,善于换位思考,具有洞察力和判断力,有正确的解决问题的思路和方法。愿意为产品开发投入大量的精力,真诚和公正地对待团队成员,尊重团队成员的意愿,充分信任团队成员,自信,勇于为产品的成败承担全部责任,不找借口。善于理解技术,善于应用技术解决相关问题。擅长优先解决重要问题,熟练、迅速地区分重要任务和紧急任务,合理地规划和安排时间,良好的口头表达能力和书面表达能力,掌握商业技能"(摘自:【新手上路常见问答】关于产品管理)。
  • 所以说产品的核心竞争力并非代码能力,花大把时间在代码能力的提高上显然性价比不高,对个人业务水平提高不大。
  • 但合格的产品必须能够理解技术,指导某一项技术的优势和局限性。保,答应我再也不要出现“变色的手机壳,五彩斑斓的黑”。

问题4、设计产品时是否需要考虑不直接给企业带来利润的用户的体验?

问题描述:

  • P216页

  • Stone网用户画像:

    1.商户:在网站上出售货物的用户

    2.买家:在网站上购买货物的用户,还有越来越多的人通过手机访问

    3.浏览者:在网站上浏览、比较货物,并不购买

重新思考:

  • 对于此问题,同原来思考一样,我觉得应当按实际情况分析。
  • 对于ToB的应用,它的目标用户是非常明确的,用户大部分都是直接给企业带来利润的,所以对于此类企业肯定得以目标用户需求为导向。
  • 而对于以流量为中的网站,主要收入靠广告的项目。则用户对其来说并非直接带来利润的,这是后切勿为了一时“金主”爸爸的打赏,而忽视了用户的使用体验。做得太过于过分,例如广告巨大,各种弹出,则最后会丢去自己的流量。
  • 对于购物网站此类,则应当在满足直接带来利润用户基础上,考虑边缘用户的使用体验,毕竟边缘用户也是可以转换为直接利润用户的。

问题5、什么样的软件工程作业才叫好作业?

问题描述:

  • P37页

  • 很多老师反映软件工程的作业题不好出,学生做的“大作业”也是了无新意,自学软件开发的读者往往也想不出什么有意义的题目来练习。怎么办?师生们身处轰轰烈烈的软件产业大环境,但是在软件工程课上做的题目却是非常简陋,没有起到应有的作用,这的确是一件很有讽刺意义的事情。

重新思考:

  • 此次软件工程实践,个人觉得都挺有意义的。
  • 我认为好的软件工程作业应该有以下特性:
    • 复杂性:考虑不同层度学生的水平,不让学生感到容易,也不让学生感到困难。太过容易没学到东西,等于这次作业白做了。太过于难,容易打击一部分同学自信心,并且时间花费过多,而获得不一定与付出成正比。所以解决这一问题的一个对策就是:基础题+附加题的形式布置作业。
    • 有现实意义:作为一门实践课程,兼并考虑实用性再好不过。如果学生付出很大精力,写出来的东西却毫无现实意义,那难免 心中一万句经典语录。有现实意义的作业也能够激发学生的兴趣和热情,自觉完成任务,而非被迫完成。

是否原来的问题还不明白?如果有,请分析。

  • 对于以往提出的问题都已经明白,暂时没有不明白的地方。

是否产生了新的问题?如果有,请提出

  • 在任何专业皆可转码的年代,计算机专业同学该如何学习才能保持自己的优势?
  • 对于只想从事开发岗(例如:前端开发,安卓开发,java后端……)的同学,读研真的有必要吗?三年经验难道就不香吗?

二、 各阶段收获

需求分析

1、对需求分析有了基本的概念,需求分析的三大目标是:描述用户需要什么;为软件设计奠定基础;定义软件完成可以被确定的一组需求。
2、在软工实践之前,我确定需求的方法往往只是出于自己的想象,主观臆断。在此次实践中,我们先确定的产品的具体方向后,采用了问卷调查的方式去发现潜在用户的痛点,并从中提取需求。并且通过建立模型的方法去确定我们的需求,完善我们的需求。
3、在答辩中,在老师、同学的建议下也逐步完善我们的功能,例如:拉黑、审核……
4、需求分析作为软件开发的第一步,有着十分重要的意义。如果解决的问题是错误的,那么软件再精巧也满足不了任何人的需求。我理解的软件行业是一个服务行业,必须基于用户的需求之上开发。
5、我认为在设计和需求分析中是要考虑到系统的延展性和用户需求变化的。好的架构应该能够在付出较小代价的情况下适应用户需求的变化。

设计

1、在实践过程中对我印象比较深的是:数据库的设计、接口的设计和安全设计
2、在数据库设计上:应该牢牢捉住数据库设计的五大原则:一致性、完整性、安全性、可伸缩性和扩展性、规范化。数据库设计最好是在类图设计完成之后再做设计,根据类图能够很方便地转化为相应的数据库表。并且在设计中也要充分利用工具,我们有用到可视化数据库设计工具(process On,好像是这个)。一来:可视化能够加快设计进度,二来:便于协同设计,最后只需将多张图连在一起,连接好相应表与表之间的关系,就能直接导出艰苦SQL语句了。
3、在接口设计上:接口设计是前后但共同的事情,切勿接口只是单独由一方制定。并且,要注重接口文档的维护,在需要改变接口时要前后端都有人在场。前后端开发都要遵循文档的约定,切勿不看接口文档盲目开发。在接口访问出错时,第一反应应该去看接口文档。
4、安全设计:安全设计直接保障着用户和公司的直接利益。千万不能忽视。安全方面设计也是个吃经验的工作,这方面感谢队友带飞,自己在安全方面就是小白,还需要学习很多。

实现

1、每天的站立式会议一定需要有仪式感,而不是组员之间耍嘴皮子,一定要有Leader主持会议。每位同学轮流介绍进度,安排下一阶段任务,确保项目有序开展。
2、在开发过程中一定要经常翻阅需求文档和设计文档,让自己对项目有更深的理解,防止项目开发偏离方向。
3、对GitHub和Github Project的使用更加熟悉了。
4、个人技术方面,在结对作业和大项目中本人都是担任前端的工作。初次接触前端工程化开发,对以往Web知识有了进一步的加固,并且对小程序开发有了初步的掌握。此外,小程序开发与Vue框架其实有很多相通之处,在两次开发过程中也学会了技术之间的融会贯通。
5、编码一定要遵循项目规定的编程风格,整个项目至始至终保持一致的编码格式。

测试

1、在实践中,自己的心态经历了一个大转变。在学习课程之前,自己也会有编码才是的最重要的,测试算什么的想法。经过实践毒打,真香。还是乖乖好好做测试吧。
2、学会了利用JUnit做单元测试,单元测试是测试的基本单元,是每一个程序员都应该掌握的技能。
3、关于前端页面测试上,学会了用前端测试工具录制和回放,对整个项目进行了压力和性能测试。以前一直不知道前端测试是怎么实施的,这次算是开眼界了咯。
4、作为编码人员应当十分注重自己的编码规范是否符合项目指定的编程风格。
5、此外,还了解了白盒测试、黑盒测试和灰盒测试的相关内容。

发布

项目是小程序项目,接触最多的是小程序的发布。明白了小程序发布流程和审核流程和需要的资料吧。涉及到社交类小程序的发布,最后也是没有成功,小遗憾。下图的证真不好办,。

三、 理解与心得

个人作业心得

  • 在寒假作业(2/2)中不少同学因为编码格式的问题被痛失了很多分数。也从中得到教训,一定要审题,多看题目要求。其实开发过程中也是如此,一定要多翻阅之前分析和设计阶段生成的文档,明确方向,才能又好又快地做出成果。此外,在此次作业中也初次接触了单元测试这一测试工具,在测试中也真正发现了自己程序地BUG,第一次体会到测试的重要性。

结对作业心得

  • 结对作业中工作量大且只有两位同学,而以前也没有太多得接触前端的知识。所以,整个过程还是很艰难的。

  • 面对一项全新的技术,该如何上手学习?

    以往面对一项新技术,自己往往是无从下手,学习效率极低,掌握效果也不好。经过这次结对作业我认为学习新技术较好的方式最有效且最重要的有以下两种:

    • 视频(直观、易于理解)
    • 官方文档(个人认为是最为重要的,也是第一手资料,最直观的想法)
  • 明白了计算机基础知识对编程的重要性。

    在这次结对作业中,我好几个难以解决的bug在结对队友的帮助下都很好的解决了,结对队友有很好的web基础,所以这也让我认识到计算机基础对编程的影响。

    例如:

    • 只有了解了axios的内部访问机制是多线程的,才能更好地组织代码架构,让代码更高效。
    • 面对跨源访问401问题,结对队友能很快意识到这是cookie的问题,在远程电脑上保存的cookie并不会被传送到服务器上,所以自然没有权限访问。之后队友一波设置电脑host,将远程服务器映射到本地,就解决了。
    • 此外还有文件夹命名中含有“&"的解决方案,队友解决过程命令行一堆,实在看不懂,我只能直呼内行。

团队作业心得

  • 明白了软件开发过程有:需求分析、概要设计、详细设计、编写代码、软件测试和运行维护这么多阶段。以前自己所看重的编码阶段往往不会超过全部项目时间的30%,也让自己学会其它阶段的知识并加强学习,编码能力只是软件能力的一部分罢了。
  • 以往自己做事总是急性子,巴不得立马做完。在这次团队作业中,自己在前期工作中过度追求速度,而导致了很多BUG,例如:alpha阶段那个不能点的头像组件。在后期也吸取了教训,对待工作更加细致沉稳了不少,当然产生的bug也少了许多。
  • 在alpha阶段和beta阶段中,我们采用了github project作为我们的管理工具,并且每天举行站立时会议,了解项目进度,对整个项目的有序进行起到了很大的作用。验证了“凡是预则立”。
  • 此外,也认识了一群志同道合为一个共同目标前进的好友们,感谢他们一路的陪伴,到最后也算是到达了我们的预期。
  • 个人技术方面:从0开始学微信小程序开发,自我感觉应该算是入门了吧。

第二部分:个人技术总结

  • 在准备篇中我为自己定制了学习机器学习的学习路线。在本学期,着重复习了数学基础。对python语法也有进一步加强。但是由于精力有限还没有深入得学习pytorch框架,目前正在找时间尽快补上。

技术博客链接

概述

  • 介绍:Promise用于处理小程序中的异步问题
  • 学习该技术原因:项目中很多地方需要用到异步操作,例如:只有当用户登录之后才能去访问其它接口,不然无法访问;我们为图片上传定义了单独的接口,当需要发布文章是,需要等所有图片上传之后得到图片的Url再调用发布文章的接口……
  • 技术难点: 提取项目中的异步关系

posted on 2021-06-28 11:57  DemoJi  阅读(135)  评论(4编辑  收藏  举报

导航