随笔分类 - 阅读笔记
摘要：有意义的命名 1.一旦发现有更好的名称，就换掉旧的 2.名副其实 如果名称需要注释来补充，就不是名副其实 3.避免误导 做有意义的区分 使用读得出来的名称 使用可搜索的名称 如：MAX_CLASSES_PRE_STUDENT 4.类名 类名和对象名应该是名词或名词短语，如Customer WikiP
阅读全文
摘要：整洁的代码 1.习艺之要 1).知：习得有关原则、模式和实践的知识，穷尽应知之事，并且要对其了如指掌 2).行：通过刻苦实践掌握它 2.阅读本书原因 1）。你是个程序员 2）。你想成为更好的程序员 3.勒布朗法则： 稍后等于永不 4.花时间保持代码整洁不但有关效率，还有关生存 5.程序员遵从不了解混
阅读全文
摘要：错误处理 抽离Try/Catch代码块 函数应该只做一件事，错误处理就是一件事。 // bad public void delete(Page page) { try{ deletePage(page); registery.deleteReference(page.name); configKey
阅读全文
摘要：分隔指令与询问 函数要行做什么事( 例如 user.setName('xxx') )、要么回答什么事( 例如 user.isVip() )。一个函数里不要把两件事都干了。 如何写出好函数 分解函数 修改名称 消除重复 注释 好的注释 法律信息 警示性注释 TODO 注释虽好，但也要定期查看，删除不再
阅读全文
摘要：动词与关键字 给函数取个好名字，能较好地解释函数的意图，以及参数的顺序和意图。 对于一元函数，函数和参数应当形成一种非常良好的动词/名词形式。 // good write(name) // better // 更具体，它告诉我们，"name"是一个"field" writeField(name) 函
阅读全文
摘要：做有意义的区分 如果同一作用范围内两样不同的东西不能重名，那其意思也应该不同才对。那么这两样东西应该取不同的名字而不是以数字区分。如果以下代码参数名改为 source 和 destination，这个函数就会像样许多 public static void copyChars(char a1[], c
阅读全文
摘要：第十章介绍类的设计，最重要的还是SRP（单一职责原则）。 第十一章是关于系统设计的内容，开篇引用了微软首席技术官Ray Ozzie的一句话："Complexity kills. It sucks the life out of developers, it makes products diffic
阅读全文
摘要：第四章讲的是注释，有一句话我很喜欢，说的是："Comments Do Not Make Up for Bad Code."（注释不是对劣质代码的补救）。事实上好的代码即便没有注释也拥有良好的可读性，但恰当的注释会让代码变得更可读、可维护性更高。 第五章讲的是代码风格。现代IDE（集成开发环境）几乎都
阅读全文
摘要：最初我喜欢这本书可能是因为非技术方面的原因，这本书中有很多我喜欢的插图。这本书的第一章的第一句话是这样说的：读这本书通常有两个原因：1. 你是一名程序员。2. 你想成为更好的程序员。我们需要更好的程序员。 这本书的每一章都可以总结出一句话，其实每章开始的插图就是这句话的浓缩。 本书的第一章是关于什么
阅读全文
摘要：《人月神话》是对失败的软件项目的复盘和反思，但所有的这些反思，并没有能从根本上提高软件项目的成功率。更多的项目之所以没有被宣布为失败，很大一部分程度上是因为项目的实施者（或者用户）接受了充满缺陷的成品、同意追加了成本或者延长项目交付时间，软件工程中的时间黑洞永远让人无法看清其本质，在《梦断代码》中，
阅读全文
摘要：作为一个PM，其任务是： （1）带领团队形成团队的目的/远景，把抽象的目标转化为可执行的、具体的、优美的设计； （2）管理软件的具体功能的生命周期； （3）创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍； （4）代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。
阅读全文
摘要：对于单元测试，回归测试，效能分析和通过PSP讲解个人软件开发流程。在《构建之法》，上有一句话“哎，你看我一通加班，就写好了程序，得了高分。也不用啥软件设计的原则，事先也不用需求说明书，也不留什么文档，就搞定了！软件容易得很！“。这句话就是学生陷入了”我有银弹“得误区，虽然短期看来完成了作业，也得到了
阅读全文
摘要：之前很多老师问过我们：“什么是软件？”，我总是想到了软件=数据结构+算法，但是看了《构建之法》之后，我突然醒悟原来我之前的角度和看法都是有误的，正确的思路是程序就是数据结构+算法、软件即程序+软件工程、软件企业即软件+商业模式。程序包括算法、数据结构是基本功，但是在算法和数据结构之上，软件工程决定了
阅读全文
摘要：但即使对结局有了一定程度的预判，也并不影响本书阅读的趣味性和实用性。项目中的每个人基本上都是全力以赴投入到Chandler项目中去的，并且其中大部分人都才华横溢，这样一个团队却未能打造出成功的产品，在相当程度上都是有很大的启发性的。软件工程可能是少有的几种用心也不一定会做好的工作，其本质与软件的脆弱
阅读全文
摘要：我认为，关于软件工程失败的经典之作，非《人月神话》莫属，这本书将IBM360系统失败的故事上升到理论高度，总结出一系列关于软件工程复杂性的规律，就IBM而言当然是一种不幸，但对作者布鲁克斯来说可谓失之东隅收之桑榆，《人月神话》对软件工程行业的影响之巨大，不是某一个软件系统可以比拟的。 为啥起了这么个
阅读全文
