我是一名软件工程专业的大四学生，2019年12月份，学校的课程终于结束啦，随后就去南京找了实习单位。这家公司是创业型企业，位于新城科技园，公司不大，一共10个人左右。在这公司呆了一个多月，我发现这家公司并不是很符合我的期待，同时我也深刻了解到软件工程课程的重要性。
来到公司第一天，CTO通知我熟悉现在开发的项目，我看了一下项目，立刻惊呆了，我发现这个项目和我平时自己做的项目的流程差不多，于是很快就熟悉了整个项目。经过半个多月的磨练，终于有一天我发现这家公司在项目管理这一方面有很大的问题。
项目流程大概是这样的
- 老板有个想法
- 老板和CTO沟通
- CTO开始构建新项目并画出线框图
- 分配任务给开发
- UI设计师构建高保真原型图（同时开发去构建项目基本结构）
- 开发（开发和测试同步进行）
- 上线
你也许感觉还可以，但我觉得上面这些步骤并不行，会有很多问题，而事实上却是有很多问题。
首先“老板有个想法”这个是没有问题的，所有的一切都是从想法开始。接着“老板和CTO沟通”也是没有问题的。然后“CTO开始构建新项目并画出线框图”这步，我感觉是有点问题的，不应该这样，而是应该先构建产品需求文档。需求文档能够让研发人员和客户非常清楚的了解，项目的背景、预期、以及产品的细节，尽可能全面的把产品各方面实现的，可能存在的问题都列举做出说明，提高开发效率，节省不必要的频繁沟通。而事实上确实如此，在快要过年前，老板要求我们上线XX项目，然后由于前期的准备不充分，到上线的之前的几天，老板让我们改了很多东西，导致那一个礼拜都在加班。倘若之前有需求文档，那么老板看到这个需求不太符合他的要求的时候就可以去提前修改，当然了，还有就是研发人员对整个项目的流程不是很清楚，研发人员都是边开发边理项目清流程，这就导致了开发进度缓慢。由于需求的不清楚，导致UI设计师画的高保真原型图有很多错误，从而导致我们开发人员开发出来的功能就错了。
UI设计师构建原型图也应该是在产品需求文档中的内容，而不是和开发同步，理由是因为UI设计师也没有很清楚项目的流程。
有了产品需求文档后，接下来就是构建系统需求文档。这个模块主要有这么整个项目的完整思维导图、业务流程图、数据字典、功能性需求费功能性需求，这个可以帮助研发人员清楚了解每个模块的流程，而不是边开发边了解。由于现在是前后端分离的项目，所以数据字典就显得十分重要。提前定义好数据字典，前后端可以自已随意开发，前端的数据可以使用MOCK数据，不用担心由于后端接口还没开发完，前端无法测试的情况，这样整个开发过程就十分快捷。
测试也是一个项目中的关键阶段，我们公司有个测试人员，我以为测试是完成冒烟测试，压力测试等，然后给我反馈bug率或性能相关的问题，但是实际上他主要负责产品使用说明书的编写和测试项目流程是否能够走通。我觉得主要还是每个研发人员对项目的了解不够深刻，因为不够深刻，导致测试需要测试流程是否能够走通。
代码编写阶段是重要阶段，这个阶段的时间和财力成本都是很高的。倘若之前的工作没做好，那么这个阶段的代价就十分昂贵，有时候公司为了赶工期，压榨员工的自由时间，导致员工加班到很晚，最后老板认为是开发人员的技术水平问题或者平时都在玩。
版本控制，我们都知道git flow，但是我们公司并没有实行真正的版本控制，而是把git作为协作的工作。假设当前是版本3，倘若未来有一天需求是变更为还原版本2，那么开发人员只能重新去开发，就会浪费了大量时间。
我们公司只要项目跑起来，能够运行就行了，代码质量的都无所谓。我呵呵，代码质量的好坏牵扯到项目的维护性如何，我做的这个项目，由于觉得赶时间，然后就随便写了，代码更狗啃一样，我以为我的代码很糟糕了，看了隔壁实习生的代码，我发现我的代码还是挺好看的。后来她辞职了，这个项目也就全部由我来负责，在修改她的代码的时候，我实在没法下手，比如改了这个页面样式，那个页面的样式就变了，在比如命名fn、aa、bb、one、two。实在是无语，后来索性花了两天时间把他写的代码重写，保页面的样式不会互相冲突以及代码量的减少。如果没有一个好的代码规范去保证代码代码质量，那么未来就没有必要维护了，直接重写得了。
这几天在写一个新的项目，写了几个页面，这个项目我的代码质量都是十分ok的，代码量都精简到最少，而且在没有后端接口的情况下，都完成了所有的功能，后期等后端的接口完成，只需要修改对应的参数就可以了。当然了，还是一样没有需求文档。
需求文档是属于流程规范化的一个部分，这是专业性的表现，我们弄这个弄那个不是为了什么就是为了提高效率，小公司小在哪里？小在专业化不够，没有统一的流程，这导致太多时间被浪费掉，做太多无用功，心累。如果没有写需求文档会导致这个需求只有公司的某个人知道，而其他人如果想要参与到这项工作中就需要问他，你问一句，他问一句，别人还怎么工作呢？需求文档是为了降低沟通成本，节约时间，不影响别人工作而发明的，只要写好了需求文档，谁都可以看，谁也别问谁，谁也别影响谁。
老板说我们公司是敏捷开发，当时我就蒙了，这种随便开发的模式怎么就敏捷开发了呢，难道我学了假的软件工程。后来又去搜了阮一峰老师写的有关敏捷开发的文章，发现老板确实忽悠我们，敏捷开发并不是想我们公司这样的随意开发，也是有一套完整的流程，引用文章中的话
敏捷开发的核心是迭代开发，敏捷一定是采用迭代开发的方式。迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本，然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤，不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。
不管哪种开发模式，都需要让开发人员理解需求，如果不清楚需求那无论什么模式都是不能提高最终的效率（那种让员工自由发挥的项目除外）
在学校我觉得软件工程这门课程有啥用呢，现在终于明白他的重要性了
