- 价值观
在构建之法课程群中，大多数同学都会吵着说“时间不够”“作业太多”，还有“评分太苛刻”。同样的抱怨在高考时可能也有，不过教师并不响应的。对于本课程中同学们的这些反馈，教师的回应也不见得应该是关爱。
对于同学们的困惑，教师们(以及教师的领导们)也持有不同的观点，估且称之为价值观。以下是我的价值观。
3.1 尊重
在课程中，教师中对该对学生保有善意。但是善意有很多种，并不一定是宠爱，尊重也是一种善意。尊重不必一定帮助你做各种事，扶着你搀着你，替你端水斟酒，好像你是残疾人一样。尊重是视你平等为人。
尊重不是违心的肯定，无论你做得够不够好，而是认为自己的学生与其他人一样优秀，也可以完成学业，通过规定的考核。做得到底好不好，是有客观标准的，不以我对你的感情而发生任何变化。尊重甚至也不是鞭策，而是如实地向学生传达信息，传达身为教练根据经验和理论观察到的事实。尊重也不是面子，而是公开的否定和肯定。所有的作业成绩都是公开展示的，就像作业要求也是公开展示的。教师有多么差，学生们在教师这么差的情况下还完成了这么优秀的作品，这是我们期待的。学生有什么缺点，我们都(对外人？)掩盖起来，假装不存在，免得自暴其短，这不是我们期待的。
尊重基于你完成了契约约定的工作，我兑现我所承诺的每项工作的分值。而不是当工作不能完成的时候，才开始抱怨工作或者考核方法本身就是不合理的。这是借口和解释，而不是争论。在工作中也是一样，如果老板付了糟糕的工资，我们不应该少做工作以保证对等，而是应该换一家公司。契约是这个世界上少有的神圣之物，当你给出承诺，就置命运与他人之手。以任何借口破坏契约，都是把自己再次交到对方手上，任人宰割。所以，要么不承诺，要么努力去完成。只是，大家对于什么是“努力”的标准区别甚大。
经常有同学本着中华传统文化说，“对不起，老师，这次的作业如何如何，我以后会努力的。”我通常也会礼貌地回答，“没有关系，没有关系，反正分数我已经扣了。”我不会原谅你，因为你并需要我原谅，这是你的工作不是我的。千万别以为作业完成得不够好是对教师的冒犯，怎么会呢。你不完成自己的工作，我为什么要生气。
总之，尊重基于平等、公开、契约。
还有完全不同的一种尊重，不是甚至平等，而是基于仰视的。源于一个传说。据说西班牙人离间印弟安人，问，“你在你的部落有什么权利？”印弟安战士回答说，“我有冲锋在前的权利。”
3.2 作弊
作弊之所以是个严重问题，首先因为这是软件工程职业教育的一部分。不少同学认为作弊是无所谓的，到了真正的工作中自然就会变好。只怕在职场中，不作弊的决心是有的，不作弊的能力则不见得同时就具备。此外，确实有不少同学对于什么是作弊并不清楚，需要实践经验。
抄袭代码和抄袭文字一般明确认为作弊，但是有相当多的同学认为复制再修改就没有问题。有相当多的同学坚定地认为在博客或论文中复制图片是“出于教学和科研的原因”，是不需要授权的。也有同学认为自己作弊不会被抓到。
有同学认为“抄代码也挺费劲的”。确实是这样，就像小偷偷东西也挺费劲，不过这并不能改变盗窃的认定。做假药的也挺费劲，你因为这就觉得有情可原了？
团队作业要求每日立会，拍照为证。上一届尹同学以学长身份发言时指出，他们都是一次立会，照出一星期的照片来。为什么作弊需要负出额外的代价，这就是原因。要想避免尹同学团队作弊，方法很多，比如要求全程录音或录像，并且发布。反正每次只有半小时而已，录音录像也并没有多大的障碍。这显然为其他诚实团队的带来了不必要的工作量，除非这些录音录像有教师或助教分析，或有同学互评。并且，这也将教师引入了狱警囚徒模式。我们花更多的时间避免违背作业本意的投机取巧，而不是把有限的精力花费在更有效的教学上。
所以，不必考虑道德，这里也有成本问题。
三次教学中，发现过文字抄袭的，照片作假的，当次作业负分。发现过一次团队代码抄袭。那一次全班整体成绩较高，在这一背景下，降整个团队分数为61分，队长60分。
作弊是一种例外，而不是常规教学的一部分。所有的检测都有些假设。我们假设学生提交的作业并不是作弊的，在此基础上开展教学，而不是先假设学生们都会骗人。验尿的设备假设提交的样品是尿液，记者把绿茶倒进检查，由于绿茶碎屑与红细胞大小相似，在仪器中查为血尿是合理结论。处理作弊，也并不一定每次都有事先规定的条款可以遵循，因为并不希望师生是狱警囚徒模式。每次处理作弊的原则是保证教学整体不受影响，其他同学不会效仿或认为不公平。同时，不必对作弊的同学动怒，也不必在他的身上花费过多的时间。道德教育是公民教育的一部分，并非软件工程课程的重点。
3.3 对同学们感受的回应
(1)时间少，工作量
“作业量太大了”“做不完啊”“我还有啥啥别的正事呢。”
同学们将在三两年后走向工作岗位，成为一个用工资养家糊口的人。据我所知，大部分人由于能力所限，只能从事每天8小时工作。同时据我所知，现在不少同学每日学习时间不过1小时。从1小时到8小时的过渡是怎么完成的呢？
作业量大不大，可以根据完成时间来判断。大叫着工作量太大的同学们，PSP记录表明平均每周约9小时工作量。各位同学的导师认为，每周9小时工作量太小了。同时导师们指出，同学们经常对导师说，“杨老师的课作业非常多，所以您的工作要放一放”，各位也是这样对我说的，“我导师布置的任务特别急，所以作业完成不了啊。”各位同学不太清楚我和你们的导师互相认识，还常见面吧。
(2)我还有别的正事呢
兄弟院校有同学提到，我还有某某MOOC的课要上，这也是正事吧。我的学生不太跟我说这个，因为我的回答一般是，“是正事，应该好好学，只是跟我有什么关系，为什么要跟我说这个。”你恋爱了失恋了心情不好心情太好，天太冷天太热，这对你的人生都非常重要，是很了不起的感受，不过，我一点儿也不想你分享给我。我只想评价你的作业。
为什么MOOC能投入时间，而软件工程课则不能呢。因为(很多)MOOC没有考核。没有考核不做度量的课程，都是耍流氓。你真以为真了几届世界杯以后踢球就能功力大进？是的，研习他山之玉是不可或缺的，不过，这是充分条件么？我对你有别的什么本事，又学了什么新的技能一点也不感兴趣，我只想评价你的作业。
(3) 嘴硬
同学们还喜欢用言辞证明，我的就是好，就是符合要求的。我想说，工程不是辩论，徒以牙尖嘴利是挣不到工资的。不过有时候，对这种态度确实挺失望的，所以连这句话也懒得说。
如果你是真心不懂，那么这是教学。如果你懂，只是想来辩论，那么就超出教学范围了。
这里本来举了一些例子，自己读了一遍，顿时兴致索然，全删了。
(4) 我不会啊
我也想对上级和领导说“我不会啊”，他们会换个人来完成这个任务的。
同学们说“我不会”的时候，有时是求救，希望能越过这个障碍继续完成任务。有时，解决障碍本身的答案并不重要，而寻找答案的方法才是更重要的。以下是一例，当时在微信中答同学问。
--引文开始----
有两位同学在遍历目录时出现了类似的问题。以下是解决的建议，不是单独外对这一特定问题，而是"我不会"，"我基础差"，出现类似的"莫明其妙"的问题该怎么办。
方法1. 读手册
[https://msdn.microsoft.com/en-us/library/system.io.directoryinfo.directoryinfo(v=vs.110).aspx]
MSDN说DirectoryInfo需要catch 3类异常。
我查了代码，你没有捕获，在调用的时候，在调用的函数外面，都没有。这就跟调用函数的时候缺了三个参数一样。
不知道如何写捕获异常是吧，这应归结为知识结构不够完整。知识结构不完整是不可能自行解决的，要么补知识结构，需要较长的时间，要么借助外界力量，这个比较快。
方法2. 问同学，看同学代码，看别人如何解决。
不要说，“这个实现不了。”谁也实现不了，才是实现不了，你实现不了，就只是你实现不了。
有人能实现，去请教。如果你连查一遍博客找谁和你用了相同的语言的时间都不想花，那就只好等别人主动帮助你了。
别人没有责任给你讲怎么办？死皮赖脸地求，请TA吃饭求，给他买各种礼物求，给他男朋友女朋友买礼物求。在芬兰有位中国小伙儿问我，没有实验经验怎么办。我说直接找个感兴趣的实验室。他说，人家根本不给没经验的人活儿干。我说，去给他们扫地，然后再说呗。我学计算机，是从给老师打字开始的，就为了能摸到键盘。
方法3. 搜索引擎
搜索，随便找了个链接进去，然后就知道应该怎么写了(bing现在有了代码示例，更加友好)，这样就能得到异常被抛出的原因。在这之前，神仙也不能确认就是什么原因，这也是远程诊断和听你描述特别难以提供帮助的原因——必须先能看到展示的信息，然后才能判断。
此外，我发完消息才发现漏了一点。
我不会在有技术效果不能确认的时候，就写下那么长的核心代码。一定先把没用过的技术都试用一遍，然后再写核心代码。如果技术手段不行，核心代码不必写，因为跑不起来。
写那么长的核心代码，长达72行，却从来没有调试运行过。
这就像写了 main(){，然后就开始写代码，写了800行，再写最后一个 }。
善良的老师会说，你的匹配能力还真强呢。
不要相信这位老师，他想的就是，“不要这么做。”只是受教育理论要求，才必须友善。
--引文结束----
(5) 我费了这么长时间做，为什么得分少？
这是典型的"没有功劳还没有苦劳么"心理。分数判定是按spec来的，就像高考就像托福机试一下。你顶烈日冒大雨前来考试，也一样可能不通过。你的努力是成绩的必要条件，不是充分条件。
事实上，同学们甚少跟我就这一点讨价还价。我听说了有些学校的同学这样做，那是因为同学们觉得跟仁慈的老师讨论可能有效益，跟我讨论这一点纯粹是浪费时间。
(6) 为什么算法实现了，却扣我分这么多？
这涉及到 核心算法与符合规范 间的分值分配。凡是参加过ACM比赛的同学和有过工作经验的同学并不存在这种疑惑，因为工作业绩是以结果度量的，而不是以什么“核心”或者任何不可见的部分声称完成来领工资的。科学、技术、工程都以可见的指标衡量，凡不能度量的，就是不存在的。
此外，本课程作业中的算法过于简单(并且不是算法课)，大部分工作也是如此，此时合规是工程的基本要求。需要由外在检验符合需求，而不是你会了就行。比如作业要求是命令行参数，那么不能用scanf实现。即使你觉得命令行参数不好而scanf更好(而不是只会scanf)，也需要按规范实现。
4. 教师改进的方向
(1)及时反馈
如果当周作为不能评出分数，一方面学生会迅速忘记当时是怎么考虑的，不利于学习，另一方面学生可能在此后没评分的几周里再次犯下相同的错误。所以快速反馈，至少下次作业以前，是必要的。
一旦有出差，批作业就非常成问题。完全不出差，又难以实现。此问题估且搁置。
(2) 避免不教而诛
初学时，学生经常陷入无所适从，做的各种事情都是错的，这样的感觉。这种感觉不利于学生建立信心和继续努力，会得出结论“我不适合学习某某学科”。理工科普遍有这种不够友好的倾向，下马威一百杀威棒能让不少同学望而却步。
有些办法能减少学生完成作业以后的挫败感(罗列条目细致会增加作业前的畏难，再讨论)。
如，在学生互评时，原则是"不得有相同分数的"，这在执行时，不如"排序，不得存在并列名次"操作起来容易。这个案例想说明，原则执行起来要比具体措施困难，虽然原则更接近动机。在部置作业时，需要考虑二者的妥协。
再如，代码参考和文档模板。邹老师提议过写一个词频统计的代码，低效能，同时代码风格较好，供学生在此基础上修改。这个还没有做。文档模板，FFL老师给出的两篇作业 软件产品案例分析 遵循了相同的模板，
要求清晰，
能够帮助学生把握回答的脉络。
引用如下。
----FFL引文开始----
[http://www.cnblogs.com/orzyt/p/6013963.html]
[http://www.cnblogs.com/dasusu/p/4896863.html]
大纲如下
第一部分 调研，评测
第二部分 分析
第三部分 建议和规划
细节如下
第一部分 调研，评测
评测：
软件的bug，功能评测，黑箱测试
1、下载并使用，描述最简单直观的个人第一次上手体验
2、按照描述的bug定义，找出几个功能性的比较严重的bug（至少两个）。用专业的语言描述（每个bug 不少于 40字），如有必要，可以配图
采访：
1、介绍采访对象的背景和需求（他们有没有用过这个APP或类似的APP，除了现有的功能还有别的需求么）
2、让采访对象使用10-30分钟K米的功能（请上传照片证明用户的确正在使用，远程采访的同学请让别人帮忙照相）
3、描述用户使用这个产品的过程, 用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？
4、用户对产品有什么改进意见
5、结论：经过这么多工作，你一定有充分的理由给这个软件下一个评价,请选择一个结论:
第二部分 分析
1、使用此软件的大部分功能，联系第二部分的分析，估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）
此处应参照教材WSB表格
2、分析这个软件目前的优劣（和类似软件相比），并推理出团队在软件工程方面可以提高的一个重要部分（具体建议）
3、根据理解和体验，画出整个软件所有功能逻辑框图，根据重要度标识出各模块的重要度、完成度、出发点及效果
4、针对不同的维度评分，对用户体验方面、UI界面美观度、核心功能，分别打分（总100分）
第三部分 建议和规划
1、如果你是项目经理，如何提高从而在竞争中胜出？
此处应根据NABCD或“根据《构建之法》8.5小节的内容”
2、目前市场上有什么样的产品了？
3、你要设计什么样的功能？
4、为何要做这个功能，而不是其他功能？
5、为什么用户会用你的产品/功能？
6、你的创新在哪里？可以用 NABCD 分析
7、如果你来领导这个团队，会有什么不一样？
8、如果你的团队有5个人,4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
9、描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定
10、作为用户，你或你们最喜欢其中什么功能？（列表123，最多选择三种，说明理由） 你或你们可能会为哪些功能付费？（说明理由）
----FFL引文结束----
又如，有同学在todolist、燃尽图、PSP、WBS中的功能点不对应。这不是主观故意，而是因为对工程管理缺乏了解，所以教师应该在课堂或作业中提出明确要求，而不是见了作业以后感觉“这你也不懂”。
又如，控制台和命令行参数，各个学校不止一届同学表达了困惑，应该单独撰文发贴说明这些概念，并作为作业的附件。一味指责同学们基础不好，连这个也不会，于事无补。
最后，有同学提出希望有更详细的判分依据。我曾经以ACM不公布测试用例为据否定了同学的提议。如果假设同学们是诚实的，不会直接输出测试用例期待的结果，那么详尽的判分依据对同学们更快掌握和进步会有帮助。应详尽到对文件名的要求这样的程度。我尝试了给出pull脚本，既帮助同学们检验自己的git repository是不是可以拉下来，也帮助同学们拉别人的工程参考和互评。
(3) git
git每学期都在改进，不过还是要注意 要从开始就保持检查，作为强制要求，不提交倒扣分。应对团队项目也执行这一要求。下学期我准备写个脚本每天pull一次，然后diff，把团队项目的log发到作业评分里。在教师机器本地的部署执行，实施方案还在考虑中，会重视，但是难以兑现。目前检查的措施是要求学生对演示录屏，要求学生实现快速部署对于学生经验要求高，对教师机器要求高。
(4) 整理和积累
FFL博士建议过作业加标签，还没有做，逐渐意识到必要性了。
示范和模板，积累不够。
点评同学们的作业，都留在了微信中，在博客里和作业里看不到。这样的好处是，1.节省时间，2.实时交互，3.避免同学们置之不理，4.同学们能注意到这是单独对他本人所说的，而不是拿出对别人说的话再对他说一次，感觉到被尊重。坏处是，不利于教学成果的积累。下学期，整理对话吧，仅dump记录还不够。
(5) 课堂知识结构组织需要更有条理
使用邹老师提供的PPT讲了一节，教室投影不清楚，学生休验不好; 内容太多，取舍难。按我自己拉的大纲讲，经常某一项超出计划时间很多，到最后只好后面的讲不完了，下课了之。得刻意控制一下每点的时间花费。
------------------------------------------------------
博客会手工同步到以下地址：
[http://zhuanlan.zhihu.com/younggift]
[https://younggift.net/]
//[http://blog.csdn.net/younggift]
//[http://giftdotyoung.blogspot.com]