软件工程实践总结——手持两把锟斤拷，口中疾呼烫烫烫

222100121洪恒辉 2024-06-04 14:46:37

这个作业属于哪个课程	2302软件工程社区
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	实践总结
其他参考文献	CSDN、《构建之法》

一、课程回顾与总结

1.1 温故知新

1.1.1 当时的博客

1.1.2 再回顾
问题一：AI辅助编程，是一个银弹么？

原回答：

使用AI辅助编程在我看来是未来程序员必备的技能之一了，我个人也尝试过各大平台开发的代码辅助工具，虽然现有许多框架基于“约定大于配置”的理念开发了已经相当完善的代码生成器，但就我个人的使用体验来看，AI的使用赛道并不同于此，而是更偏向于思维启发和小规模的定式代码生成，比如说对于一个项目开发中途遇到问题，可以询问AI解决思路。还有就是现在用得最多的小规模的定式代码生成，无论使用的代码生成器多完善，业务代码总归还是要程序员来编写的，在业务逻辑中使用的算法可以让AI生成模板算法，程序员在去修改和使用，比如算法中的各种自动机，建立各种树和图等，这样程序员仅需知道原理，而不用去背大段大段的模板。
现回答：

通过本学期的软工实践，回答还是没有变，而且更加坚定了我的看法，特别是面对快速发展的技术来说，AI辅助程序员的模式已经势不可挡了：当我使用以前的SpringSecurity模板时，当我更新SpringSecurity的版本时，当我刷新maven导入新的包时，出现十几个爆红的问题试问哪个程序员不崩溃，一查旧方法已经被淘汰，该如何修改网上众说纷纭，以前的程序员只能在CSDN大量营销号复制粘贴的博客中一行行淘取有用的知识，而现在，我们有伟大的ChatGPT，将原and模式的配置输入，让GPT直接转化为新版的Lambda形式，效率之高，用过的都说好。

问题二：单元测试应该在什么时候开始做？

原回答：

这个问题每个开发者或许都会有自己的理解吧，我本人是开发和测试都有涉猎，了解到开发和测试两边的博弈，开发当然可以不管测试，老练的测试也需要把一部分工作推给开发而避免加班，这是从人的角度看待这个问题。从软件的角度看，开发人员当然是要在每一个业务逻辑编写完成后就进行冒烟测试，以保证单一功能的准确性，开发人员一般也需要掌握一些基本的测试框架，更何况有些公司根本没有专业的测试人员，此时开发中的单元测试更是尤为最重要。至于在业务完成前编写还是完成后编写，要求程序员并行或单元测试更早编写（这里的“更早”并非时间上的，而是逻辑上的，即单元测试应在不知代码全貌的情况下编写，即所说的冒烟测试），以便与文档要求一致。
现回答：

“哈哈，测试？测试是什么东西，在我这里项目能跑起来不就行了？”这是我在团队开发中的真实想法；“妈的，这里怎么又有问题，这里逻辑不对啊？开发怎么想的？”这是我在最后收尾阶段测试时候的想法。由于我在团队项目中即担任后端开发又担任最后总结阶段的测试录频，对于测试的理解又加深了，《构建之法》说测试是软件的最后一道防线，确实是这样，但软件发布后有问题大家怪的也是测试人员，看起来和开发没有什么关系，但开发如果不做测试，出现问题测试人员不断打回，一来一回不光影响软件的开发周期，也会逐渐影响测试人员的判断。所以虽然我在作为一名开发人员时非常不想做测试，但我还是认为一名负责任的程序员应该在开发过程中就把单元测试做好。

问题三：为什么一般不推荐在单元测试中使用随机数增加测试的真实性？

原回答：

这个问题也是非专业人士的误区之一，专业的测试人员要明白，测试的本质是“为难”开发者，随机数有时可能找不到具体问题，类比一个简单的哈希冲突，采用双哈或更高级别的哈希，冲突概率可以降到很低，但经过人的计算，可以很容易（也可能不太容易）的找到冲突的地方，如果完全随机，可能服务器跑很久都不会有冲突。有一些有趣的算法网站（如CodeFoces）就鼓励去骇入其他人的代码，最容易骇入成功的数据当然是边界情况，测试同理，也需要测试人员人为生成一些边界或容易出错的数据。
现回答：

