自我介绍
我叫陈志锴，undergraduate，pre-phd，初级程序员（c++和c的区别只知道多了类和对象这种，python只会写大作业代码和用基础的neural network框架），曾经跟着师兄们做过一些low-level visual computing的工作。日常查资料、看论文、看书，偶尔运动（跑步、轻度健身、有条件时就羽毛球桌球乒乓球）。典型的INFP型化解者人格，强度16级，如下图所示
闪光点
- 技能
- 高二的时候花了几个月做（“导演”）过一部课本剧获得全国中学生xxx银奖，很失败，不知道怎么评上的
- 业余小提琴爱好者，曾经学习了七年，我觉得一件事情能做这么久其实也很不容易了，但是现在缺乏练习导致技能点下降
- 其他
- 工作中没有不良情绪，低落的心情从来不会留到第二天
- 脾气好，善于倾听，乐于与人沟通，比较适合做一个team member
- 谨言慎行，说话不口嗨...
- 课余爱好比较广泛但是随心情和状态变得快（自认为闪光点^.^）
- ……
- 自我认识挺丰富：闪光点可以列很多，如果叫我列反向闪光点也可以列很多
现状
在我选择这个cyber-security专业的时候，主观原因是挺感兴趣，为了顺应信息时代潮流（从众心理），而security又是一个非常重要而发展相对稳定的领域；客观原因是信院四大专业其他的几个都有我非常想避开的必修课。选择转业后我很快进入了实验室并且做的是与专业不太相关的方向，可能是因为对动画电影美妙特效的喜爱，我开始了解了multimedia方面的研究。大学生活实际上对我的三观造成了很大的冲击，USTC的“学习”气氛疯狂的渗透进了我的生活，无论是点点滴滴的学业上的磨砺还是与良师益友的交流对话，但其中令人印象最深刻的还是“考试没考好”“代码出问题”的那种受挫感，所以也需要不断的提升自己在IT方面的技能，比如以下几点就对我来说十分重要：
| programming: comprehension | 4 | 7 | read paper and browse GitHub code |
| Programming: Design | 4 | 7 | coding |
| programming: Implementation | 5 | 7 | coding |
| program: performance | 4 | 6 | read some materials and do experiments |
| programing: BigData | 1 | 4 | learn from my partners and process some big datasets |
| Supporting Knowledge: Mathematics | 3 | - | learning by doing |
| Presentation | 4 | - | learning by doing |
我阅读了一些ASE推荐的blogs，结合自己在科大形成的价值观。
上课认真听讲的问题
我反驳一下引述的这篇博客的观点。该文一开始提出了一个普遍观点“水课不听，专业课认真听”，然后否定了该观点，并认为“大学生上课就是要认真听讲”。我不敢苟同它的否定和观点，首先它并没有一个标准来规定什么是好课什么就是水课，这种好坏之分只是一小部分学生基于一小部分客观事实给出了一个主观臆断吗？还是用类CMMI模型经过深入分析得到的结论呢？一门课要学到什么程度应该由这门课的质量和它对你的重要程度来决定（重要程度不好判定），我的观点基于这个事实，所以大致可以描述为“水课不听，一般的课认真听，好课听讲还要关注附加的内容”，而这里的“水课”“好课”不是一个人任性的主观臆断，而是理性分析的结果，要不要听的问题关键在于课程好坏如何评判的这个难题上。所以我引述前文博主以下几个观点来并在观点下面进行反驳。
- 这些能力不一定需要通过“大学生上（所有）课就是要认真听讲”来培养。还有关于这些能力都同理。
- 讲的不好难道能成为听讲的理由吗？既然它既不能成为不听讲的理由又不能成为听讲的理由那如何能用这个说法来说明烂课也要认真听呢？
- 一个（或几个）学生说老师讲得烂，作者认为这并不能说明这门课讲得烂，我也同意这个观点。但这能说明烂课就必须要听讲吗？如果当课程之烂已铁证如山之时，我们也必须要认真听讲吗？
这个观点我也是同意的，有用无用同样甚至不是某一个权威科学家能准确判定的，所以存在两个问题：
- 何为有用？对自己毕业工作赚钱有用？还是对提升自己专业能力有用？还是让人开心了就算有用？哪门课又是没有用的的呢？或多或少它所教授的内容都在一个人漫长的生命中会起到一点作用，因为未来尚未分明，我们可以给课的作用排序分类但不能指责其无用。
- 有用就要一定要认真听吗？价值是我们已经实现的东西，区别于理想和信仰。在我们追求价值最大化的同时，其实就是追求尚未实现的东西——理想。今天高等学府的学生并不是缺乏资源，而是不知道该如何选择资源而屡屡错失良机。既然这么多课都有用，除了课之外还有那么多东西有用，就需要我们来排序分类结合自身需求进行选择从而取得最优解。研究者们往往习惯于很快登上一座山峰而不习惯在这座山上长久的攀爬，从而陷入局部最优而非全局最优。
总结一下，该文列出了三点认真听课的好处，一个场景假设以及一个相关事实，站在Ta的角度上的确有一些道理，是值得尊重赞赏的观点，但是Ta比较倾向于说明认真听课的好处（其实不认真听课去做别的事情也有好处的），缺乏一些其他场景的对比（比如跟不认真听课而去做作业的好处的对比）。
所以大学生要不要认真听讲？人要尊重自己的感觉，在上课时尽量保证自己处于“学习区”。我的观点是，如果学生对自己未来规划比较迷茫还不鲜明，建议认真听讲，如果已经很有想法或很确定，那可以根据课程状况与质量、自身能力，经过理性的分析调研（基于模型、亲身体验、询问老师同学等等）之后来判断该如何上。而我为何要来上这门课，主要原因是听说这门课质量非常好，老师非常棒，而且我自己又在一些比较对口的能力提升上以及学分上有需求。
教学方法：师生关系、手段
理想的师生关系是Coach/Trainee的关系，学员要提高水平，在教练的资源支持下身体力行，双方及时给予反馈。我也比较关注——怎么用最优的代价，过了这门课。最小和最优还是有点差别，学习的过程中代价最小总给人一种不踏实感，对某些问题可能难以留下深刻映像，代价在某种意义上说也是收获。
计划
现在我在MSRA Media Computing Group着手一些texture compression的工作。短期内（近一两年）仍然会持续研究low-level media computing，今后还想涉及一些social multimedia / media analysis的工作，希望Phd期间在感兴趣的领域完成一些研究并实现一个conference paper的小满贯。几年之后，我仍然会选择做学术研究，但同时会注重产学研的结合，做更多有意义的原创性工作。在我研究生涯到达一定阶段之后（15至20年后），成为一定级别的研究员，我或许会转型到其他更多的行业如教育、管理，甚至是创作，所以我今天除了在IT research上的工作，空余时间会去看一些感兴趣的书籍以及和经验丰富的管理者打交道，我也不太想与其他同学对比，可以与他们交流学习一些经验，但自己的选择只要自己热爱就好，这种规划可能比较适合我的INFP型化解者人格。
关于ASE
《构建之法》读后感
早在第一次上现代软件工程这门课，为响应授课老师的号召，我曾经读过这本书的前面一些章节(Chapter 1~8)并且在博客园写过读书笔记(CH 1~3, 4~6, 7~8)。《构建之法》倡导我们“learning by doing”，在软件开发的过程中心以“人”为中心而非软件本身。这本书的内容可以分为两个部分(from my sight of view)，软件的开发测试和除开发测试外的所有工作，而后者就被定义为了PM的工作。
作为一本经典的ASE教科书，目的就是想让老师和学生切实实践一些商业化的软件工程的开发流程、方法、工具。如果把这本书当作一个开发软件，那它的典型用户就是学生，那么它是否能戳中学生的痛点呢？我有幸在学校用这本书上过这门课程，一边进行program一边读这本书，我的最大感受就是：工作量大，印象深刻，我的其他课要没时间做了。如果学生是用户，课程是一个软件，那对该“产品”的需求有这么几个重点：给分好，学到东西，工作量不太大，学分多。其中有些比较具体有些比较模糊，当然这种需求是不太现实的，因为grade、credits、workload之间本身就存在一些负相关，毕竟在学校的管理制度和教学体系之下不可能以满足这些要求为标准来制定课程，但如果说绝大多数课程都是在尽量满足学生需求和教学需求关系上寻找平衡点，那么ASE课程的存在就是逆流而上希望打破这种双方坐“翘翘板”的桎梏，在教学质量上达到一个比较理想化的状态，如果大多数同学在繁忙的课业压力中，书中推荐的很多材料没有时间看，教科书也就会慢慢成为一本工具书；但是邹老师在关于教学方法的探讨中对比了THU和CMU的课程项目的多少，虽然有其他种种环境因素不一样，但这个对比还是能很好地说服我的：负担是有的但是人类还是可以接受。
身为一名“典型用户”，这本书列举的东西太多我经常抓不住重点，也或许每个细节都很重要，这样读起来实际上感觉非常累，但是也可以一目十行懂个大概（状态b），读完或许也没觉得哪里有什么令人惊讶之处。经过自己的实践，我总结出一个比较容易接受（比较科学）的阅读方式：先快速读完，了解重要的基本概念在脑海中形成一个“big picture”，在做一些实践项目，项目遇到问题时回头参考书本、认真思考。
问题总结
1. 《构建之法》中企业化的软件工程移植到在校学生团队上，需要有什么变化吗？
书中好像没有详细讲这一点。事实上，课堂上学生团队和一个成熟的企业有很大的差别。主要体现在两点：
- 成员的平均开发能力更弱
- 不同成员对开发工具的熟悉程度差别比较大
第一个问题一般比较好掩盖，课堂上的项目会比较迷你，老师给的时间也会放宽，对质量要求适当调整。但要解决第二个问题就存在一些困难，比如：
- 大家都是同学组成的团队，项目起步阶段如何分工(WPS)？按照自愿划分还是按照某个标准来评判谁最适合哪个角色？如果用标准评判那该如何制定与实施呢？
- 由于开发能力不同，明确分工之后，一边进展的差不多了另一边还刚开始，整个过程要么就搞得像木桶理论一样，要么就是能力强者一个人一路高歌猛进全做完。
由于这些困难的存在，“把学到的软工理论应用于实践”该如何应用就成为一个关键。按照开发测试的准则写几个代码，PSP流程管理开发时间，双人合作领航+驾驶，这些都是实践。但若想更深入一步，比如在团队项目中建立一定的团队模式，选一个PM来对开发者人员、用户、产品等进行驱动、调研、测试、交流、估计、计划，将spec转化为MBA那一套，那真的是不太可能。通过浅层次的实践，我们能做的预期是：深入感受“用户（老师）”要求折磨下的开发过程，切身体会软件工程对于软件的重要意义（PSP、双人开发、规范...），初步了解并敬畏高级软件工程尤其是商业化软件中，除开发测试以外的各项工作的重要作用（团队、PM、设计、用户端、质量...）。
2. 需求分析一章中，Work Breakdown Structure要满足一些要点，包括：节点不相互覆盖、从结果出发等等，除此之外，节点任务的时间同步性是不是也应该成为一个要点呢？
3. 书中有关于用户体验的设计，典型用户和场景的描述，对用户需求分析很透彻。但有时候有一些其他因素不可忽略，比如人类习惯根深蒂固，市场上软件产品层出不穷，无法轻易辨别、理解、管理；手机一搜可以找到许多功能类似的产品，而且也没空一个个体验一遍再来选择。在这种大趋势的困难下，如何依靠技术产品打破僵局，推广出去呢？
4. ASE课上很多同学也提出宏大的创新想法，这些想法大多都成为空的构想。Crossing the Chasm说鸿沟就在于innovators和early adopters之间，所以是因为这些想法吸引不了大众而落空吗？
5. 2004年11月信产部娄勤俭声称：中国软件业还在手工作坊阶段，书中也提到创新的出路不能再各种峰会上的发言人士，而需要走进各自的小作坊。到了2016年，纽约时报一则视频却形象地描述了大型垄断企业的影响力。有能力的小作坊，需要找到合适的渠道和空间来实现自己的价值，需要环境对知识产权的尊重和保护。而随着软件工程数十年发展及第一批公司的壮大，小作坊的成长空间是不是越来越小了呢？
结尾
在ASE课程中，我是收获最大的是什么？是阅读方法论？还是实践经历？开发测试的过程？除了这些之外，最重要的一点是团队交流，在交流中规划开发、完成开发。教科书虽然是学习的纲领与指导，但learning by doing的过程中，书本只是参考，是主菜的调味品。而主菜就是大家放下其他的事务专心集合到一起，静下心来讲事实敲代码找问题的过程。
软工课上起来如此费力，邹老师借用了CMMI模型评价了教学成熟度，用“赢者通吃”准则作为评分依据，用真实的项目人员流动来保证可维护性。只是可惜软工课不是一个软件产品，要不然一定会做得更完美。