随笔分类 - 阅读笔记
摘要：第四章讲述了为什么没有其他工具和技巧辅助的直接提问对于正确地获得需求是永远不够的 书中也给了回答：你需要其他的工具和技术来辅助直接提问,因为为了获得成功,完全直接提问的方法将需要一个完美的人。 那么在探索需求中我们应该如何直接提问？ 利用决策树模型。决策树模型本身是一个用于辅助直接提问的显著的工具。
阅读全文
摘要：第三章讲述了含混性的来源 把回答列表并在一个柱状图中显示其分布的最重要的原因并不在于柱状图本身，而是其后的能找出含混性出现的来源的讨论。解释错误倾向于产生分立的聚类，而观察和回忆错误倾向于在每一个聚类内部的变化中展示自己。 在实际探索需求时应该怎么做？ 1 对参与者需求文档某些部分的解释进行提问,并
阅读全文
摘要：第二章主要讲了需求陈述中的含混性，我认为，这是指在描述需求中没有提到或是没有指明某些要求，导致程序员按照自己的理解或是无意中的想法完成需求，然而很有可能并不符合客户的要求，这就造成了成本的浪费。 我们要做的是攻击含混性以便降低成本： 在后面的内容，我会了解到如何攻击含混性。
阅读全文
摘要：由于本学期上了软件需求与分析，所以我选择读这本书。 通过阅读第一章，我学到一个新的名词：映射图。 人们探索制作映射图，最终得到一张足够接近于实际形态的映射图，并为了一个“现实的”目的把它表达出来。同时，在面对不同客户时，我们要将自己的符号系统很好地解释给用户。映射更像是为了进行清晰交流的一些注意或委
阅读全文
摘要：看完这本书最大的收获就是知道一名合格的软件工程师是怎么样的，要怎么做才能进步。书可以读很多次，每一次都会有不同的感受，对事物都会有不同的认识。我想这可能就是成长的一种表现吧，随着成长我们队许多事情就会用不同的角度思考。对于“构建之法”，我也是这样认为的，现在我只是很粗浅的认识了软件工程，谈不上任何实
阅读全文
摘要：“团结就是力量”，善于运用团队，发现无限潜能。前几周老师提出结对作业的时候，我觉得只是这么一个小小的程序，没有结对的必要性吧。可越到后来越发现结对的好处，队友可以找到网盘想不到的问题。尤其是看完书后觉得，结对不是单纯的从一个人变成2个人写。而是从一个角色变成另外一个角色，就像是领航员与驾驶员，在不同
阅读全文
摘要：今天看完了第一章，恍然大悟，原来这就是软件工程啊。看完定义才知道，软件工程是“把系统化、规范化、可度量的途径应用于软件开发、运行和维护过程”。软件可以成为商品，但又不同于别的商品，它是一个逻辑产品，具有抽象性和易复制性，由程序和软件工程组成。软件也会像楼房一样慢慢出现裂痕，这时候就需要维护保证其可用
阅读全文
摘要：今天我读到了软件开发中沟通的重要性，我很庆幸我在团队合作前读完了这本书，这对我之后的团队合作带来不少帮助。 作者提到： 软件开发过程中必要的沟通手段； [ 软件开发中最大的风险往往不是技术的缺陷，而是缺少沟通；] 在软件开发的过程中，只有适度改进，没有包治百病的银弹。[在软件开发的过程中，重要的不是
阅读全文
摘要：今天阅读的这部分，作者提到了概念一致性。 如何得到概念的完整性？ 这样的观点是否要有一位杰出的精英，或者说是结构设计师的贵族专制，和一群创造性天分和构思被压制的平民编程实现人员？ 如何避免结构设计师产出无法实现、或者是代价高昂的技术规格说明，使大家陷入困境？ 如何才能与实现人员就技术说明的琐碎细节充
阅读全文
摘要：开发团队的组建： 作者提出了一种外科手术的方式去组件团队 外科医生。Mills 称之为 首席程序员 。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。他使用例如 PL/I 的结构化编程语言，拥有对计算机系统的访问能力；该计算机系统不仅仅能进行测试，还存储程序的各种版本，以
阅读全文
摘要：读完了这本书，收获到了一些开发中真实存在的故事，但要说具体的收获还是感悟不出来或者说用话语表达不出来，只能发出啊啊啊的感叹，后面再有一些经验再来读吧。总体来说，这真是一本超级好的书！
阅读全文
摘要：这本书我认为我看到了高潮的部分，好看，这本书我居然能看懂！ 我意识到备份很重要，作者就是因为这个差点白费了辛苦。以后做了程序员更得备份。 摘抄书中一段话，是对做大型开源项目的建议：别做大项目，从小项目开始，而且永远不要期望他变大。如果这么想，就会做过度设计，把它想象的过于重要。更坏的情况是，你可能会
阅读全文
摘要：初读了这本书，感觉比较好读，翻译得也挺好。 在书中有一段这么说“软件并不只是用来发电子邮件或写报告的程序那么简单，它已经不声不响地渗透到生活的每个角落”。感觉先人就是先人，这么早已经洞悉一切。 书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。随着人数的增加，依赖关系的复
阅读全文
摘要：1.在编写代码遇到问题时，要及时的修正问题，而不是发出职责和无关的抱怨。初次之外，还应该有一个意识，bug无论是团队中谁的过错，并不是很重要，他仍需要我的解决，以及团队的合作。 2.调试的思维方式： 首先是不应该对惶恐。 遇见bug的第一反应是“那不可能”，不要把情感浪费在这上面，它不仅可能，而且已
阅读全文
摘要：1. DRY原则：dont repeat yourself,含义是系统中的每一项知识都必须具有单一，无歧义，权威的表示。即要避免重复。 程序员需要持续不断的维护，这是整个开发过程中的例行事务。 2. 重复的类型： 强加的重复,指环境因素导致的重复.解决需要智慧。 信息的多种表示（如不同平台不同语言对
阅读全文
摘要：1. 如果我确实同意要为某个结果负责，就应切实负起责任，当出现失误时，诚实地承认它，并给出选择。 2. 预先制定应急计划，源码必须备份。 3. 出现问题不要向老板说借口，而是挽回的方式。 4. 不仅要留心大图景，还要持续不断地观察周围发生的事情。 5. 让用户参与决定所制作的东西何时是足够好。 6.
阅读全文
摘要：1.作者通过“愚公移山”告诉了我团队是如何实现工程的：产生需求、团队沟通、研讨，团队中拥有三名技术人员和一名工程管理人员。之前在做易班轻应用时，我组建了一个小组一起做，问过学长后，对团队合作有了浅显的认识：先弄清楚要做什么，把需求搞清楚，否则匆匆的开始越到后面越难；多开几次会，做工作量评估，学会分工
阅读全文
浙公网安备 33010602011771号