如同我在人工智能评测篇做的测试一样，如果仅仅是随机测试，想找到讯飞星火url末尾带/api会发生问题的概率微乎其微，但对于一个程序员或者专业的测试员，对/api、/admin，/auth这些单词必须有一定的敏感度，对这些名词专门进行黑盒测试往往会有意想不到的结果。这个测试结果也是对我之前回答的一大力证。

问题四：如何准确判断一门编程语言的发展阶段，从而在学习的过程中不会浪费时间到最后学了一门被淘汰的语言？

原回答：

这个问题可以成为大一新生必问的问题之一了，几乎每个初入业界的萌新都会有类似的疑问：我要学习什么语言？在前人的引导和我自己的学习中也逐步明确了这个问题的答案：语言不重要！！！重要的是思想！！！这是我和目前在职的程序员沟通过的结论。初入行业需要选择一到两门编程语言学习，一般是选择C和C++，这样你就能学会编程中的大部分语法思路，这样即使公司要求你转码重构，也可以很快适应。解决完语法问题就是方向的不同了，如果走技术方向，需要掌握很多框架的思想，最常用的就是Spring的IOC和AOP思想，技术人员常常需要根据需求写出公司要求的框架给业务人员使用（大一点的公司都有自己写的框架），封装重写一遍SpringBoot也未必不可能，而掌握其中的思想才是最为关键的。如果走业务方向，就更简单了，两个思想：抽象和封装（出自某在职程序员）。语言排行榜的浮沉都是虚的，掌握更多的编程思想才能成为大佬。
现回答：

五一放假期间道听途说了福州锐某捷公司的某领导的谈话：“十多年前我刚毕业时大家就说Java完啦，现在你都要毕业了大家还在说Java完啦。”我的看法与之前一样，语言经过迭代，语法糖越来越多，结合框架，Java20、21越来越像Python，学得多的可能会了解到Groovy，语言间的差异越来越小，前不久找到一个好玩的项目使用C实现ChatGPT的训练，作者为OpenAI的创始人之一，同作者的项目还有用JavaScript训练GPT，怎么样？对这些语言的用处是不是又拓宽了。只要了解编程思想，不同的语言也可以实现同样的功能，与其纠结学哪一门语言不如多学学编程思想。

问题五：多设备统一是否必要，有必要追求一致的体验吗？

原回答：

先说观点，作为一个用户，这是当然且迫切需要的，某些大厂的平板和手机体验，x86和arm的软件体验，不知道已经被多少用户吐槽过了。作为一个专业的开发者这更是需要考虑的事情，做设备统一不能在业务逻辑中做，要在底层就让技术人员去封装，再交给业务人员调用，我与另一个在职程序员交流过一个项目，项目其中一个功能需要在Linux，Win，Mac上实现相同的功能，而这个功能在不同的机器上需要执行不同的指令，每次开发人员调用时写不同的代码显然不合适，也不方便后续的修改，解决方法就是抽象与封装，类比JDBC的封装，业务人员仅需调用：注册驱动、编写sql、提交收到查询结果就可以，底层针对不同数据库的命令由底层去做，业务仅需调用接口即可，在日后修改逻辑时业务层的代码就不需要修改了，这就是低耦合的好处。回到应用层面也是一样的，有兴趣的可以去了解一下H5的跨平台是怎么把ios干掉的就知道了。
现回答：

为什么不呢？这学期选修了系统结构，对于系统底层结构也了解了更多，刚好我的手上也多了一台arm版Windows的设备，经过一学期的使用，不得不说，身为一个真实使用不同设备的用户，arm版软件的适配问题确实是《某些大厂》应尽的义务，未来流行什么？谁也说不准，但软件公司理应具有一定的前瞻性，提前入场布局总比市场变化后在慌忙开发要好得多，所以，国内某些大厂的软件适配着实让人恼火，不过也有一些已经开始做适配的值得说道，如网易云音乐pad版终于要公测了，作为用户，我肯定会更倾向于使用做了适配的软件，这样，由于没有进行多设备统一，某些软件产品肯定会流失一部分用户。

1.1.3 新的问题

经过一学期的软件工程实践，我不由得产生了一些问题，某些实践的要求，是有必要的吗？社会上的技术正高速迭代，某些实践内容是否过于形式主义？
而当我对实践产生疑问时，仅得到了“往届也是这样的”的回答，这样的答案显然显然太过随意与敷衍。不过这类问题我确实不了解，实践课也到此结束了，记下这些问题，或许我在下次与专业软件团队的交流中能得到答案。

