一只阿宅码农的奇妙冒险

221900330_詹鹏翔学生 2022-06-22 07:26:06

这个作业属于哪个课程	2022年福大-软件工程;软件工程实践-W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	课程回顾与总结,个人技术总结
其他参考文献	csdn，构建之法

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

以前提问题的博客链接

博客链接

对曾经提出问题的解答

问题1
- 对于一名工程师而言，究竟应该是更”专“一点好，还是更”广“一点好呢？原问题链接
- 过去回答：在我看来，我觉得更”专“一点比较好，只有深入学习一门技术，才有可能能熟练运用它，否则很可能只停留在皮毛阶段，当然，这也不是说只学一门技术就好，在学好一门技术后，去了解学习其他技术也会更快，可以比较两者的优劣之处，更有利于学习
- 现在回答：时至今日，我依旧认为，技术需要专精，人的精力是有限的，不可能同时专精太多门技术，比方团队作业中，前端后端都会一点但不深入的成员可以临时救急负责一些简单的工作，但是终究不可能作为负责人使用，有所取舍，才能走得更远。
问题2
- 应该在什么时候使用goto？原问题链接
- 过去回答：goto容易造成包含分支和循环结构的程序逻辑混乱，所以在学习语言时老师都建议尽量避免使用，我认为在团队开发中goto会增加代码的理解难度，能不用就不用。
- 现在回答：如果不考虑汇编语言（goto都要写high了）的话，目前我依旧很少使用goto，《构建之法》中曾提到“函数最好有单一出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto”，在我的理解之下，无论是使用什么方法，只要能保证程序逻辑，goto也可以使用，不过是一种方法罢了。但是一般用上了goto，一个控制不好，程序逻辑反而会更加混乱。
问题3
- 开源项目的商业价值如何体现? 原问题链接 https://bbs.csdn.net/topics/600465548)
- 过去回答：开源项目意味着能有更多的人可以了解或参与该项目，巨大的流量本身就意味着盈利，只要有足够的用户，自然会有相应的变现方法，出售书籍，官网广告等等。
- 现在回答：说实在，以前我以为开源项目只要做的办就一定有办法盈利，但是现在我不这样想了。前些日子faker.js 开源作者因为一直被白嫖，甚至连一个20万美刀的offer都搞不到，一气之下删除了所有的代码。我开始重新理解两者之间的关系，开源软件并不意味着免费使用，faker.js 的商业价值价值很高，但是作者却几乎没有什么收益。因此，我认为开源项目应该有最起码的要求，你可以获取源代码，但是必须付出一点的代价，可以是宣传，也可以是金钱。否则最后怕是演变成人人白嫖，作者扑街无人问的局面了。
问题4
- 好的用户体验当然是所有人都想要的，如果它和产品的质量有冲突，怎么办？牺牲质量去追求用户体验么，用户能接受吗？原问题链接
- 过去回答：我觉得看情况，用户体验是一个很主观的概念，一千个人眼里有一千个哈姆雷特，一个产品注定不可能让所有人满意，在一些不重要的产品质量点上我觉得可以适当牺牲来获得更好的用户体验，但在一些重点功能上应当无法退让。
- 现在回答：经过这一个学期的学习后，我有了新的感悟，这种问题极端肯定不对，大多数人都会选择平衡中庸之道。但是哪有那么好中庸呀。说白了我们只是开发者，我们和用户的立场肯定是不一样的，产品的最终使用者是用户，用户是上帝嘛，因此必须获取到产品使用用户最多群体的意见，在数据的支持下，无论是追求质量还是追求用户体验，我认为都是对的
问题5
- 专业性产品是否需要考虑非专业类人群客户？原问题链接
- 过去回答：我觉得可以这样理解，针对非专业人群，可以设置新手指引，比如在idea等软件中，在初次使用中会进行新手指引，解释一些功能，同时专业人群也可以直接跳过新手指引。在满足专业功能要求的情况下，考虑非专业人群，个人认为对产品的推广有利无害。
- 现在回答：和上一个问题有点像，我认为，所有产品都需要做到以人为本，专业性产品的目标就是专业性用户，把非专业类人群客户考虑进来只会降低数据的精确度，到最后可能得不偿失，在满足目标用户的需求之后可以进行一定的扩展，但是一旦会影响目标用户的需求，我会果断选择放弃非专业类人群客户。

每个阶段中收获最大的知识或能力

