1.方法的好和坏
The rise of worse is better: 作者Richard Gabriel在文章中对比了两种软件设计的思想， “the right thing”和“worse-is-better”，前者认为，软件设计过程中的简单性、正确性、一致性、完备性等特征，对于设计者来说同等重要；后者则认为，实现过程的简单性及性能是设计者唯一需要考虑的东西，正确性、一致性以及完备性都可以因为简单性而有所牺牲。
Is worse really better：作者认为，“worse-is-better”哲学将会拥有比“the right thing”更强的生命力，其产品更容易被用户接受并广泛传播。
在“词频统计”项目中，我们小组在项目过程的开发流程偏向于第一种哲学，每个人在实现项目中的子功能时，都尽力做到接口的一致性，每完成一个小功能都会对其进行单元测试，保证结果的正确性，这样做的好处是，能有效的减少我们团队的沟通成本，避免给其他成员带来不必要的麻烦，而且会让我们得到很多锻炼；坏处则是，有时候为了保证接口的一致性以及功能的完备性，增加很多代码，这一方面会对我们程序的性能造成影响，另一方面还让我们在实现核心功能之外的代码上花费了很多时间。我认为，在一些小项目中，尤其是一些看重准确性和完备性的团队项目中，第一种方法会增加团队合作的效率，保证项目的稳定持续开发。如果接手的是难度较大的项目，我更倾向于用第二种软件设计哲学，因为它对我这种经验不多的开发者更友好，更容易让我在功能实现中获得成就感。而且，过于浪费时间在核心功能以外的细枝末节，而不去关注完成的产品是否可以有效抓住用户的痛点，可能会使我们花费的时间变成无用功。
2.软件工程的方法论到底有多少用处?
Jez Humble: Why Software Development Methodologies Suck
在博客中作者认为，实际的的软件项目是复杂的无规律可循的，现有的软件方法论适用的范围则极其有限，因此开发者们完全遵照软件方法论工作也不能保证项目的成功和产品的质量。而且，相对于编程语言和方法论的选择，开发者的能力是更具决定性的因素，而怎样衡量开发者的能力是一个难题，招聘好的人才更是一门艺术。那么怎样在实践中提高我们软件的价值呢，作者提出了两个重要原则：缩短开发周期和提升反馈效率。
在最近的团队项目（AI生成对联小程序）中，我参与了前端小程序的开发工作，工作中的体验让我对这篇博客的观点深以为然。在小程序的开发中，一开始的demo设计是简单粗暴的，目的只是为了将后端的工作展示出来，而没有遵照什么开发流程。从小程序的第一个版本到基本功能实现的alpha版本，小程序设计中的bug以及用户体验问题绝大部分都是在团队成员试用时发现和提出的。持续的用户反馈使我们开发和debug的方向更为明确，少了闭门造车时苦思冥想，持续的版本迭代可以在短时间内就让我们的最终结果符合大家的预期。我觉得这种软件运作流程的效率和效果要好于每天流于形式的讨论和构建。
3. 软件工程和计算机科学的有区别么?怎样才能教好、学好软件工程?
Is “Computer Science != Software Engineering” an excuse to teach programming poorly?
在这个讨论中作者提出了两个问题，下面的评论都十分精彩，我的答案是这样的：
1.Is the CS != SE argument a copout or excuse for not properly teaching programming skills.
不，我认为不是CS等同于SE。我认为计算机科学是研究计算的一门学科，他介于数学、物理等自然学科与软件工程、机械制造等技术学科之间，教会我们怎样用形式化的语言去建模实际中遇到的各种问题，用数学化的方法简洁的高效率地为人类解决问题，编程是实现模型的手段之一；软件工程是一门更注重实现具体产品的学科，更注重编程的效率和产品的质量，编程能力成为衡量软件工程人员能力的主要标准。因此不应该仅凭编程能力的高低来评判CS教育的成败。我的本科专业是自动化，大学的专业课程里面也包括控制系统设计、程序设计等课程，但是大四毕业后我并不认为自己可以马上胜任运维工程师或软件工程师的工作，但我不认为我在大学期间的学习是有问题的。大学只在培养学生扎实的数理基础和本专业的理论基础，编写程序也不过是计算机专业教学过程中的一小部分。就像自动化不等同于设备工程师专业一样，计算机科学也不是软件工程，这是事实，不是借口。
2.Regardless of your answer to question 1; if you were in the almighty position of making such a decision: would you force an emphasis on proper teaching of programming in CS courses?
我的答案依然是不。大学应该做的是为学生打好数理基础，引导学生发现自己的兴趣，并让学生有能力自我发展、自我提高自己的兴趣，不应该特定的培养学生的某方面能力。具体到程序设计上，大学老师起到的也不过是入门的引导作用，编程能力的高低绝大部分还是取决于学生的个人努力。而且我觉得讨论发起者应该想想应该用什么样的标准来衡量一个计算机系的大学生是否合格，我认为如果他可以对问题的概念有清晰的认识，并有初步计算方法建模的能力，他就是合格的。但看起来，发起者更想要一个有着四年开发经验的软件工程师，那么他应该去软件学院或是人才市场找，因为计算机专业没有义务也没有必要培养职业码农。
在这次的团队项目中，我参与了前端小程序的实现工作，我以前并没有过多接触过这方面的内容。但通过快速学习前端语言以及对问题结构分析，我依然可以在有经验的队友的帮助下，完成既定任务。我认为这种学习能力是大学应该培养的，毕竟，大学也不可能把每个领域的编程语言都教一遍。
计算机科学是一门缜密的学科，所有的理论、方法都可以在数学中被证明；而软件工程则不同，因为有人类活动的参与，所以需要符合人们的需求，需要被人类所理解维护，软件的设计要考虑科学之外的人文思想。而在学习中，因为软件工程的大多数概念没有明确的界定，我们无法单纯从概念上对软件设计的方法论有很好的理解。
通过在ASE课程的学习，我深感实践才是理解软件方法论的有效途径。在实践中，计算机科学是我们实现设想的手段，良好的沟通能力，与人协作能力以及创意都应该是软件工程从业者应该具备的素质。
5.我是CS 的, 我就要做计算机科学家!
Philip Guo是麻省理工学院的高材生，博士期间就读于斯坦福大学计算机系，履历不可谓不辉煌，但即使这样，他的博士生涯也是四处碰壁，充满苦涩。这一方面和斯坦福严苛的毕业要求息息相关，另一方面则是因为做学术和接受大学教育之间的巨大差距。Philip本科期间就已经有了不错的研究经历，而且早早定下了从事学术研究的目标。但博士第一年因为在导师的核心项目中长期从事低智力高体力的编程工作，导致他对该领域的科学研究产生了恐惧；后来因为研究兴趣不符合主流和导师方向，Philip经历了颇为苦涩的几年，一波三折后才顺利毕业；但似乎，毕业的时候他也开始对现实妥协，对是否继续从事科学研究也有了动摇。
Philip的研究经历给我的感受是这样的：
- 读博不能只靠理想，我现在对学术研究的认识、对自己的了解都还不够深入，是否要以学术研究作为职业生涯，需要时间和实践的检验；
- 做研究不是读大学，博士期间的课题不再有明确的答案等着你去寻找，在这个时候，要学会做研究的方法，找准自己的研究方向，让自己不断有成就感，对冲课题前景的不确定性带来的恐慌感；
- 要有开阔的眼界和广泛的人脉，闭门造车不会提高自己做研究的水平和研究效率，与优秀的研究者合作、与成功的团队合作可以让自己更顺利地进入行业的核心，更快更好地做出优秀的工作；
- 在MSR期间的经历对Philip来说弥足珍贵，没有冗余的基金申请、教学任务，研究者在气氛积极、目标明确的环境中更容易沉得下心来做科研；我很庆幸可以在MSRA攻读博士学位，这里即讲究创新性，又兼顾实用性，是做科研的理想殿堂。
6.习而学的软件工程教育
你觉得文中提到的方法有什么优缺点?
邹老师以某大学软件学院本科教学计划为基础的修改版，我印象深刻的有：
把 <计算机新技术与产业发展> 放到大一上学期, 并用 <浪潮之巅>, 等反映行业变化, 生动活泼的著作作为教材 (原教学计划无教材)。 希望能让大一的同学知道 “学计算机软件能做什么?” “计算机行业是怎样一个有意思的行业”。
对整个行业的认识我认为应该是每个大学生的第一课。尽早地认识自己的专业，了解专业的历史，可以让懵懂的高中生迅速成长为计算机科学的探索者，无论是有志于科研的人，或是致力于工程技术的人，或是对这个专业不感兴趣的人，都有充足的时间去培养自己的热情，规划自己的未来或者是另寻出路。
对学生要有明确的实训/实习要求, 要到高水平的企业去, 而不是去低水平的企业混日子。 可以在短学期安排, 学生也可以自行安排。
实习可以是为了提高自己的动手能力和工作能力，也可以是看看自己的前辈具体做的工作，在与前辈的交流中，对自己未来的发展规划都会有更清晰的认识，更有利于规划自己的大学生活和职业生涯。
要求所有学生在入学时就建立一个自己的专业博客, 记载自己的作业, 专业上的成长与体会, 毕业找工作时展现这个博客即可。
很好的思路，记录下自己成长的历程，不仅可以督促自己，还可以增加自己的成就感，增加自己的动力。
我认为信息类学科的工程性比较强，是比较适合习而学的学科，关键是要把握好学的进度，避免因基础知识不牢固而出现空中建楼阁的情况。
UCSD的教学方法和ASE的颇为类似，都是老师带领大家迅速地过一遍软件工程的方法论，然后通过大量的实践让学生们在”做中学“。我认为这种学习的方式（或者说氛围）比较契合大型软件公司的团队工作方式，在这种方式下培养出来的学生很容易就会适应公司的运作流程。
另外，文中说到的Facebook等公司对实习生的要求，对互联网充满热情且极其聪明，我也十分认同，通过软件工程课上的团队项目，这种特质是很容易被发现或培养的。软件工程不同于传统的科目，需要通过大量的、快速的review和meeting来更正自己的方向，反思自己的工作模式。在我们两次的团队项目中，及时的沟通和代码复审都贯穿始终，很好地帮我认识到了项目运作的流程。