1.2 知行合一

1.2.1 需求阶段

在需求阶段我们的团队针对项目进行了激烈的讨论，在这个阶段我收获最大的能力是学会对市场，用户进行分析，经过团队的讨论、思想的碰撞，对社会文化、需求有了更加充分的了解。

1.2.2 设计阶段

在这个阶段我们进行了软件原型的设计，经过小组的讨论，我们使用了大多数人更熟悉的磨刀进行设计，但由于我之前设计使用的是其他的原型设计软件，上手比较困难，不过好处就是我能收获比其他人更多的能力，经过这个阶段，我已经能熟练地使用原型设计工具进行原型的设计。在这个阶段我还负责了数据库的设计，经过数据库的设计，我对各种数据库设计技巧、约定有了更深刻的理解。

1.2.3 实现阶段

在实现编码阶段我负责后端部分代码的编写，使用的还是熟悉的SpringBoot来进行开发，在此阶段我最大的收获是对多人开发有了一定的了解，也对前后端结合有了一定的经验。

1.2.4 测试阶段

在测试阶段我最大的收获是学会使用了ApiPost这一接口测试工具，以前都是使用PostMan，但一是没有汉化版、二是稳定版界面不美观：设置为暗黑模式上面的窗口还是白色的、三是界面复杂，功能不明确、四是必须要登录才能使用，由于网络原因登录会有些困难。种种原因让我转投了使用ApiPost这一国产软件，原本只是尝试，但经过使用后，一键压测，自动化测试等等功能确实好用，而且完全免费，不用登录就能使用，让人感慨国产软件也能做到这种地步了。

1.2.5 发布阶段

在发布阶段我做了验收测试和最后的总结，经过这一阶段，我通过收集各个组员的感想，完整的了解了一个软件的开发流程和技术，对软件开发有了更加深刻的了解。

1.3 心得体会

个人项目

在个人项目中我还是使用了传闻中最快的json解析器：FastJson，不过导的包是以前学的时候用的低版本的，也是后面和其他专业程序员聊天后才知道FastJson低版本有爆出漏洞，不过这种趣味编程也不需要部署，安全问题大概也不用考虑，不过也给我敲响了警钟，写新项目时要尽量更新包到最新版本。在写完代码时我仅对用例进行了简单的测试，最后提交后检测时才发现有错误，果然开发还是需要进行专业的单元测试才行。

结对编程

在结对编程过程中，我第一次接触到原型设计，学会了如何与队友进行有效的沟通，也学会了如何使用git与队友进行协同编程。对项目的部署也有了一定的了解。由于和队友平时就比较熟悉，开发过程中的交流很顺利，对敏捷开发有了实际的认识。

团队项目

在团队项目时，我第一次接触这种大型的多人项目，经历了一个软件开发的全过程，对软件开发周期和阶段有了明确的认识，最重要的是认识到了测试的重要性，即使现在国内在社会上大多公司对测试都不太重视，但开发者也应在开发过程中进行严格的测试。

1.4 自我评判

目标	内容	评分	解释
1	理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。	90	扣分扣在我还没有实际参与过专业公司团队的软件开发，很多概念也只是道听途说的
2	掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。	85	与人交流是最难的，理解客户的表述要非常专业的需求分析才可以做到，我还达不到这个水平
3	掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。	98	这个方面通过这次实践课的开发我确实掌握得不错
4	能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。	92	经过软件评测实践，我基本具备了评测软件质量得能力
5	遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。	95	这点在团队开发交流中已经养成了规范的格式
6	具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。	90	这点我在团队开发中也得到了锻炼
7	能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。	80	这一点对没有实际安排过项目管理的我还是有点陌生，只停留在理论阶段

二、个人技术总结

2.1 个人技术学习角度：Gurobi求解器的使用

博客链接：Gurobi求解器的配置与使用
概述：商业求解器Gurobi是由美国Gurobi公司开发的新一代大规模数学规划优化器，我的个人技术博客中将会介绍Gurobi求解器的用途，如何申请和配置Gurobi，以及如何放弃微软臃肿的Visual Studio转而拥抱由Oracle开发、界面简单易用的C++ide：CLion中配置和使用它。

...全文