软工课设完成杂谈
此为杂谈，又或者说是迷思、胡思乱想。如有观点不同，语言锐气还请谅解。
完成了软工课设…
软工课设的实行简直就是一场灾难…一群人对着一个指导书写报告，完全不管实际需求和代码实现。指导书上要求人事管理系统需要能发招聘信息，但招聘信息必须要登陆才能查看，而登陆的前提是你是公司里的某个角色。结果就是发的招聘信息别人根本看不到。这还只是海量问题中的沧海一粟。归根结底软件工程就离不开甲方。当甲方变成了一个指导书，需求沟通变成空谈，之后的迭代开发更是想都别想。这个软工课设的实行从根子上就坏了，搭建起来的报告就犹如空中楼阁，学生不知道写出来能有啥用，有心人把代码实现之后更会怀疑人生——我到底学了个啥。
按理说要学生干这种工程实践就应该得发工资，我交了钱来这上课结果内容跟打工内容完全一样，那我为什么还来上呢。起码得要让学生学到点实在的东西吧。
尽管如此不堪，我还是尽量写完了，在无意义的世界之中寻找意义本身就是就是一种英雄主义，尽管是属于自己的英雄。
谈软件工程
我不喜欢软件工程
理由非常充分，我用的软件起码有50%都不是用软件工程理论开发的——几乎所有开源项目都没有用到软件工程的那一套方法论，gcc,linux kernel,chrome,vscode都是如此。在这些项目中，软件工程这门课程仅存的价值只在贡献者交流时，或者文档中，提供几个UML图供读者方便理解。
你可能也会反驳，软件工程声称解决了多少多少问题，软件退化啊，什么开发投入/时间比指数上涨啊等等。对，但不完全对。软件工程解决这些软件开发的问题的目的是为了让计算机学科变成一个工科——不论来什么人都能训练成软件开发人员跟团队协作开发好一个软件。应该说除了画图那部分，软件工程剩下的都是管理学方面的内容。这些管理学的内容对于一个学生来说没有任何价值，组织开发一个软件已经有一个更好、更快、更方便的方法——Github+敏捷开发。轻松易得的版本管理、快速且强烈的正反馈、完全扁平的交流：这些优点都碾压了复杂的软件工程的管理学。再加上大家的水平都差不多，差距没能大到需要一个复杂的组织结构才能运行，扁平化交流造成的民主式的开发能很好的解决复杂的实际需求，也即小规模下直接民主是一个最优的方案。而更大规模的组织通常你也不会去思考为什么这组织一定要存在。就算要思考了也没必要——事实上软件开发成本随着工具软件的开发是越来越低的。以前做一个3D游戏非常困难，你需要手操GPU管线，将这样或那样的素材导入到各种缓冲区中，还得维护各种复杂的角色状态机、事件循环等等；但现在，一个高中生就能开发出一个3D游戏了（虽然看着不咋样）。软件开发成本的降低意味着以前需要几百人组织开发的大型软件现在几十人就够了。几十人的规模完全可以不用上软件工程的那些开发形式。一步到位，敏捷开发就行。敏捷开发造成的影响如此之大以至于软件工程权威教材（大理石书）直接把敏捷开发独立拉到第三章。要知道这还不是软件工程这门学科之前所倡导的软件开发行为，传统软件工程理论的存在价值变得岌岌可危。
就连画UML图都可能不是软工最有用的地方——这些应该归类为RPC/Restful这种业内标准/惯例做法。要达到UML的目的，无需刻板的按照规定怎么画的行事。画UML图的唯一用处就是让其他人快速理解这个软件How it working，标准UML的做法不可能覆盖到每一个场景下的这两个要求快速和成功理解How it working，只可能是一种局部最优。但就像Restful的作者也不会有一套Restful的通用理论——在每一种场景下都是最优。这就意味着UML图不止有一个答案，自由的UML图应该就如同自由的设计模式一样，面对无穷无尽的需求，归纳成为一些惯例。这可能适合出一本书，但不适合当作一门学科。
再谈前端
仔细思考一下你就会发现前端所造就的一些奇观…
- Restful其实就是一个可靠消息传输，但是其基于的HTTP依赖的TCP是流式传输，于是就有了基于(基于消息传输的UDP的QUIC)的HTTP/3.0
- chrome+网页是一个UI应用，我们直接把它打包成一个可执行文件就成了传统UI应用了。于是就造就了您的电脑上有xxxx个chrome的奇观，于是就有了（可能可以解决的）tauri
- npm解决X-A-B1.0,X-D-B1.2,X-C-B1.0的问题竟然是直接全部clone下来(2个B1.0,1个B1.2)…明眼人一看就看出来这会指数膨胀。于是就造就了写一个helloworld需要500M硬盘空间的奇观…说这是脚本语言，Java看了都摇头。于是就有了pnpm…
可能这也是敏捷开发所造成的奇特现象吧，这任何一个问题放在kernel，甚至放在libcurl都是不敢想象的。但是我想你也看到了，根本不存在。一是kernel这些东西都非常成熟，二是开发出这些东西的都是大佬。前些日子还解决了一个前端人写C++随手一写const char* s=xxx.c_str();导致的悬垂指针问题…照理来说编译器会直接报Warning的也不知道他看没看。
当然这并不意味着前端没有价值，前端最大的价值在于chrome，但更多的我想应该还是html+css。
html+css现在既能做排版又能做UI，你能在其中看到许多影子。
html全称是超文本标记语言，虽然我想没多少人想去念它的中文全称，但是这昭示了html的本质——文本和上面的标记。这和Latex不谋而合，比如
1 | <a href="www.google.com">检测是否科学</a> |
完全可以变成
1 | \a{herf=www.google.com}{检测是否科学} |
而能做UI得益于CSS的帮助，传统意义上的UI起码要解决一个问题——部件的尺寸该如何决定。没有css的html只能变成一个“报纸”。有了CSS后我们来看看我们可以如何决定一个部件的大小
- 首先部件有盒子模型了，这相当于打了个地基，其他改变尺寸的所有属性最终都会呈现在这个盒子模型上
- 我们有width和height属性可以直接决定一个盒子的大小了，甚至
- 我们有flex布局，可以各种各样布局任意多个元素了
到这也就够了，width和height可是UI一个基本的属性，flex布局就对应着UI的三大经典模式——水平布局，垂直布局和表格布局。
因此我们可以说html+css确实能够胜任latex和传统UI的工作，实际上代表传统UI的Qt框架也在跟着html+css推出了自己的qml和qss。
历史是一个圈，大圈包小圈。
也许之后真的有些地方需要用到传统软件工程的理论把，希望是这样。
浙江温州皮鞋湿，下雨进水不会胖。