标签：相关 日志 mon 语言 exception 令行 http 关于 多少
在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阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答
?P55第三章“软件工程师的成长”里举例
很多学生学了一些编程语言，读了一些技术博客，一般都豪情万丈，做一个项目恨不得展现平生所学，再加上前沿技术，做一个轰动
的创新。每天都有很多宏大的新想法，惊世骇俗的评论冒出来，争论美女/张飞/巨石的重构问题，对一些通用的框架/平台提出一些人云亦云的评论等。
?这是作者在书里面提到软件工程师的思维误区包括过早的扩大化/泛化的例子，我觉得学会了新技术就想要马上实践是正常的，有时可能会有出人意料?
?的突破，但或许这些想法可能会不切实际，新技术中有很多不确定的东西，机遇与风险并存。那应该如何去尝试与选择应用新技术是最适宜的呢？
answer:想尝试新的技术时，要考量自身的情况，确定自己的精力和时间是否足够自己完成这一项技能学习目标。还有在项目中应用这一新技术时，能否取得实质性的效果，例如如果新技术在处理大数据上有优势，但你的项目并不需要做大量的数据处理，就不必要使用。但是要主动了解新的技术进展，对新技术不能一知半解就想应用，实践时也要判断好项目合适不适合应用此新技术。?p388这里作者说到要对选择合适的时机，对不同的人施以不同的引导。里面对积极的初学者的能力方面的帮助里提到
要定义他们在团队中的角色和范围，限制自主性发挥;
?作者划分了四个象限，从无知的乐观状态->知情的悲观状态->价值危机->知情的乐观状态。对每个状态的人给出了不同的引导，定义角色和范围有利?
?于初学者找到方向，但是限制自主性发挥这个我不太理解，自主性发挥会带来什么问题。应该工作上限制，学习上提倡吗？
answer:在一个团队中自主性发挥也包括创造性的发挥，这种发挥对项目有帮助的发挥不应该限制。而敏捷开发过程中每天分配的任务，成员还是应该按每日计划完成任务，而不是随意发挥不顾规则，导致项目各模块无法衔接上。但是队员实现方式可由队员自主决定。?P114敏捷开发
?看了敏捷开发的流程，包括了找任务，细化任务，沟通完成任务，总结，实现快速迭代。参考资料里提到
而敏捷开发的意义在于它只关注文档中的重要点，或者尽可能的去简化文档，敏捷开发其实更注重的是人与人之间的沟通、交流。所以它强调以人为核心。
?把设计文档的时间用来进行团队沟通，书里作者还提到适合敏捷流程的团队要求是：自主管理，自我组织，多功能型。所以对团队各成员的综合能力?
?要求比较高。项目成员较多的情况下，沟通理解能力可能不同，相互交流需要较多的时间，要怎么样让每个人理解到同一意思，确保任务有效传达？
answer:沟通之前要先理清自己所要让其他成员知道的信息，其他成员不太了解的地方要进行更为详尽的解释，讨论结束后还有疑惑或出现问题要及时与团队成员汇报和沟通,然后及时解决。这次的冲刺过程中，整合各个模块时，遇到有不太理解的地方，就立马与负责的成员沟通，跟她说明问题，解释好问题发生的原因，想要询问的问题，对方明确了解后才能给出满意的答复，进展的也会比较顺利。同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。列出一些事例或资料，支持你的提问 。说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
一个模板可以是这样：
我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。【或者】我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
?P178第八章“计划与估计”里提到
软件时间的估计，事实上是多个估计值的乘除法（估计的需求，估计得需求复杂度，估计的技术难度，估计的人员能力，人员流动和
不可替代性），如果在这些估计都差一两个数量级，那么我们最终的结果就会偏离十万八千里。
?项目开发过程中会遇到成员发生紧急情况，无法按期完成项目任务。前期估算要考虑到这种风险增加估算的时间吗？项目时间紧迫的话，写的仓促可?
?能一周写的代码需要花两周来改bug，得不偿失。且没有项目开发经验的团队，对项目的复杂度无法进行准确的预估。所以怎么才能较好的估算项目?
?时间？
?P200第九章“领导力-高效的团队讨论”里举例
会议的参加者想到哪里就说到哪里，各人的情绪也自由地发挥，虽然热闹，确是一种无序的交流，效率不高，我们应该把这些无序的活动逐步约束为有序的活动，然后让大家通过一系列的思维活动来分析问题，在一个时间段内只做一类思维活动，决定行动。
?这是作者在书里面提到项目开发过程组织会议时会出现的情况。里面提到”把无序的活动逐步约束为有序的活动“，“在一个时间段内只做一类思维活?
?动”，这一点我不太理解，产品经理该怎么做才能让成员按照一定的思维方式走，在每个阶段做合适的思维活动，以推动会议进程。
?P134第七章“MSF基本原则”里包括
推动信息共享与沟通。就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到的技术机密，安全性等信息要采取必要的保护措施。成员之间的交流要简明，不必为了交接而搞出许多文档。
?里面提到要讨论包括所有需要知道的人员，决定要公布给项目的所有成员；信息公开是什么形式？怎么才能做到随着项目事件的发生自然地传递到关?
?心这些事情的人那里。
?P121第六章“敏捷流程”里提到
程序员写完功能的时候，我们感觉好像项目完成了80%，殊不知后面的20%往往要花费80%的时间
?正如作者所说，软件开发过程中的一个特点就是随时会碰到未知的问题，特别是没有很多经验的团队。这时候碰到技术难题，怎么预估需要花费多少?
?时间解决？要如何判断该去花时间攻克还是跳过，以免影响项目的进度？
?P247第十一章“每日构建”里提到
对于下一个导致构建失败的成员，授予“构建大师”称号，构建大师做下面的事。
1.负责管理构建服务器。
2.调试构建，负责找错，并分析出错的原因。
3.负责把“构建大师”称号和责任交给下一个导致构建失败的成员。
4.“构建大师同时向团队的”构建之法基金“存入50元，以供大家将来团队构建之用。
?让不擅长的人做事可能可以督促他并提高他个人的能力，但是把整体交给他会不会降低团队每日构建的效率。
在豆瓣页面的最下方 “读书笔记” 那里发言， 《构建之法》的作者会亲自答复问题
标签：相关 日志 mon 语言 exception 令行 http 关于 多少
原文地址：https://www.cnblogs.com/zyjjj/p/9029038.html
