《程序员修炼之道》读书心得
因为看到“采石之人应胸怀大教堂”这句话,决定买这本书看看。
其实,开发软件的主要目的就是保持灵活性、稳定性,所以软件开发的主要原则就是解耦;
总体上说,一般般的一本书,不过,看完本书,还是有以下三点重要的收获。
- 需求文档与政策文档分开
- 解开解不开的谜(在盒子外思考)
- 创立品牌(标新立异的名字、标识)
要配置,不要集成
config、Property文件,例如.ini .xml文件
与通用的编程的情况相比,可以通过一种大为接近问题领域的方式表示元数据。
商业政策和规则更有可能发生变化,通过配置文件维护更为合理。
将抽象放进源代码,将细节放进元数据(配置文件)
需求描述
两个陈述“1、只有指定人员才能查看员工档案”和“2、只有员工上级和人事部门才可以查看员工的档案”的区别。
陈述2是真的是需求吗?今天也许是,但它在绝对的陈述中嵌入了商业政策。政策会经常改变,所以我们可能并不想把他们硬性地写入我们的需求。
我们的建议是,把这些政策文档与需求文档分开,并用超链接把两者链接起来。使需求成为一般描述,并把政策信息作为例子发给开发者----他们需要在实现中支持的事物类型的例子。最后,政策可以成为应用中的元数据。
通过陈述1,通过需求文档与政策文档的分离,开发人员就能实现访问控制系统,实现变与不变的分离!
你必须把底层不变项当做需求进行捕捉,并把具体的或当前的工作实践当做政策计入文档。
需求主要是要理解用户背后的目的,而不是用户的陈述!
用例:通过角色的视角,通过UML工具,描述用户做什么,怎么做。
需求文档通过Web进行管理,我们公司现在是通过Confluence进行管理,类似wiki的功能。
解开不可能解开的谜
在盒子外面思考,逆向思维
戈尔迪之结
立鸡蛋
三条线连接,回到起点:
。 。
。 。
有些约束是绝对的,有些则只是先入为主。绝对约束必须受到尊重,不管它们看上去有多讨厌或多愚蠢。另一方面,有些外表上的约束也许根本不是真正的约束。
在盒子外面思考,鼓励我们找出可能不适用的约束,并忽略他们。
解开谜题的关键是在于确定加给你的各种约束,并确定你确实拥有的自由度!因为在其中你讲找到你的解决方案。这也是有些谜题为何如此有效的原因;你可能会太快就排除了潜在的解决方案。
在面对棘手的问题时,列出所有在你面前的可能途径。不要排除任何东西,不管它听起来有多么无用或愚蠢。现在,逐一检查列表中的每一项,并解释为何不能采用某个特定的途径。你确定吗?你能否证明?
想一想特洛伊木马,一个棘手问题的新奇解法。按常规思维,走前门,一开始就作为自杀行为而被排除了。
对你的各种约束进行分类,并划定优先级。我们想先确定最为严格的约束,然后再在其中考虑其余的约束。
你所需要的只是真正的约束、令人误解的约束,还有区分他们的智慧。
挑战
- 用心想一想你今天遇到的无论什么难题。你能否解开这个戈尔迪之结?问你自己提出我们在上面列出的那些关键问题,特别是“它必须以这种方式完成吗?”
- 当你签约开发你现在的项目时,是否交给了你一组约束?他们是否仍然都适用?对他们的解释是否仍然有效?
交流
有一个简单的营销诀窍,能帮助团队作为整体与外界交流:创立品牌。当你启动项目时,给它取一个名字,最好是不同寻常的某种东西,花30分钟设计一个滑稽的标识,并把它用在你的备忘录和报告上。在与别人交谈时,大方地使用你的团队的名字。这听起来很傻,但它能给你的团队一个用于建设的身份标识,并给外界以某种难忘的、可以与你们的工作想关联的东西。
例如阿里的平头哥、达摩院以及每个人的花名。
了解你的听众
你需要了解你的听众的需要、兴趣、能力。
你要在脑海中形成一幅明确的关于你的听众的画面。
你需要清除听众的轻重缓急是什么?
重构
重构是一项需要慎重、深思熟虑、小心进行的活动
- 不要试图在重构的同时增加功能;
- 在开始重构之前,确保你拥有良好的测试。尽可能经常运行这些测试。这样,如果你的改动破坏了任何东西,你就能很快知道。(回归测试)
- 采取短小、深思熟虑的步骤。 (小步快跑,及时测试)
文章摘要
- 参加本地用户组织:不要只是去听讲,而是主动参与。与世隔绝对你的职业生涯来说可能是致命的;打听一下你们公司以外的人都在做什么。
- 读书有三上:马上、枕上、厕上
- 能不能让那个正确的原则知道正确的行动本身,其实就是区分是否是高手的一个显著标志;
- 认知科学认为,频繁的高强度的外部刺激和自主的有意识的反复提醒是加速内化的两个重要的方法。
- 理想的阅读状态应该是先大致理解和记住里面的Tip,然后每周争取实践2-3个Tip。
- 把问题放到更大的语境中,设法注意更大的图景。
留心大图景,要持续不断的观察周围发生的事情,而不只是你自己在做的事情。
- 在所有的弱点中,最大的弱点是就是害怕暴露弱点。
- 计算机语言会影响你思考问题的方式,以及你看待交流的方式。
采用领域语言的语汇、语法、语义,进行实际的编程。
- 要崩溃,不要破坏
java语言库已经采用了这一哲学。当意料之外的某件事情在runtime系统中发生抛出RuntimeException。如果没有被捕获,这个异常就会渗透到程序的顶部,致使其终止,并显示栈踪迹。
- DRY Don't Repeat Yourself
正交性
- 软件更像园艺,需要不断的修剪;
- 向导式开发,生成骨架代码 skeleton code
- 解决需求蔓延的方法最好通过敏捷开发的模式,通过迭代找到最重要的需求。
- 在你的作品上签名。
- 破窗户理论。
- MVC 视图是对模型的一种解释
代码和文档(代码中的注释),可以视为是同一模型的两种视图;