学生时代几个项目开发下来的一些经验

最后一个学期结束了，在CSIRO的实习也结束了，我想从工程开发的角度回顾下我学生生涯的三段实践经历，也算是一个总结，以及后续哪里可以进一步深挖。往后也会定期的对工程项目进行一定的总结，这个章节并不会涉及到具体的技术细节，而是工作大的方法论。

知识体系的构建与缺陷

由于我从大一下学期起开始对前端开发积攒起较为浓厚的兴趣，以及在算法数学方面比较薄弱。我在接下来的课余时间的自我学习以及实习上基本用在了学习相关开发上，这个过程贯穿了在西工大以及澳国立的几年。从一开始的纯html/css写静态界面，到后来跟着网上视频教学抄代码，仿写了几个vue的小组件，直到我的第一次实习，我都没有写过较为复杂的项目，而且前端的知识点基本上没有体系，都是哪里不会查哪里（虽然现在好像也是这样）。个人感觉像HTML/CSS的东西，最开始学的时候是死记硬背，但到现在大多数时候已经逐渐转变为习惯，进而转成肌肉记忆。

依托于当下相当成熟的前端项目架构，大多数时候其实要做的更改相对有限，也就是一些特定的脚本以及端口的修改。我目前的项目与工程化经验基本也是基于几个前端项目，考虑的多是组件化以及复用性这种属性。至于在课堂上学习的设计模式等思想，一般只会应用到自己页面的内部逻辑函数，由于目前的前端项目在进行业务逻辑划分的时候往往彼此独立，彼此之间除了跳转之外往往不直接相依赖，所以那些相互调用，相互依赖的开发经历较少，缺乏与他人共同开发复杂逻辑的经历。说白了，我缺乏后端或者传统软件的开发经历，一直在写web前端，希望在工作的头两三年能够更多涉猎不同的开发门类，不然总感觉自己缺点什么。比如设计模式，我在实际应用中也就写过简单工厂模式，但几十年的业界总结出的那么多模式只是在书本上见过，我觉得不失为一大遗憾。

（更新于2020年8月16日），目前得知以后在华为的工作业务大概率是服务器机组设施的自动化运维，即面向后端逻辑和OS的开发，内容为JAVA。简直太好了！我并不希望我的职业生涯在一开始就被钉死在一个狭窄的领域，刚好我也希望借着这个机会来完善学生时代所欠缺的后端以及OS的开发，我觉得一个合格的软件工程师不能仅仅停留在写toy的阶段，一定要参与一些这种最原初软件开发，涉及到一定硬件或操作系统，这样技能体系才能完整。

规范化与流程管理

实际的开发也遵循一般的软件开发生命周期，即需求，设计，编码，测试。在anu的工（吹）程（逼）训练下，我在需求与设计阶段基本能够独立地去找利益相关方去确认需求以及提出相应的设计草图。编码就不用说了，前前后后写了几个项目，基本的react，vue以及MVC框架的套路也算有点清楚了，剩下通过自己研究（google）基本也能完成个八九不离十。但是我学生生涯中的几个项目，对于测试是存在严重忽视的，仅有的测试也仅限于自己写的helper function的功能性单元测试，但目前我对前端的测试还是不怎么了解，这个需要在以后的工作中逐步培养，我觉得前端测试不应该仅限于直接交给用户或产品经历去拖拖拽拽，而是也应当有自动化的测试步骤。

项目管理的意识与版本控制

大一做大作业的时候，小组靠U盘相互传递代码；大二开始接触一些JSP的开发，知道一个叫SVN的软件，惊叹于其代码比对的功能；大三开始是用git，一直用到现在，也算是对其操作比较熟练了。实际开发中，我所经历的实习与各种项目都会划分成3个区域，master用于产品发布，其要保证产品的正常运行，宁可有一定功能确实也要确保正确性与健壮性，这个分支的更新都意味着产品的实际迭代；develop用于将众人的开发成果进行合并与测试；以及每个人自己的分支，根据阶段性任务与进度进行各自的开发。自己的分支需要定期的将develop整合进来以确保自己的代码拥有团队最新的成果，避免后续的合并冲突。

团队内的交流

团队内的交流在我看来分为两种，一种是技术团队内部的交流，目的在于技术的攻坚克难；另一种是与市场或者产品团队的交流，目的在于确认需求，避免反复。对于第一种，与自己的同工种的技术交流基本上都是为了需求一定的技术支持或者帮助，用以在代码的设计与编码阶段获得不同的问题解决建议，拓宽开发思路，而与不同工种合作的技术人员，例如前后端进行接口设计以及后续的联调，则是为了制定统一的代码逻辑，因为两边可能同时存在不同的考量，所以在实际的交流中容易存在扯皮的现象，这就需要其中一方对产品功能的需求比较熟悉和坚定（这个通常需要前端工程师，也就是我确认，因为其更接近用户层），其往往需要在这一阶段占据一定主导权，比如对于接口数据结构的设计以及传递方式（JSON或表单）起到一锤定音的作用。同时一旦确认，需要尽快形成相应的接口文档，除非后续版本功能更新或者底层数据结构重构导致非改不可，不要随意更改，因为不利于后续的维护。

至于与非技术部门的交流，由于其可能在几次的交流存在较大的往复，我们需要做好文字记录工作，同时要报以尽可能大的耐心。因为很有可能在最开始所有人并不清楚产品究竟是什么样，这就需要一个“打草鞋”，越打越明白的过程，所以在这个阶段一定要做好记录，并且在每次交流后迅速做好相应的设计原型，这样交流的效率会成倍提升。至少我通过这样的方法，和老外交流能迅速在一两周就把产品的需求与设计做好。

小总结

我从大一开始被反复灌输的一个概念，就是时刻以用户为中心，工程所带来的产品一定要解决用户在实际的生产生活中的具体问题的，这才是其存在的价值。所以从大的角度讲，最重要的问题是在实际开发中理解用户的实际需求，这其中有一系列的方法，比如各自原型图以及让用户参与的开发过程等等。在理解用户需求的基础上，这就需要我们软件工程师本身所拥有的软件开发技巧去把需求一步步转变为计算机代码。同时在一个相对漫长的开发过程中，渐进地将我们产品发不给用户，并且不断修正实际产品和用户期望间的差距。这在技术层面需要用到的就是各自版本控制。最后，重中之重，在于整个开发过程一定要不断的和用户交流，软件工程不同于传统工程的区别在于，软件的需求千奇百怪且用户很可能在最开始并不能明确知道自己想要什么，因此开发的工程也是一个对软件本身认知的螺旋上升过程，就好比剥竹笋，一层一层地才能看到最内部的笋子。所以，除非需求十分明确（现实基本不可能），否则传统工程中的瀑布流是很少能使用的，基本都要依赖敏捷开发这种理念。至少在学生时代的几个项目经验表明，这是一套确实行之有效的方法。