Wander Software Engineering
本文一鸽再鸽, 从原本计划中 SE 的开篇到现在的落幕, 或许也是开发中的一个常态吧: 按时交付是不可能按时交付的, 这辈子也不可能按时交付 ←_←.
在过去的两年里，在计算机领域从一无所知的小白成长为如今的大白，写过几个“小玩具”，在开发过程中也遇到了很多的问题，有时候总觉着时间再多一点就好了，这段代码能不能写的更优雅一些？自己也在不断地思考以及在查阅解决方案，可拼拼凑凑却也找不到一个成体系的方式去阐述自己遇到的问题、以及该如何解决，直到遇到了软件工程。
Origin
第一次遇到这个问题，是在大一第二学期的 Advanced Programming。这实际上是一门类似于 Java 语言基础的课程，其中包含了一些面向对象的简要介绍。这门课的期末大作业是一个 Poker 项目，基于此也诞生了我的第一篇长博客（Advanced Programming Project – Poker）。
In principle，这是一个小组项目，in practical，我承担了绝大部分的工作。
我想在这个项目开始之前我对软件工程还知之甚少，对于如何完成一项这种“大作业”还完全处在探索阶段（值得一提的是之后大多的 Lab 老师均未设置太多的框架，只要完成目标就好，因而有了更多的机会去尝试）。
当时在青春在线已经学习了一些关于 Web 开发的相关知识，博客站点已经投入使用，并陆陆续续写了一些与课程相关的文章，因此对于“文档”已经诞生了一定的概念。
除此之外对于我影响最大的其实是此前的学生工作经历。“该如何策划一场活动”和“该如何完成这个大作业”从高度抽象的角度来说好像区别不大：做好“预案”、规定好“约束”、然后交给另外一部分人去“完成”。于是我就习惯性的去分析、模拟、设想这个“项目”主要的几个部分、最终呈现的效果、需要注意的问题……因此最终演变为了——“需求分析”。
在这个期末大作业开始之初，我希望能够与组员建立起一个比较好的沟通的桥梁，并且本着当时自己对于 OOP 的粗略理解（黑盒、封装），决定从这个“文档”入手，写明对于作业的需求以及具体实现的要求：
这部分工作在实际上耗费了相当一部分时间，虽然没有对小组合作起到什么实质性的且正向的作用，但或许我从这时便开始逐渐思考该如何实现一个复杂任务了。当时的机缘巧合，结识了 xhh 学姐，同时也是在她口中第一次得知了 UML 这个东西，当时的自己也并没有进一步深入，只是在最终的博客中画了几个类图便草草结束了，而且现在看来更为“滑稽”的是，当时的类图还是在开发完成后进行的，完全颠倒了顺序。（但又或者类图只是一种展示的工具而已，用它来展示项目的结构好像也未尝不可？）
More and More Complex
在大作业结束之后是一个奇妙的暑假，我遇到了自己第一个有甲方提需求并且最终实际上线的项目————青春答疑站。
现在回顾这个过程，还是蛮有 Software Engineering 那个意思的：
甲方提出需求 → 确定系统功能(包括约束) → 设计UI界面 → 核心功能实现 → 增量开发 → 后期维护
我觉着 zxy 同学还是很有学计算机的天赋的，在整个项目的生命周期中，进行了多次沟通，功能性需求、非功能性需求、性能指标要求等等均有涉及，她提出的关于数据库的 Concurrence 和 Data Persistence 的问题直到一年之后的 OS 和 DBS 我才有了一个比较明确的答案（But toooooooooo late）。
这个项目踩的坑是真不少，原本计划是要写一篇博客来着，但是也无限期的咕咕咕了（或许，maybe，perhaps 我之后会再写的！），后来这个答疑站也演变成了今天的 BulBox，欢迎大家来踩~
回顾一下项目中遇到的几个关键问题就会发现已经逐渐有了“工程”的苗头了：
数据安全
微信小程序在架构上采用了前后端分离的形式，（这或许就是现在常听到的“体系结构”了吧），因此部分涉及到用户隐私的 API 是不允许直接在前端明文调用的，为了搞懂这一点但是也是费了一些力气。但因为此前没有做过前后端分离的项目，因此我将所有的数据处理和查询都写在了前端的 JS 中，这种方式有很大的安全风险，好在也没人在乎我这个小项目哈哈哈。
数据并发
也就是 zxy 同学提到的，关于同一个问题被两个人同时回复会怎么样。对于这个问题在这个项目中则完全依赖了 DBMS 的调度策略，没有在系统中做任何的限制，哪怕是现在，我也没想到有什么好的办法去处理这个问题。感觉问题是出在了最开始的系统的设计上，如果做成就绪队列然后再分配回答人员，这样应该能避免这个问题。
约束问题
主要涉及到两部分共三点。
第一部分是微信平台的约束：1. 如何对用户提交内容的进行敏感信息审查；2. 如何规避微信对小程序社交属性的审查。
前者在之后的 Bulbox 中进行了一定的处理，即对于用户提交的信息，均需要审核后显示，但在最初的“答疑站”中并没有处理。对于第二个问题则是做了一个 Fake Page 通过数据库字段控制前端的渲染来躲避微信审查，这样很轻松能通过黑盒审查，但如果是对源代码进行白盒审查，那多半就会被禁掉了。
第二部分则是属于经费限制，早先学长在开发小程序时曾出现了流量过大导致后期服务器费用超出预期，但好在这次主要是文本信息，耗费的流量并不大，并且甲方也保证了可以提供一定的经费支持。
Hard Code
在还不知道 Hard Code 是什么的时候就已经深受其害了。
项目下线前需要提前弹出提示，当时的做法是直接在前端写死一个 Alert 然后重新提交审核。这样做显然是有点儿蠢，目前能想到的比较好的办法就是像上面的 Fake Page 一样通过数据库进行控制，再进一步如果有管理员界面，可以通过管理员操作数据库进一步设置弹窗提醒。
可维护性
这应该也算是 Hard Code 的危害之一了吧！在处理 Date 信息的时候偷了个懒，直接把月份写入了数据库，但是没有注意 getMonth() 的返回值是从 0 开始，导致最终的月份都提前了一个月。
最后解决的办法，还是挺搞笑的：
之后这个问题也被我复现了一道模拟题用在了校内选拔赛中 糟糕糟糕OMG 魔法怎么失灵了
另外比较回旋镖的一点是本学期的 SE Lab3 HCI 设计，我先在平板上绘制了草图，lpj 老师看到以后说“这样就足够了”，so，“传出去，计算机学院都是在纸上编程”：
对于这个“小玩具”，坦白说代码质量一言难尽，命名不规范、代码复用率低，这也直接导致了后期维护成本升高以及我再也不想打开这一坨代码来重构了。所以在 BulBox 中仅仅只是参考了这个思路罢了，而没有在此基础上修改。
任期内另一个主要项目是关于网站改版，毫无悬念的烂尾了。如果是从头写一个网页，那其实还好，但是对于 Web Plus Pro 平台，我只能说，emmmmm，无话可说。项目截止到目前唯一的遗产是关于系统模板页编写的一些文档，想要摸清这么一个黑盒子里面的“特性”真的好难，火鸡科学家也不是那么好当的。
但是其中遇到的几个问题我想与 SE 也是有相当的关联的。最主要的一点就是关于工作的分工和调度，但这一点已经超过了我的本职工作，在此不详述。要提这一点是因为在最近学习工作中脑海中突然出现了一句熟悉的话：“破处体制机制障碍”，因此也便产生了一个疑问：当任务的复杂度、广度不断增加时，技术或者是说执行还是任务的关键吗？也正如人月神话所讲，一个人干十个月，十个人一个月就可以完成吗？又或者说，当“工程”二字出现后，用什么“技术”已经不再是主要矛盾了？
Eureka?
忽然的某一天，发现了“设计模式”这个东西。
原本的计划是要在这个超长的假期好好地学习一下，可惜总会有一些超出控制的事情发生，最终也成为了一个烂尾项目。
但是可以看一下一年前的这段话（又闭环了有木有>_<）：
第一次更新 Reading 的分类，不知道该如何定义这样一篇文章。最初的标题是“前言”，但又感觉不合适，最终更改为了一篇随着阅读不断更新的 Summary。其中的一些内容会动态调整，随着自己不断地阅读和学习也可能会有进一步的思考吧，第一次尝试这种方式的读书笔记（其实在此之前很少有做笔记的习惯），不知道效果会怎么样呢？
自己的水平有限，很多概念在写这篇文章的时候只是刚刚接触，也没有进行过很多的实践，所以行文时可能会在很多简单、基础的地方不断赘述，却忽略了真正核心和重要的部分，也或许对个别概念理解上有所偏差，不能完整准确的表达其精髓，望见谅！也希望读到这些文章的同学们可以相互交流，对文章中不合适的内容提出建议。很早就对 UML 这个东西产生了疑惑，进而了解到了作为 CS 本科生课程的软件工程（Software Engineering）。在本学期的面向对象开发（Object Originted Development）课程中涉及了一些关于 UML 的知识，同时 wl 老师也简单介绍了一些软件工程中的基本概念。
本书所涉及的设计模式即是属于软件工程的一部分，同时以面向对象（Object Originted Programming）为基础介绍了 24 种设计模式和 4 种原则，因此在阅读此书之前需要具备一定的面向对象的基础知识。
面向对象的语言有很多种，
C++、Java、C#等等，本书采用的是C#进行描述，但由于代码风格和Java比较类似，因此有Java基础的同学看起来也不会很吃力。同时该书提供了“附录A”对面向对象进行了简单的介绍，在这里就不过多赘述了。面向对象中的继承、封装、多态（动态绑定）可以将程序的耦合度降低，而使用设计模式的目的就是让程序更灵活、更容易修改、更易于复用。有些人认为新手在刚刚接触开发的时候必须要有意识的使用某种具体的设计模式进行设计，但本书提出，学习设计模式的最终目的不在于将其生搬硬套到自己的开发中，而是要领悟到其中的思想，进而融会贯通。
个人理解的就像C中尽管没有面向对象的概念，但是使用结构体和函数式编程同样体现了一些面向对象的朴素的思想。因此思想的凝练十分重要，掌握了面向对象的思想，无论是在转换哪种语言，也都可以快速上手。OOP 的优点以及为什么要使用设计模式
书中以活字印刷的几点优势类比了程序设计中的几点要求：
- 可维护
- 可拓展
- 可复用
- 灵活性好
对于可复用，这是之前很少注意过的事情，特别是在几次开发中，比如 Java 大作业和小程序的开发。对于大量重复的代码，都是通过复制粘贴实现的（例如小程序中不同页面的），这也导致了后期维护的时有些困难。
以小程序为例，可以通过Component将重复的代码封装，但是由于时间紧，加之自己从前没有过类似的训练和习惯，所以采用了复制粘贴的方式进行了“重用”，代价就是后期修改的困难。在竞赛中偶会出现一些大模拟的题目，许多繁杂的细节常让人感觉抓狂，也会在脑海中飘过“如果用面向对象是不是更合适”。确实，即使是使用面向过程进行求解，却也会使用函数式编程的方式进行处理，一方面会让思路更加清晰，另一方面则是为了调试更加方便。
我真觉着这是个好东西！！！！特别是对于 OOP 还处在懵懵懂懂状态的时候，真的应该简单学习一下这部分的知识。
在之后 Event Driven Programming 的项目中，原本计划是应用几项设计模式相关的知识，并且已经设计好了相应的功能，但是众所周知，人类的本质是鸽子，最终结果大家已经猜到了hhh
最近另一个印象深刻的小项目就是上学期实训的小编译器了，不去讨论其他的方面，只关注开发和技术相关的内容还是有很多值得思考的地方。具体技术细节不在这里详述了，项目开发时的一个核心原则是“增量开发”，尽管整体只有五天的时间，但在前几天把骨架搭好后，后期丰富功能的速度是极快的。
对比之前把一个模块完全完成后再进行下一个，最后完成一整个项目的方式，在“开发一个小型编译器”的限定条件下“增量开发”在我看来显然是一个较优解。
站在当时的角度认为，设计模式对于提高代码质量、提高系统开发效率确实有着很大的帮助，但是到现在才看清楚，真正影响着代码质量和开发效率的应当是设计模式背后的体系结构。
Be a Architect
“Architect” 离我还是很远的，但是 Architecture 早就在身边了。
在 Poker 之前其实还做过一个 PHP 的博客小项目 click here，虽然只是为了应付一下青春在线的考核，对于当时要求的“使用面向对象”并无太多感受，再回顾这个项目，抽象、分解、封装原来早就出现了！
再进一步！将前后端分离，于是就有青春答疑站，第一次（其实也不是第一次啦，第一次是 Vue）用到 MVVM 架构；走到 BulBox，后端的 Django 又用上了 MVT。
模块化的开发方式让原本复杂的内容一个 import 就搞定的，美观度高了不止一点吧←_←；虽然被 Django 的中间件搞得有点头疼，但是其安全性高了也不止一点：
但在学习的过程中还是产生了一些困惑，甚至有个阶段竟沉迷于“面向过程”与“面向对象”的“纯度”之争，现在看来好像没太大意义，毕竟能跑的代码才是好代码！
马上就要面临升学的抉择了，花花世界迷人眼，大家都想要去到一个不错的地方，但我总感觉，未来不会是我们目前看到的这些，不能一直猛堆算力、大力飞砖烧开水吧？可惜自己没有那么多的天赋，好像最终的出路也只是压榨那80%的快乐换取技能熟练度的提升吧！
一直用别人的东西可能永远也做不了 Architect ，自己更像一只风筝，一只迎着风口也飞不起来的风筝。但有机会的话，还是希望以后：
Into SE, Beyond SE
过去的一些实践已经证明，盲目的开始一项工作大概率会造成许多难以估计的问题，许多“虎头蛇尾”也是因为对自己没有一个清醒的认知。而在软件开发上的第一步就是“认识自己”。
认识自己是非常难的，对于系统的分析也是如此。单纯从技术的角度来说，很多功能实现起来并无难点，但是考虑到众多的外部约束条件，软件工程似乎已经超越了软件本身的范畴了。
所以软件工程到底是什么？
用系统的、规范的、可量化的方法来开发、运行和维护软件。
这是书本话，大概是自己脑子不太记事，所以一直不喜欢这种条条框框的定义。
纵观整个 SE ，期间介绍了不少概念、模型、工具、方法，但这就是 SE 吗？
或许 Engineering 们没有太大的区别，大家都是在用技术创造着一些东西。回到第一次，对我“该怎么做”启发最大的反而是与软件、开发毫无关系的学生工作，好像有点儿怪，但好像又没什么问题。
当我们把这些问题抽象、抽象、再抽象，分解、分解、再分解，终于变成了一个 P 类问题，只不过是 Philosophy 的 P。
剩余价值石锤