需求阶段
- 应该是NABCD的模型这个需求分析方法，根据一句虚幻飘渺的概念就做出一个产品是不切实际的，通过Need明确需求、Approach确定产品实现需求的方法，Benfit再一次确定了该产品的优点好处，Competitors了解竞品与自身的优劣，Delivery推广产品。通过这个方法，我删除了我存储的很多产品idea（~~发财梦想破碎了......~~），但是也从中提炼出了一些有意思的想法，依我之见，NABCD模型是让每一个幻想落地的第一步。
设计阶段
- 其实所有设计都是在围绕功能来进行，先采用自顶向下的方法划分功能结构图。之后所有设计都是在围绕功能结构图划分。无论是类图、UI原型设计、数据库设计等等，都离不开这个基本骨架。因此骨架必须要稳当。最好可以留下一定的可扩展空间，否则后期返工，将是一个非常绝望的过程
- 此外，印象最深刻的应该是第一次认真设计了一个数据库的中继器，发现了很多以前没有想过的问题，比如中继器的循环问题等等
实现阶段
- 作为组长，实际上我后端Spring boot 和前端React Native代码都有参与代码编写，中间有许多收获，比方说后端文件上传的缓存路径问题，WebSocket连接问题，React Native 地图定位等等......其实代码本身的收获在于其次。印象最深刻收获感觉最大的应该还是去统筹调度，确保大家的开发进度，可以体验组长的责任与快乐（and绝望、崩溃、秃头）。
测试阶段
- 最大的收获应该是一句话：人和人的区别之大超乎想象，我一开始设计的是按照模块测试、接口测试、整体测试，后面我发现不行，因为开发者本身很难测试出来bug，然后我们采用交替测试的方法，他们突然好像变性了一样，感觉潜台词就是：“你要是能测试出我bug，那我也一定能找出你的！”，结果好家伙，修完3个bug，来7个bug，修完7个来12个，那几天全组人员都弥漫着一种痛并快乐的氛围中
发布阶段
- 所有项目的部署都是由我来完成的，后端Spring boot和web前端的部署没啥好说的，打包扔到服务器上就行了(web前端谨记几个大字——防火墙！)，比较有意思的应该是React Native 的部署，设置密钥再打包，不同的android版本还可能不能兼容，需要修改一下android源代码
- 用户调研阶段其实挺有趣的，很多有意思的反馈，比如游戏性不够可以添加相互扔鲜花和臭鸡蛋等设计，果然群众的智慧无极限，感觉要是之后有机会，可以去实现一下这些好玩的设计

理解或心得

