一. 成员介绍
韩青长
自我介绍：
我是韩青长，技术小白，抱着对软工的好奇和对未来工作的憧憬选了这门课。暂时选择了测试的工作，也对开发和UI有一定兴趣。从前上帝创造了我们，现在轮到我们来创造自己的软件了~
有图有真相：
职位：测试
陈彦吉
自我介绍：
呃，自我介绍。。怎么说呢，我叫陈彦吉。。作为一个没什么基础的渣渣，感觉一路被碾压了两年，成绩不如大多数人，能力可能也不如大多数人，其他人都可以说自己曾经拿过什么奖，做过什么项目，我感觉我可能什么也说不出来，不管怎么说，这都是因为自己怠惰了，但是我还没有放弃治疗，这个学期我一定要拿下这门课！
有图有真相：
职位： PM
石浩然
自我介绍：
有幸成为19勇士之一很开心啊！
选罗老师的软工真是一门需要情怀的课
献上自己的膝盖和所有假期
大神们带我飞吧
有图有真相：
职位：开发
陈鸿超
自我介绍：
除了会点编程啥都不懂，纯粹来学技术的小白，请轻虐o(╯□╰)o
有图有真相：
职位：开发
二. 采访
寄语
I leave uncultivated today,
was precisely yestoday perishes tomorrow
which the person of the body implored.
我们，
奋笔，疾书，争渡；
或许听到了梦想化作泡沫的声音，
然而，
There are no trails of the wings in the sky,
while the birds has flied away.
我们，
远行，探索，寻途。
或许被风沙迷离了双眼，
但仍不停歇，
I am a slow walker,
but I never walk backwards.
正篇
- 当时的项目有多少用户，给用户多少价值？现在还有人用吗？
严肃而言，当时项目的真实用户数为0；这里我也简单说明具体的情况，我们团队项目共划分为四部分，这里也尽可能用简单朴素的语言解释清楚： + 搜索引擎原始数据的分类与整理（爬虫组） + 原始数据的结构化（数据结构组） + 搜索引擎网页前端的设计（搜索引擎网页组） + 搜索引擎APP前端的设计
而我们团队负责的就是搜索引擎网页前端的设计，即搜索引擎组； 在Alpha阶段团队本身更倾向于自身的架构设计，而与其他团队交流后发现他们都倾向于读懂原始代码，调试并修复，无法和我们团队本身的架构实现融合，因此团队当时也并未深入思考过重做轮子的复杂工作量，凭借团队本身的能力直接完成了由爬虫到网页前端的全套架构和基本实现；但实际上这也是团队的第一份成就和第一个错误，软件工程需要非常注重各组之间的协调，而不是在最后时刻试图用中间层的方式兼容其他组的应用，因此，团队实际上在Alpha节约的“与其他团队的沟通成本”几乎占据了Beta阶段全部成本的50%； 在Beta阶段团队一方面由于其他课设压力增加，另一方面沟通成本瞬间提高且时间紧迫，因此团队做出了第二份非常具有挑战性的成就和第二个可能的错误，团队试图将ReactJS引入架构提高前端代码的可复用性，几乎又重构了前后端，同时也与APP组共用后端增加了自身的压力；最终我们将目标订位面向开发者的开发，而非实际用户的开发，为此我们留下了充足的接口文档和学习文档；最终我们成功完成了新架构下的设计，但也同样犯下了“重构”的错误，我想如果还能再有软工，我们会选择推翻第二次难度非常大的重构，而不给后续开发者，特别是初步接触软件工程课程的人，非常巨大的压力
至于用户价值，我们上面也说过了，我们留给下一届的是面向开发者的前端设计和代码，包含详细的文档；当然我们也给Alpha阶段和Beta阶段做了充足的标记，通过回滚操作也可以继续Alpha的工作继续做起，而不是以FLUX这一难度较大的设计入手；我们也希望后续的开发者能继续完成这一份任务~真正，将它的用户价值挖掘出来~
现在，由于当初校内的服务器相继被撤回，团队也没有继续维护自然也没有人使用；之前实习时，公司的BOSS阅读我们的代码结构也吐槽过我们的重构和文件组织形式，或许等团队人员在大四结束尘埃落定之时能继续未完成的工作吧~
- 这个项目能否给我们团队继续开发，源代码和文档还有吗？之前听说过这一项目比较难所以询问一下具体的情况
团队当然非常希望你们团队能继续开发，源代码[https://github.com/bugphobia]和文档[https://github.com/bugphobia]均存于github中，有兴趣的话可以详细阅读，而为了方面后续开发者能有清晰的入手方向，团队也提供了Cookies文档以帮助开发者迅速理解项目本身的内容，后面也后团队的联系方式来着的~
但同时，我不希望你们团队能继续开发；因为这一项目本身就是一个协作形式的项目，特别是知道了今年仅有19人选修了罗杰老师的软件工程，无法协作分工成至少3组完成各自的职能；软件工程并不是一个团队的战斗，因为很有可能需要有不同的团队负责不同的数据流动环节，这一过程需要完善的协商，有参考和遵守价值的规范文档；如果仅是一个团队去完成我们的前后端设计，那对于这门课程并没有很大的价值，那只是阅读和调试代码，不是工程！真的希望，将沟通，甚至不是沟通，而是遵守的规范作为首要的准则，这才是协作的软件工程
- 项目开发有什么经验和教训吗？
笔者作为当时团队Beta阶段的项目经理对这一点感触颇深，这里将少量叙述技术细节，尽可能将经验和教训抽象化： - 将沟通，或者是约定的准则作为首要的评价标准；在开发过程中不是两个人用10个小时说一下各自怎么做然后中间慢慢墨迹和对接，而是首先抽象功能，从功能抽象所谓的文档（接口API，输入输出规范等等），根据文档做客观的开发，可能在初期会节省很多纠缠，节约很多时间；至于后期，团队磨合充分后可以做出一定的其他的尝试；至少当时我们团队就尝试过不同人尝试不同的角色（比如前端开发人员和项目经理双重身份的笔者），去充分体会不同职能的具体内容 - 暴政还是分工？我无法回答这一问题，因为团队经历过暴政的高效执行也经历过分工的细致轻松；因为团队具备能力强的架构人员GNU_Linuxer，也具备任务划分粒度合理的项目经理Panacea（来自鼻子莫名其妙变长的笔者），同时团队的成员个人能力也都较强，因为不同情况也都能顺利完成目标期望；我只能希望之后的团队能首先分析清楚每个人的能力，然后合理安排，就像你让人用HTML写后端这种感觉；我们并不排斥有一个能力强的人引导着每个人做正确的事，但我们希望引导之后能真正明白自己的职能，最终协作达成目标~ - 责任？笔者跑一个题，之前笔者的学长创业，吐槽过好多次不要找熟人，否则“不忍心”；当然，这里说的责任包含两方面的意义：首先，请按照每个人的贡献给分，真正公平是需要规则约束的；其次，分工时即使是结对编程，也要指定唯一负责人！换句话说，出了问题只询问一个人，否则极有可能出现安排上的问题
- 对学好软件工程有什么建议？
但至少，不管是爱情、亲情或是友情； 只要喜欢一个人，就不要冷冰冰地
不要问笔者为什么将上面两句看似无关的话放在前面；软件工程，是实践之后才可能有扎实收获的课程，永远不要冷冰冰地去注视一段代码，既然你想真正爱上软件工程，那就去追求她（fork），了解她（read/run）……[此处略去大量内容]
- 大家工作的内容是先定在了角色的范围内，还是根据任务量会相互分担？
详见“项目开发有什么经验和教训吗？”这一问题的“暴政还是分工？”分支；简单阐释，团队是先确定角色以完成团队磨合，后期磨合成熟后会开始不同人处理不同职能的“体验”经历
- 学长你怎么看待2014级仅有19人选修罗杰老师的软件工程课，大家貌似听到第一次作业后纷纷退选OAO
真的很遗憾的感觉，并不是那种喵的我今天受的罪我一定要让学弟尝到的那种遗憾，而是发自肺腑感觉错失一种体验的遗憾； 首先不得不承认，退选并不是一个错误的选择，编译原理、数据库、信号与系统，大量有趣和丰富的课程同样是不错的替代品，相比于当初笔者遗憾选择了编译课设的中高难度，选择一门轻松的软件工程课程也的确是可行的选择，这没有什么遗憾的，当完整设计出漂亮的编译器，思考着底层的优化，是不错的成就~ 然而，如果仅是因为第一次作业退选那的确是一种遗憾；笔者也当然会倾向于选择轻松的那一条路，但我记得当时我笑着写了一张纸，贴在了左侧的铁皮柜上，“痛并快乐着~”；就像今天敲着寥寥几行文字的自己，在面试能将它勇敢地写在简历上，面试时也能淡定自若讲述着重构的经历和技术细节；这门课程真的能相通很多事情，不仅仅是技术上，更多是认识问题的层面上，也希望大家能通过这门课去认识更多志同道合的人，比如邹欣大大2333333~
- 老师上课的内容和书本几乎一样，那学长你们当时课上都做些什么呢？
说来惭愧，笔者在上软件工程课是分心狂魔，基本都在集中经历在做自己的事情俗称溜号；上课的内容和书本类似，这一点从PPT当时的内容上也能看出来，但有时罗杰老师也能给出一些自己的理解，也能问一些好玩的问题~一本书几个小时后重读也可能有着崭新的感受；估计我再说下去的话罗杰老师要请我喝茶了，但我们课上更多的是思考我们项目遇到的问题是否也再课上偶尔提及过了呢，有时太过单调也做一些自己的事~
- 项目貌似大多集中于网站和APP的范围，但我们此前都没有类似的经验，是否有一些快速入门的资料或网站
搜索引擎，STACKOVERFLOW（比如和C语言鼻祖教材相比肩的另一本教材《How to copy codes from stackoverflow》） 对于经验，更多希望能在阅读过一些小DEMO在提供~（其实已经很好地团队留下的历史文档里了~在哪里自然希望能自己查找了OVO）
- 学长你们团队貌似都是能力比较强的一些人啊？
首先，不是能力比较强，我们团队都是比较帅或者漂亮的人，据说是最帅的人担任项目经理的……………… [被BugPhobia团队的其他人暴打后] 咳咳咳，我们来说正题，事实上，团队的个人能力的确较强，但这并不妨碍我们成为一个团队~文案能力较强的人，由他负责整理我们的讨论摘要，和架构商议后及时调试相应的技术细节；学习能力较强的人，由他去引导不同的人接触不同的框架或是语言，结对编程的方式快速上手完成相应职能；综合能力较强的人，由他去在项目空闲期时积极完成与其他团队的协商；我们不是因为个人能力强而成为能力强的团队，而是我们强大的团队让每个人变得强大~