一、个人总结
在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；
请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。
第一部分：硬的问题。展现出价值和能力。
| 类型 | 具体技能和面试问题 | 现在的回答 |
|---|---|---|
| 语言 | 拿手的语言 | java,代码量没估算过 |
| 软件实现 | 有没有在别人的代码基础上进行改进，你是怎么读懂别人的代码，你采取什么方法不影响原来的功能，遇到的bug是什么，怎么解决，bug出现的原因 | 有在别人的代码基础上进行改进，通过原有的注释，有意义的命名来看清整体思路，继而看懂该代码实现的功能，改进时，是尽量能保留原来的方法，在这基础上调用。自己可以重载或新加函数方法，需要时调用该方法，不破坏原来的功能，代码也比较清晰。bug出现是因为原先代码没有考虑到一些特殊情况，调用时发现有问题。 |
| 软件测试 | 你是怎么测试自己的代码，怎么测试别人的代码 | 利用junit测试，或自己设置一些特殊值来测试。 |
| 效能分析 | 你写过最复杂的代码是什么？你是如何测量和改进它们的效能的，用了什么工具，如何分析的 | 最复杂的代码可能是大一用c语言写万年历吧。还有上次的四则运算。 |
| 需求分析 | 你做过多少个有实际用户的项目，用户人数多少，你的项目有什么创新之处 | 做过的完整的项目就这次的小程序，用户目前100多 |
| 行业洞察力 | 你最感兴趣的领域是什么，这个领域过去十年有什么创新，你分析过这个领域前十的产品吗，请分析一下他们的优劣，你要进入这个领域，如何创新 | 大数据 |
| 项目管理 | 你参加过项目管理吗，如何决定各个任务的优先顺序，如果项目不能及时完成，你要怎么办 | 参加过，先从需求分析做起，然后设计，编码，测试。如果项目不能及时完成，就团队一起商讨，加班加点 |
| 软件设计 | 你做过架构设计，模块化设计，接口设计吗？请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果 | 做过系统设计，做的不好 |
| 质量意识 | 你是怎么做代码复审的，如何提高代码质量 | 我做代码复审主要是添加注释，代码行的缩进，让整体代码清晰明了，还有关键代码函数值打印 |
| 工具/社区 | 你在各种开发平台都使用过什么样的工具，自己写过什么工具来改进工作效率？给社区贡献过代码吗？github有分享过代码吗？你写技术博客坚持多久了，读者最多的是哪篇 | 测试工具junit，效能工具jprofiler，还有xml数据解析。自己没写过。在码云上分享代码 |
| 团队协作 | 描述你在项目中如何说服同伴采取你更好的方案，或是听取别人的意见改进自己的方案，如何说服懒惰的同伴加紧工作 | 跟项目成员说明方案的优势，不会对原先的计划产生影响 |
| 理论素养 | 你上过什么数学，计算机或是理论课，举出具体的例子，如何帮你解决问题 | 高数，线性代数 ，离散数学，数据结构等，利用离散数学的逻辑，数据结构编写代码，看代码复杂度 |
第二部分：软的问题，在成长路上学到了什么？
| 编号 | 问题 | 解决方案 |
|---|---|---|
| 1 | 保持高标准，不要受制于破窗理论(broken windows theory)[i]。当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。” | 一直主动这样做 |
| 2 | 主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了[ii]。 | 不但主动做， 还会影响同事一起做好 |
| 3 | 经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。 | 看了就忘 |
| 4 | DRY （Don't Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式。 | 如果有明确要求，我可以做好 |
| 5 | 消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。 | 想做，但是不知道怎么衡量效果 |
| 6 | 通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。 | 不但主动做， 还会影响同事一起做好 |
| 7 | 设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。 | 一直主动这样做 |
| 8 | 估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。 | 不但主动做， 还会影响同事一起做好 |
| 9 | 图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。 | 正在学习命令行工具 |
| 10 | 有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手 | 还会学习和使用各种编辑器的扩展 |
| 11 | 理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。 | 从来没听说过 |
| 12 | 代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。 | 经常用 |
| 13 | 在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加 log. | 只会printf |
| 14 | 重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事，不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设，你认为不可能发生的事情在现实世界中往往会发生。 | 从来没听说过 |
| 15 | 只在异常的情况下才使用异常 (Exception), 不加判断地过多使用异常，会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。 | 一直主动这样做 |
| 16 | 善始善终。如果某个函数申请了空间或其他资源，这个函数负责释放这些资源。 | 一直主动这样做 |
| 17 | 当你的软件有多种技术结合在一起的时候，要采用松耦合的配置模式，而不是要把所有代码都混到一起。 | 一直主动这样做 |
| 18 | 把常用模块的功能打造成独立的服务，通过良好的界面 (API) 来调用不同的服务。 | 不但主动做， 还会影响同事一起做好 |
| 19 | 在设计中考虑对并行的支持，这样你的API 设计会比较容易扩展。 | 考虑在适当的层次支持并行 |
| 20 | 在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。 | 一直主动这样做 |
| 21 | 重视算法的效率，在开始写之前就要估计好算法的效率是哪一个数量级上的（big-O）。 | 主动测试程序效率，以验证估算 |
| 22 | 在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。 | 想用，但不知道工具 |
| 23 | 经常重构代码，同时注意要解决问题的根源。 | 一直主动这样做 |
| 24 | 在开始设计的时候就要考虑如何测试 ，如果代码出了问题，有log 来辅助debug 么? 尽早测试，经常测试，争取实现自动化测试，争取每一个构建的版本都能有某些自动测试。 | 项目没有安排时间，我也没有提这事 |
| 25 | 代码生成工具可以生成一堆一堆的代码，在正式使用它们之前，要确保你能理解它们，并且必要的时候能debug 这些代码。 | 从来不看那些代码 |
| 26 | 和一个实际的用户一起使用软件，获得第一手反馈。 | 不但主动做， 还会影响同事一起做好 |
| 27 | 在自动测试的时候，要有意引地入bug，来保证自动测试的确能捕获这些错误。 | 如果有明确要求，我可以做好 |
| 28 | 如果测试没有做完，那么开发也没有做完。 | 一直主动这样做 |
| 29 | 适当地追求代码覆盖率：每一行的代码都覆盖了，但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件。 | 要覆盖至少60% |
| 30 | 如果团队成员碰到了一个有普遍意义的bug, 应该建立一个测试用例抓住以后将会出现的类似的bug。 | 一直主动这样做 |
| 31 | 测试：多走一步，多考虑一层。如果程序运行了一星期不退出，如果用户的屏幕分辨率再提高一个档次，这个程序会出什么可能的错误? | 如果有明确要求，我可以做好 |
| 32 | （带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜。 | 不但主动做， 还会影响同事一起做好 |
| 33 | （带领团队） 不要停留在被动地收集需求，要挖掘需求。真正的需求可能被过时的假设、对用户的误解或其他因素所遮挡。 | 不但主动做， 还会影响同事一起做好 |
| 34 | （带领团队）把所有的术语和项目相关的名词、缩写等都放在一个地方。 | 大家看代码就好 |
| 35 | （带领团队）不要依赖于某个人的手动操作，而是要把这些操作都做成有相关权限的人士都能运行的脚本。这样就不会出现因为某人休假而项目被卡住的情况。 | 一直主动这样做 |
| 36 | （带领团队）要让重用变得更容易。一个软件团队要创造一种环境，让大家有轻松的心态来尝试各种想法 （例如，模块的重用，效能的提升，等）。 | 不但主动做， 还会影响同事一起做好 |
| 37 | （带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的进度安排更可靠，质量更高。 | 不但主动做， 还会影响同事一起做好 |
| 38 | （带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？ | 不但有明确和一致的处理原则，而且对于影响团队士气的任何事情追究到底 |
第三部分 团队管理源代码的水平
| 我们的团队采用码云管理源代码和文档，数据文本保存在项目中，后阶段会利用数据库存储在云服务器上。各成员均可管理码云的项目，查看其他成员的提交修改记录。除了在码云上保存代码，也有备份到云端，防止误修改。 |
二、回答问题
我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答
Q1.
P55第三章“软件工程师的成长”里举例
很多学生学了一些编程语言，读了一些技术博客，一般都豪情万丈，做一个项目恨不得展现平生所学，再加上前沿技术，做一个轰动
的创新。每天都有很多宏大的新想法，惊世骇俗的评论冒出来，争论美女/张飞/巨石的重构问题，对一些通用的框架/平台提出一些人云亦云的评论等。
这是作者在书里面提到软件工程师的思维误区包括过早的扩大化/泛化的例子，我觉得学会了新技术就想要马上实践是正常的，有时可能会有出人意料的突破，但或许这些想法可能会不切实际，新技术中有很多不确定的东西，机遇与风险并存。那应该如何去尝试与选择应用新技术是最适宜的呢？
- 参考资料： 折腾！新产品千万不要用新技术来开发！
| Answer:想尝试新的技术时，要考量自身的情况，确定自己的精力和时间是否足够自己完成这一项技能学习目标。还有在项目中应用这一新技术时，能否取得实质性的效果，例如如果新技术在处理大数据上有优势，但你的项目并不需要做大量的数据处理，就不必要使用。但是要主动了解新的技术进展，对新技术不能一知半解就想应用，实践时也要判断好项目合适不适合应用此新技术。 |
Q2.
p388这里作者说到要对选择合适的时机，对不同的人施以不同的引导。里面对积极的初学者的能力方面的帮助里提到
要定义他们在团队中的角色和范围，限制自主性发挥;
作者划分了四个象限，从无知的乐观状态->知情的悲观状态->价值危机->知情的乐观状态。对每个状态的人给出了不同的引导，定义角色和范围有利于初学者找到方向，但是限制自主性发挥这个我不太理解，自主性发挥会带来什么问题。应该工作上限制，学习上提倡吗？
| Answer:在一个团队中自主性发挥也包括创造性的发挥，这种发挥对项目有帮助的发挥不应该限制。而敏捷开发过程中每天分配的任务，成员还是应该按每日计划完成任务，而不是随意发挥不顾规则，导致项目各模块无法衔接上。但是队员实现方式可由队员自主决定。 |
Q3.
P114敏捷开发
看了敏捷开发的流程，包括了找任务，细化任务，沟通完成任务，总结，实现快速迭代。参考资料里提到
而敏捷开发的意义在于它只关注文档中的重要点，或者尽可能的去简化文档，敏捷开发其实更注重的是人与人之间的沟通、交流。所以它强调以人为核心。
把设计文档的时间用来进行团队沟通，书里作者还提到适合敏捷流程的团队要求是：自主管理，自我组织，多功能型。所以对团队各成员的综合能力要求比较高。项目成员较多的情况下，沟通理解能力可能不同，相互交流需要较多的时间，要怎么样让每个人理解到同一意思，确保任务有效传达？
- 参考资料： 谈谈我理解的敏捷开发
| Answer:沟通之前要先理清自己所要让其他成员知道的信息，其他成员不太了解的地方要进行更为详尽的解释，讨论结束后还有疑惑或出现问题要及时与团队成员汇报和沟通,然后及时解决。这次的冲刺过程中，整合各个模块时，遇到有不太理解的地方，就立马与负责的成员沟通，跟她说明问题，解释好问题发生的原因，想要询问的问题，对方明确了解后才能给出满意的答复，进展的也会比较顺利。 |
三、再提问题
同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。列出一些事例或资料，支持你的提问 。说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
一个模板可以是这样：
我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。【或者】我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
Q1.
P178第八章“计划与估计”里提到
软件时间的估计，事实上是多个估计值的乘除法（估计的需求，估计得需求复杂度，估计的技术难度，估计的人员能力，人员流动和
不可替代性），如果在这些估计都差一两个数量级，那么我们最终的结果就会偏离十万八千里。
项目开发过程中会遇到成员发生紧急情况，无法按期完成项目任务。前期估算要考虑到这种风险增加估算的时间吗？项目时间紧迫的话，写的仓促可能一周写的代码需要花两周来改bug，得不偿失。且没有项目开发经验的团队，对项目的复杂度无法进行准确的预估。所以怎么才能较好的估算项目时间？
- 参考资料： 估算项目的时间进度！
Q2.
P200第九章“领导力-高效的团队讨论”里举例
会议的参加者想到哪里就说到哪里，各人的情绪也自由地发挥，虽然热闹，确是一种无序的交流，效率不高，我们应该把这些无序的活动逐步约束为有序的活动，然后让大家通过一系列的思维活动来分析问题，在一个时间段内只做一类思维活动，决定行动。
这是作者在书里面提到项目开发过程组织会议时会出现的情况。里面提到”把无序的活动逐步约束为有序的活动“，“在一个时间段内只做一类思维活动”，这一点我不太理解，产品经理该怎么做才能让成员按照一定的思维方式走，在每个阶段做合适的思维活动，以推动会议进程。
- 参考资料： 如何开好项目会议
Q3.
P134第七章“MSF基本原则”里包括
推动信息共享与沟通。就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到的技术机密，安全性等信息要采取必要的保护措施。成员之间的交流要简明，不必为了交接而搞出许多文档。
里面提到要讨论包括所有需要知道的人员，决定要公布给项目的所有成员；信息公开是什么形式？怎么才能做到随着项目事件的发生自然地传递到关心这些事情的人那里。
Q4.
P121第六章“敏捷流程”里提到
程序员写完功能的时候，我们感觉好像项目完成了80%，殊不知后面的20%往往要花费80%的时间
正如作者所说，软件开发过程中的一个特点就是随时会碰到未知的问题，特别是没有很多经验的团队。这时候碰到技术难题，怎么预估需要花费多少时间解决？要如何判断该去花时间攻克还是跳过，以免影响项目的进度？
- 参考资料： 开发过程中遇到问题了怎么办
Q5.
P247第十一章“每日构建”里提到
对于下一个导致构建失败的成员，授予“构建大师”称号，构建大师做下面的事。
1.负责管理构建服务器。
2.调试构建，负责找错，并分析出错的原因。
3.负责把“构建大师”称号和责任交给下一个导致构建失败的成员。
4.“构建大师同时向团队的”构建之法基金“存入50元，以供大家将来团队构建之用。
让不擅长的人做事可能可以督促他并提高他个人的能力，但是把整体交给他会不会降低团队每日构建的效率。
【附加题】请将问题提交至豆瓣：https://book.douban.com/subject/27069503/， 并在博客中给出链接
在豆瓣页面的最下方 “读书笔记” 那里发言， 《构建之法》的作者会亲自答复问题