随笔分类 - 阅读笔记
摘要：本次阅读了第十五章 稳定和发布阶段、十六章 IT 行业的创新 第十五章戳到了我们的痛点，我们的软件在设计时有时就构想的太全面，想在第一次发布的时候就搞全面，起始不大现实，在进行的过程中出现了越来越多的问题，不只是程序上的，还有团队的沟通交流方面的；维护和运营由于是刚刚发布阶段，用户数量和反馈还不多，
阅读全文
摘要：第7章 细节视图 需求搞错的严重后果，18英尺的巨石拱门变成了18英寸的石桩子。想起老师上课讲的《构建之法》中修井修成烟囱的示例，不搞好需求分析基本就等于失败， 第8章 白板上的即时贴 非常敬佩写标准的人，你要用5年为计量标准的眼光看问题。得花上5年时间，才能得到你真正想要的有用之物。 用贴纸法来讨
阅读全文
摘要：到底是什么驱动程序员和管理人员，测试人员长年累月投入到一个软件项目中去？ 从网上看了一则小故事： 美国的一个肥皂剧Seinfield里有一集，讲了一个混混Kramer 热心地加入了一家公司，义务打工，起初他的口头幽默和热情感动了团队，领导委以重任，不料Kramer 根本没法儿把事情做好。最后领导只好
阅读全文
摘要：本次阅读了第十三 软件测试 十四章 质量保障 在软件发布前基本没有进行测试，直到上台讲述的之前的一段时间才发现了一些问题，甚是着急 第十三章中excel计算1900闰年错误的例子给了我一个全新的概念——要服务于最主要的功能. 传说中的拐点 小飞： 我听说在软件项目中，有这样一个拐点存在——在这一点之
阅读全文
摘要：本次阅读了第十一 软件设计与实现、十二章 用户体验 在做班级派团队项目时，缺少了与团队成员的沟通，导致作业模块的界面成为一大遗憾，而且功能的实现也有欠缺，进度的报告没有能及时有效的提交 没有太多的考虑到用户的体验，只想自己要实现的功能，可以说有些跑偏，但幸好不太多 如何避免在产品开发后期不断有重大修
阅读全文
摘要：本次阅读了《构建之法》的第九、十章 在具体做项目的时候才会意识到PM项目经理这个角色的不可或缺性，每次站立会议的时间、每次要完成的内容、需要修改的地方等等基本都需要这么一个角色来协调组内关系和安排组内任务并对组内成员任务完成进度予以评价 典型的用户场景如果不能设计得合适用户，那么自己设计的软件就不能
阅读全文
摘要：这次读了构建之法的七八章。 第七章主要介绍了MSF，微软解决方案框架，也就是微软推荐的软件开发方法。读完书中对MSF的九个基本原则的介绍后，我对团队软件开发有了更加深刻的认识。推动信息共享和沟通，我们必须保证所有的信息都公开，包括团队中每个人犯的错误，这样有助于我们对项目进度的准确把握以及减少同样错
阅读全文
摘要：原来： 在自己以前的程序中，基本没用到过函数，总是全部都堆到主函数里，因为心里有那么一丝惧怕参数的传递；变量的定义也是诸如i,j,k的无注释变量；注释量也几乎没有，往往回来看自己原来编写的程序时一团乱麻 结合书内容： 使用函数的原则是：只做一件事，并且要做好。这就可以将我们的程序分成各个小块的组合，
阅读全文
摘要：本学期计划阅读《构建之法》和《梦断代码》（或《人月神话》），因为假期阅读了《梦断代码》，感觉阅读了几章不是特别明白，计划看看《人月神话》再决定，初步计划每周阅读3~4章内容，大致1~2周发表一篇阅读笔记 略读《构建之法》后的几个小问题： 1.计算机科学作为相对较新的学科，包含了软件工程，是否也会转变
阅读全文
摘要：大致浏览目录，惊喜的发现本书是从第0章开始编写，完全符合程序员的编码习惯，共有11个章节，章节题目和内容也都不含繁琐并令人生畏的代码，可以当做一本小说来读。 第0章软件时间 从我们从未接触过的电传打印机的一款名叫summer的游戏入手，不免让我这种游戏狗产生兴趣，通过纸带来玩游戏并且修改游戏脑补起来
阅读全文
浙公网安备 33010602011771号