软工+C(5): 工具和结构化(重构中, part 1...)

时间:2024-11-21 13:38:01

// 上一篇:Alpha/Beta换人
// 下一篇:最近发展区/脚手架


目录:
** 0x01 讨论:工具/*
** 0x02 讨论:结构/演进
** 0x03 讨论:行为/活动
** 0x04 讨论:开放/封闭
** 0x05 推荐:善用/佳软

0x01 讨论:工具/*(refactoring...)

软件工程/计算机相关专业的一个特点是会使用到众多的工具,工具的使用是从程序猿进化到程序员的一个关键要素。软件工程师之间流传着一句话:“不要重新发明*”,*,正是人类社会演化过程中不断被重复发明的一个典型工具。事实上,*总是被重复重新发明的。工具被发明的方式有几种方式:

  • 在一个地区里经过长期演化,被独立发明出来。
  • 一个先进地区A的工具的精细设计图纸,被传播到另一个地区B,B地区的人经过这个精细设计图纸,从蓝图开始复制+改进,制造出类似的工具来用。
  • 一个先进地区A的工具没有图纸被传播到B,但是A地区使用该工具的思想被传播到了B,B地区的人受这种思想的启发,利用本地区的条件,经过一些发明家的不断尝试,造出了自己地区的该种工具。

这是在《枪炮、病菌与钢铁》这本书的“需求之母”里提到的。先进地区对工具的使用,往往会导致实力上巨大的差距。在教学中,我们应该善于把和知识点、方法论匹配的工具融入其中,通过工具这个媒介,让知识方法的教学更好的落地。例如福州大学的软件工程教学中在各个环节使用了诸多工具。那么使用工具的选择与使用,有哪些需要注意的呢?

首先,理解手工操作和使用工具的各自优劣,合理结合。有的人说:“我喜欢用手绘的方式画功能分解、画原型、画燃尽图,手绘的成本为零,拍个照片就能发出来”。手绘适合做草图,是一种快速松散的示意方式,但是只能处理有限的适合草图的情况。而工具则具有下面这些特点:

  • 使用工具结构化数据,便于增/删/查/改,草图不适合事后修订。
  • 使用工具规范化数据,便于协同编辑,每个人画的草图只适合当面讲解。
  • 使用工具精确化细节,例如UI设计,产品原型设计,只有通过工具设计的才能让下一个环节便利地作为开发/实现的设计文档。
  • 使用工具节省时间,好的工具是可编程的,可以通过工具内,或者工具外的脚本来定制批处理任务。
  • 使用工具来约束工作的模式,例如Git背后是如何做源代码版本管理,如何选择多人协同开发的工作流。

其次,应该选择什么工具。例如,希望让学生用思维导图工具做功能分解,那么应该用哪种工具呢?有两种基本的方式:

  • 选择和对比本身也是一个好的练习过程,我们可以列出可选的几种选择,然后通过对比、体验,找出适合自己的选择。
  • 对于每一种功能,直接推荐同类产品里最佳的那种,让学生一开始就通过最佳设计的工具建立正确的概念,但是要注意便利工具背后的内核。

第三,挑选工具的过程训练什么能力? 例如:“我要买个电脑,买哪个牌子好”。同样可以是这样的:谁问这个问题就告诉他在自己的价位里对cpu、内存、硬盘、显示器之间对不同牌子做对比,最后根据自己的需求(娱乐、开发、游戏、商务)做出他自己的决策。选择的过程包含了几个要素的练习:

  • 找出同类产品Top3,学会做具体的竞品分析。
  • 找出“我”自己希望使用这个工具解决的问题是什么,希望这个工具有什么功能,做自我需求分析。
  • 做一个筛选和匹配,自己做出决策。

最后,如何使用工具? 每个工具有100%的功能,你是否需要100%的都掌握并使用?工具的说明书很多,教程也很多,应该从头看到尾么?使用工具的两个重要方面如下:

  • 2/8原则:一个不成文的经验是每个工具的20%的常规功能解决了80%的高频问题,80%的不常见功能解决20%的低频问题。
  • 边用边查原则:通过日常的使用,随时查阅手册,通过经常使用而让肌肉自动记忆常规操作,通过随时查阅手册来增量理解操作背后的原理。

0x02 讨论:结构/演进

结构化意味着做事的方式有章法,有必要的约束。就像程序语言从非结构化演化到结构化,再从结构化演化到面向对象的过程,教学的过程也需要对结构进行组织。例如:博客园提供了班级博客的支持,一个老师刚接触的时候,把班级博客搬到了线上,这很好。但是接下来会开始遇到一些具体的问题:

  • 学生从来没写过博客,一开始只能简单表达下几句,图片、表格、代码的排版也比较乱,怎么办?这就涉及到教师应该要布置好题目,例如,通过设计第一个一问一答的博客作业引导学生先有结构的写博客;例如,通过推荐使用MarkDown排版,并在一开始的作业里提供MarkDown模版让大家尽快上手,也可以参考这个教程:http://www.cnblogs.com/math/p/se-tools-001.html
  • 学生人数很多,怎么办?可以分拆线上班级,就像集美大学软件工程班级有130个人,拆成4个线上班级,这就有了班级的子结构,有了子结构很多环节的展开就会有好的粒度。拆分了班级博客后,就需要4个助教怎么办?可以是高年级的学生担任助教、可以是研究生、可以是企业里的软件工程师。
  • 有了助教,是否就万事大吉了?既然是助教,就需要自身基础扎实、能力足以给学生做辅助的水平,所以助教也需要学习如何做好工作。例如在软件工程实践《构建之法》的教学中,有许多软件工程师助教通过实践得到了一些经验,这些经验都可以被学习和复用,可以参考这里面的助教链接:http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html
  • 助教到位了,是否就足够结构化了?有学生、有助教、教师怎能缺席呢?教师在其中的作用很大。教师起到了线上线下结合的中间枢纽工作。例如:教师需要有完整的学期开始和结束的时间概念,需要一开始就和助教一起设计出整个学期的课程环节设计,正如构建之法一开始就建议一个16周的环节安排,从个人-结对-案例分析-团队Alpha-团队Beta这样一个路线清晰的结构化环节设计一样。编程语言课程的老师,测试课程的老师,也都需要一开始就有一个明确的环节结构,并且每个环节的开始结束时间要一开始就协商设计。
  • 再回头,学生提交的作业博客应该是怎样的?有的老师不注重引导和checklist的结构设计,结果学生只是拍一张纸上的作业发到博客了事,甚至连照片都是歪的。这就属于没有意识到结构的重要:教师布置的作业就是一个模仿对象,需要有好的标题、好的截止日期、明确的评分规则、清晰的checklist,checklist应该符合SMART原则
  • 助教需要和教师一期一期的去迭代,从题目设计、作业点评、代码审阅、评分发布 四个环节(结构),一期一期盯着开始和截止日期两个地方去做好里程碑。为什么强调一期一期?
    • 教师需要在一期快截止的时候,就开始拟好下一期的题目稿子
    • 初稿交付与助教协作编辑修订和确认checklist
    • 同时分工必要的tutorial教程(例如git、单测、性能测试)
    • 准备必要的模版,例如在coding.net上准备好单元测试的模版,让学生fork去实现
    • 准备必要的团队项目素材,设计题目,每个题目都有哪些约束、硬性要求?怎样把看似鸡肋的环节落地。
    • 截止日期到的时候,助教需要根据过程性的点评拟好合适的针对checklist的评分标准
    • 发布的评分博客应该符合怎样的结构?怎样有效点评公共问题?

0x03 讨论:行为/活动

正如《像导演一样思考》这本书所说的:

"对说故事而言,有一种本能是不可或缺的:发现观众喜好的能力。不论是去村庄、医院,或是开放的田野,他们总得重新学习如何抓住观众的注意力。 - 双重观点:其中一个观点是深入剧本的世界,通过探究与同情剧中人物最深的欲望和弱点来发掘它的活力;另一个观点则是把焦点集中在结构上。"

"不过,就和每一种艺术形式一样,光有技术根本不够。一个导演要成功,必须具有创造力、创作才能、直觉以及最重要的----热情。 "

"正如演员一站上舞台就应该图谋不轨(an ax to grind,或者说“具有强烈的企图心”),导演艺术家“必须有话要说”。这些话不需要是社会或者政治宣言,也不应该替代或高于戏剧本身要说的话。必须有话要说,指的是传达一种独特观点的热情。因为有话要说,所以说故事,所以当导演。"

"戏剧是由一连串有意的行为和活动交织而成,因此,追求某个目标或欲望的具体情节,是深入剧本的持续不变的通路,对大部分的演员和导演来说,也是最清楚的通路。故事情节是一出戏的内在机制和引擎,确认情节对于形成完整的概念和指导演员都是至关重要的。你一旦破译了每一场戏的情节,整出戏整体的情节(或说目标)就会浮现。如果你有效地明确表达每一个情节,两个(或两组)主要角色的目标就会形成核心冲突,这就是叙述故事和传达概念的关键。 "

教学中,需要合理的工具与结构。

0x04 讨论:开放/封闭

正面思考,对于平台和工具的选择,我个人一直偏好选择开放性强的。我理解的开放并不只是把东西放到网站即可,例如对于教学平台的选择:

  • 可访问性,任何人可以公开访问,可访问并非是个网站就有的
  • 与大广场融合,这是多样性的目的,例如技术社区群体,有大量一线开发者,程序员,工程师,那么它的多样性和广场效应就比较高。
  • 有效的外部交流,开放的目的除了能推进内容编辑的质量,也是有效外部参与交流的属性。
  • 双向的交互,封闭的平台只有单一的教师学生,缺乏课堂内部和外部多样交流,这就像高校要避免近亲繁殖一样。
  • 内容是否能持续迭代改进,单向的发布平台,还是静态的,有点填鸭式的方式。
  • “方便” 有两面性,很多人一味追求全自动化,忘记了教学中人和内容建设的重要属性,实际上再自动化也未必能产生高质量,如果对质量不做深入理解,就容易走入误区。
  • 协作的力量,教学过程,线上线下的协作过程,本身就是一个重要的过程,协作本身的价值和意义是否被重视 考虑这些因素,有助于理清很多本质和迷思之间的界限。
  • 是否只是变成任务发布平台,还是有有质量内容的积累,这对于老师,学生都是重要的。很多时候不能只看到任务,而看不到内容积累的属性
  • 学生在课程过后还会继续在上面积累么?认真思考 教师/助教/学生/路人 四种“角色人”的独立性和主动性。

反面思考,从可操作性方面来说,要从低预期低起点开始循序渐进做起:

  • 我常常求上限,其实能保持比底线+20%也是很重要的。
  • 具体的需求,可能各自不同,面对的人数不同,希望借助工具解决的问题可能也不同。
  • 技术成熟度曲线,比大众的平均值快一步就很不错,大众未必会全部都愿意求上限,例如比之前好一些就不错,比之前自动化一些就不错,这些不同层面的改良也都是值得鼓励的。

0x05 推荐:善用佳软

召唤神龙,获得独家:开发神器