[北航软工教学] 头脑风暴随想录
今天有一个学弟很认真地跟我聊了一些关于软件工程有关的话题，现在我把我们的聊天记录贴上来，希望听听各位老师的意见。（为保护隐私，文中隐去了直接的学生和团队的名字）
学弟
乾神，我觉得软件工程其实和软件关系不大，目前为止我的感受是它应该叫做工程管理，软件的部分反而显得很小。
我
软件的部分反而显得很小是指什么？工程管理是必要的，做管理是因为这是一个团队的项目，项目经理本身就需要做很多管理的工作。不知道你觉得哪里有疑问呢～
学弟
管理本身没有错，如果每个人都是全职的软件工程师，时间充裕的确没问题。但是现在问题是每人平均每天最多有2小时花在软工这门课上，其中近1小时用于管理和汇报，但是我们仍要完成足够影响力的软件。
这两者结合的结果是很难同时做到很好，所以我说这门课偏向于管理，因为过程中被检查的总是博客和会议记录，这些属于管理方面。最后也只是看一个大概的结果和数据作为软件方面的评分，至于代码是否可维护拓展(与架构相关)，API文档是否清晰(与传承相关)等软件方面的内容反而没有被太多关注。
我
你说的有些道理，但是我有几个问题问一下
1.为什么每天汇报工作需要1个小时。Scrum Meeting之所以站立，就是希望将会议的时间在15分钟左右，让进度汇报不占那么长时间。至于燃尽图，写博客，更新进度这些由项目经理负责，或轮值负责，不会拖整体的时间吧。
2.过程中检查的不止是会议记录和博客，我们会看你们签入的代码，也会看你们团队的合作。
学弟
每个人汇报+分配任务，很容易到半小时，多则45分钟
我
我上次参与过某支队伍的scrum，他们的会就开得很长，因为会有一些无用信息掺杂进来了。比如上次有一个同学，他提到分词器，然后把分词器目前的现状什么的讲了一下，但是这些对其他同学来说重要吗？这些东西其实是不太重要的，本就不需要让每个人都知道你做的模块的原理。不知道你们团队里是否有这样的情况？
Scrum Meeting的进度汇报尽可能简短有力，有一下子解决不了的问题私下单独交流，减少开会成本。没问题就安排下一步任务。你可以在今天scrum的时候把握一下时间，如果今天开完scrum以后还觉得scrum非要45分钟才可以结束的话，那你再来找我，说一说你们scrum时主要内容是什么。
学弟
我觉得软工这个课最后可能形成的东西是，表面有完整的管理体系，但是软件本身就像一个大作业，而不是一个项目，管理是成体系了，但是软件还不是成体系的软件。
比如举个例子，乾神你们的物理实验网站，七八个实验的前端表格全部写在了一个页面里面，2000多行挤在一起，后面的人怎么维护更新…
还有物理脚本完全个人化了，我看得懂，上帝看不懂，这也是所说的软件不成体系。
我
前端表格这个我没注意过，这个可能是我们的工程师习惯不好。
但是这些本来就应该是在你们考虑的范围，之前你们的项目经理说要接手我们项目的时候我就说过，这个东西不是想象的那么简单，接手一个项目可能要比新建一个项目更困难。
软件成体系的问题，我在上软工课之前也没有受过系统的训练，我相信我们组其他人也一样。所以你们在预估接手项目的风险时，就应该考虑到：学长的项目究竟是个烫手山芋，还是一个香饽饽？你们究竟有多少时间用于真正的开发？你们维护的代价会非常大吗？
我作为项目经理，我们是一个面向用户的需要快速迭代做出来的产品。我不能要求后端的人写多么详细的注释和清晰无误的API文档，前端的人一定要用工程足够规范的方法，我只能说：规范和文档是伴随着工程量或用户的增加而慢慢进行的，包括模块化，包括单元测试这些。架构的设计也是一样，难道我们网站最开始就要设计成可以处理千万级请求的架构吗？这不现实。
另外，我不同意每人每天最多只有2个小时用来开发的说法，如果这门课是必修课，或者是很高的学分，大家是不是重视程度就更高一些了？每个人对每件事情都有优先级排序，我能理解。每个人在软件工程课程花费时间不一，收获也都不同。
具体的策略取决于你们，具体的实施方案也取决于你们。我承认我们的项目，或者说每一个“上一届”的项目都不好维护。软件工程课不会教大家写代码的。
学弟
第一，15分钟的会议，无法对各成员的工作有充分的理解，既然是只是想知道做了什么，也什么要特意开一个会呢？显然每个人私信一下即可完成。如果说有什么问题再私聊，会议上不多做讨论，那这私聊的时间算不算会议的延伸？
第二，如果说软件工程就是偏管理不教架构设计不讲软件编程规范那我是接受的，但显然这导致了软件内在问题很多，这个并不是说这课不好，只是侧重点不同，选课之前和之后会有一点愿望的落差而已。但是既然不讲怎么写代码怎么管理代码，那最终对软件的要求终究是有所降低，希望有足够用户量，能够运行下去的愿望都是不堪一击的，那么最终评分的原则必须对管理方面有所倾斜，不能说没教的东西评分过重。
第三还是那个说法，我们不是全职，所以做法应该有一定的自由度，不能说全部按照全职的那一套来。比如现在我们上课受到老师的质疑——老师希望我们是按用户视觉来看问题，增加用户所希望的新进展，当然成熟的产品自然没问题，但是考虑到维护性，考虑到非全职，我们在过程中重构了的部分应该也算入工作量里面，甚至我们一半的工作量都在于重构，即便是我功能没有一点增加，但是我重构了一个很好维护的东西，比之前好，也应该是我们的成绩，不能说因为没有增加特别多的功能，看起来和之前没有差别就不算我们的工作，另一方面也是因为这既然是偏管理，那在软件方面就应该降低要求。
我
重构代码我认为是可以的。我之前跟另外的几组也说过，只要说清楚你的重构是有意义的就可以，我不反对重构。而且重构的工作当然要算在工作量里。
你们可以从不同的角度来阐释软件工程这个词的含义，不论是面向开发者的，还是面向用户的。对象不同，工作重心不同。老师认为对的，未必一定是正确的，你们按照自己的理解来，只要你们有收获，能说明你们的工作是有价值的，那我这边对你们绝对是肯定的态度。
罗老师质疑你们其实是因为：学霸online的那个网站，四年重构了四次。所以罗老师害怕你们会有这样的趋势，才会质疑你们，他怕你们占着已有项目的优势不做对用户有价值的工作。你们要抗住老师的压力，在心里把目标明确就可以。
学弟
的确一百个人有一百种代码，代码文档不全，主管跳槽了后面整个公司都开发受阻也不是不可能。
我
恩，那你们就抓住我们项目存在的缺陷，把它们按你们的理解去弥补、修复，我觉得这也是一个很好的工作啊。
学弟
这是实际问题，根本问题还是大管理套小项目，工程管理和代码管理分的比较开，我认为罗老师希望学霸online通过每一届接手最终越做越好在这种情况下是不现实的。
我
我觉得确实有一点不现实。但对大家每个人来说，我们有一个基本期望：希望大家能把软件工程的基本流程走过一遍，有过这样的团队合作的经历，做过一个能让自己自豪的项目，那就可以了。
所以我的立足点还是在你们自身的收获有多大，而不是项目本身有多厉害。
学弟
嗯行。