个人项目
- 个人项目对我来说其实是最麻烦的，因为它就像OJ一样，有过测试用例的需要，而且它又不像是OJ，可以直接提交上去立刻知道accept还是WA，需求博客里面也有很多地方讲得迷迷糊糊的，我只能不断在群里问，有哪些特殊情况，比如换行、乱七八糟的输入等等，和自己预想的不一样又要回去改代码，真心希望这一点可以进行改善，在这种地方花时间改代码真的很没有意思
- 好玩的地方应该是性能优化这一块，第一次使用了JProfiler性能测试工具，才发现自己非常希望new变量，导致GC回收占比贼高，非常影响运行速度
- 第一次使用PSP表格和git工具，PSP表格手动输入，预计耗时和实际耗时还是有些不够精准，上网找了一些计时工具感觉还不错，git工具提交回滚都很方便
- 单元测试需要多练，一个良好的单元测试，有助于代码正确性的提高，降低耦合度
结对编程
- （来自当时的博客-原型设计）第一次体验结对作业，感觉还不错，虽然在开发过程中需要时时讨论统一观点确定进度，对双方的默契配合要求很高，但同时这也让我发现了许多平时一个人根本没有留意的问题，比如图表的随意使用，图标的滥用等等，总的来说，是一次很不错的开发体验，期待下一次的结对编程能配合的更好
- （来自当时的博客-正式开发）工作量比预想的大了好多，结对的麻烦事也多了很多，什么更新失败，提交不上去，明明是一样的代码，在队友那边就是运行不起来，及其玄学。在这次结对中，对git的使用熟练了好多，之前都是在dash上输入的，现在直接使用idea这些编译器提交贼快乐，也锻炼了我找bug，与人沟通的能力（~~熬夜能力~~），希望之后的团队合作作业能让我发现自己更多的不足
- （现在）其实现在仔细回忆当时的开发，我在其中应该是作为一个主导的位置，我很想再和我的队友说声对不起，第一次和别人合作开发代码，我总是下意识把自己的习惯套用在别人身上，来活了就玩命做完再说。这其实非常不合理，我们是团队合作，不是组团卷到阎王殿，我有什么资格让每个人都以我的开发进度去开发，一个弹性的开发进度应该是要适应每一个成员的，这次结对编程也为我之后的团队开发试了一遍水，发现了自己很多的不足，再次为自己那时的不成熟向我的队友道歉，对不起，你真的已经很棒了(๑•̀ㅂ•́)و✧
团队项目
- （之前的每个阶段的心得体会在每次团队博客里，可以直接去查看，以下仅介绍当下的心得体会）
- 我是组长，相当于一艘船的船长，我得保证每个船员都在合适的位置，保证船不会开进沟里......以上是我曾经对组长的幻想，在本次的开发中，我需要负责的东西包括成员分工、小组评分、每日汇报、后端代码基本框架及编写、前台app的基本框架编写......，有点像是文职+开发码农的融合体，还好设立了一个PM来负责一些博客、每日会议之类的事务分担了我很大的压力，平心而论，我可能更像是开发组组长，有关代码的工作可能我更为擅长，而像是上台发言等，很多次都因为我的失误给小组带来了不必要的扣分，再次我向我的小组成员致歉
- 项目冲刺共分为两次，因此对于项目的可扩展性就更显得重要了，第一次在完成基础的基础上一定要确保项目的可扩展性，为后续的功能增加减少时间。
- 作为一个前后端项目，相比于正式的代码编写，前后端的事前沟通显得更加重要，一定要保证每个接口设计都是有前后端成员共同认可过的，前端后期发现接口有问题需要改，真的很耗时间
- 只有前期准备做充分了，后期的开发难度将会大大降低，以及要确保每一位成员都要达成共识，否则最终成品会走样严重
- 开发周期的问题上文也说过，在具体的开发中，有小组成员觉得我们冲刺时间严重不足，也有人觉得我们应该尽早开始冲刺，可以说是各有个的想法。此外，你永远也不会知道，在实际开发中你会遇到多少难缠的bug（比如我们Beta冲刺爬取教务处发现一个SSL验证的问题，差点实现alpha冲刺完成、Beta冲刺报废的传奇......）因此，一个弹性的开发时间就显得尤为重要

自我评分

目标1： 理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。
目标2： 掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。
目标3： 掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。
目标4： 能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。
目标5： 遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。
目标6： 具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。
目标7： 能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。

目标	分值（百分制）	理由
目标1	90	有关软件工程师的职业道德规范和实践要求，在实践开始之初就已有初步了解，遵守公民道德规范标准和中国软件行业基本公约，良好的团队协作精神等等；自认为目前开发的软件产品都具有积极向上的软件开发理念
目标2	85	在需求分析过程中，我根据NABCD模型的理论，将原先抽象的概念（用游戏形式进行学习比拼）进一步细分，总和大家意见，明确用户所需的各种需求及功能（联机/单机自习，数据分析，自习地图），并在其中熟练的使用了Xmind等工具进行逻辑梳理，制作NABCD模型，但是对系统流程图，数据流图，数据字典等需求表达工具的使用略为生疏
目标3	90	作为组长自认为算是较为深刻地接触了软件开发的全过程，负责用例图，类图，流程图，数据流图等的评审并提出修改意见，保证项目体系结构设计方法和基本设计原则
目标4	80	优选设计方案方面，小组内部在需求分析的原型设计部分曾进行过海选设计风格和草图评审等，最后我遗漏了一些成员草图设计的不合理之处，导致后期工作量的增加
目标5	90	曾在个人项目阶段和结对编程中负责过代码规范文档，团队作业中编写过需求分析文档、系统测试报告等，同时负责审查最后的文档，文档撰写方法自认为已经有所掌握
目标6	90	在团队合作中担任组长角色，使用Teambition、在线文档等方法组织、协调或指挥团队开展工作，负责和各位成员交流，确保软件开发进度，自认为组长工作完成度还不错
目标7	90	在整个项目管理中，采用Teambition+在线文档每日汇报的方式进行项目管理，在项目开始前会与PM就每项任务的难度和比重进行商讨，项目开发中，担任后端负责人的角色，同时也负责帮助前端代码的编写