RSTD_第三次作业
最近抽空阅读了邹欣老师的《构建之法》的前五章，虽然这是一本介绍软件工程的书籍，但其中介绍的观念和方法对于其他领域，也有着普遍的指导意义，感觉蛮受用。
这边结合我大学本科期间在科创团队两年多的科研经历简单地谈谈自己的感悟。
首先来回答一下老师给出的两个问题
1、软件工程师应具备的能力素质
这边首先把能力素质分成两类。一类是技术技能，即针对某项活动工作的，涉及专业知识和专门领域的分析能力的，因岗位不同而不同的技能；一类是职业技能，即区别与技术技能，对于各个领域的工作都很重要的技能
对于一名软件工程师所需要的技术技能包括：
知识: 对Java, C/C++/C#, 诊断/提高效能的技术, 对device driver, kernel debugger 的掌握；对于某一开发平台的掌握。
经验: 对问题领域的知识和经验的积累 (例如: 对于医疗行业的了解, 对于金融行业的了解)
思想：通用的软件设计思想, 软件工程思想的提高
我之后将从事的算法工程师其实也和上面比较类似，技术技能大概包括：
C/C++/Matlab 开发经验；
算法研究和开发的能力，较强的编程能力；
技术技能的培养和训练，离不开对知识的学习和熟练运用，以及在项目实践中不断地积累经验。
拥有扎实的技术技能固然重要，它是你能够做成一项工作的基础，但职业技能对于工作亦不可或缺。它包括自我管理的能力、 表达和交流的能力、 与人合作的能力;、把任务按质按量完成的执行力......
关于如何提升职业技能，这本书也给出了许多好的方法。
比如在与人合作交流方面，本书介绍了“给个汉堡包”的反馈方式
在给别人反馈的时候, 我们最想让别人接受的当然是最有营养的 [肉]， 但是光有肉, 别人不好拿, 也不好吃。 你不能强迫别人下咽。 我们要向做汉堡包、三明治的师傅们学习 - 把反馈做成汉堡包:
先来一片面包, 做好铺垫, 例如可以从双方的共同点, 团队共同的愿景讲起, 让对方觉得处于一个安全的环境。
再把肉放上，这时就可以把 建设性的意见 (constructive feedback) 油炸好, 加上生菜, 佐料等。
......
然后再来一片面包, 盖上。 这时候可以呼应开头, 鼓励对方把工作做好。
————摘自 4.6 两人合作的不同阶段和技巧
在完成任务的执行力方面，提出了“ Scrum/Sprint ”方法等等
第一步: 找出完成产品需要做的事情 – Product Backlog, Backlog 翻译成“积压的工作”, “待解决的问题”, “产品订单”都可以
第二步: 决定当前的冲刺需要解决的事情 – Sprint Backlog.
第三步: 冲刺 (Sprint). 在冲刺阶段, 外部人士不能直接打扰团队成员。 一切对交流只能通过SCRUM MASTER 来完成。 这一措施较好地平衡了 “交流”和 “集中注意力”的矛盾。 有任何需求的改变都留待冲刺结束后再讨论
第四步: 得到软件的一个增量版本，然后在此基础上又进一步计划增量的新功能和改进。
————摘自 6.1 敏捷的流程
2、基于模型的设计流程相对于其他开发流程的优缺点
这边是网上找到的一个基于SIMULINK基于模型设计作用的回答
基于模型的设计能给我们的开发带来什么样的好处？
弄清这个问题，是我们在后续有效使用基于模型设计开发嵌入式软件的前提。 这里我引用一下若干年前MathWorks公司CEO——Jack Little的说法，在嵌入式软件开发过程中，基于模型的设计至少可以给我们带来四个方面的好处：
1. 图形化设计
对于基于模型的设计来讲，图形化设计是天然的、固有的。图形化的优势，工程师们都非常清楚，明确、清晰、唯一，便于交流、便于维护，这也是为什么就算我们不用基于模型设计的方式开发软件，也需要在设计文档中画流程图、状态机的原因。
需要注意的是，我们需要把Simulink模型画到清晰、明确，便于交流、便于维护。
2. 早期验证
话说软件开发过程中，bug的引入难以避免。人非圣贤、孰能无过，引入bug不可怕，能否尽快发现bug对整个开发过程至关重要。这里提到“早期”，什么是“早期”？你某一个阶段的工作产品出来之后，紧跟着就要做验证工作。对于早期验证，以前的方式比较单一，通常我们使用评审的方式去实现最早期的验证，以至于Peer Review在很多公司的流程中被固化下来了，写完文档要评审，做完设计要评审，写完代码还要评审，写好测试用例也要评审。如果我们翻看一些软件工程的教材或者文献，大家对评审的评价非常高，因为在这个阶段每发现一个错误，都会给后续的开发过程带来很多便利，但遗憾的是，评审的效率通常不高。
使用基于模型设计去开发软件，除了评审，我们还有更高效的早期验证方式，包括Simulink模型本身固有的仿真，以及通过形式化方法工具对模型进行形式化的分析。
3. 代码的自动生成
自动生成代码通常是使用基于模型设计进行软件开发的工程师最容易关注的优势。代码都不用写了，“码农”从此跟我无关，还有什么比这事更美好的呢？确实，从开发效率来讲，这个环节，对于效率的提升，是无法量化的，原本需要一个月时间写完的代码，现在可能只要一个上午或者两个小时就可以搞定，谁帮我算一下工作效率提升了多少？不少人对代码生成的开发效率没有质疑，但对生成代码的代码效率却不够放心。这事，很多人都比过，SAE上也能找到这样的论文。通俗点讲，从效率上，生成的代码在各种效率上（RAM、ROM、执行时间等）不比大学毕业后工作了5年的工程师差。当然，遇到那种“写代码像写诗一样”的工程师，代码生成工具还是要甘拜下风的。不过，“写代码像写诗一样”的工程师我们又见过几人？
4. 文档自动化
对于文档，我说两点：
- 工程师大多不愿意写文档；
- 开发过程中文档又是不可缺少的。
有三个字足以证明上面两条，那就是“补文档”。在基于模型设计的开发过程中，我们可以通过软件读取模型中相关信息并自动创建文档，实现文档自动化。
上面提到了基于模型设计能给我们带来的好处，也正是因为基于模型的设计可以给我带来上述好处，所以我们才应该使用基于模型的设计。
3、个人感悟
这边就想到哪点写哪点吧，后面也会随着进一步的阅读持续更新~
3.1 技能的反面
关于这点，书中给出了“玩魔方”的例子
能够照着口诀还原魔方能算是“精通”魔方吗？
质问“精通”的真正意义，并提出“技能”的层次（高、中、低）
拿IT专业的面试举栗，如果一个自称“ 精通 Visual Studio C# 编程”的大学生，在面对写一段冒泡排序的任务时，还在考虑“怎么开始一个C# 的命令行程序”、“怎么开始一个C# 的命令行程序呢?”的问题，把时间都花在“解决 (低层次) 问题”上面， 而面试官想考察的“算法技能”、 “C# 程序设计技能” 都无暇顾及，那这所谓的“精通”怕是自欺欺人吧。
那怎么提高技能呢?
答案很简单, 通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。