《程序员修炼之道--从小工到专家》阅读笔记02

《程序员修炼之道--从小工到专家》在第三章中为我们提到纯文本的好好处,书中给我们提醒到,通过纯文本(XML、SGML以及HTML都是纯文本的好例子)我们可以让事情变得更容易。文本对于我们来说有三大好处:保证不过是、杠杆作用、更易于测试。对于程序员,不仅要善于使用纯文本,还必须掌握shell命令行,即使在Windows下我们也要精准掌握。Shell对于我们来说就是我们的工作台,在shell命令下我们可以操作调用我们想要的东西。可以说shell功能是非常强大的,所以对于我们程序员来说掌握它是对我们的提高。对于编辑器,我们要选择一个足够好的适合自己的编辑器。让它成为你双手的延伸。源码控制也是,使用好的适合自己的源码控制工具也是一个程序员的必备素养。代码生成器同样如此。在我看来,一个好的程序员,是通过不断的调试并且不断找到bug并且修复bug来达到的。或许有的人不喜欢调试,总是天真的幻想着一次性的代码就可以正确无误,即使有一点错误,也不想自己来调试解决,或许别人可以帮忙。我想,经验丰富的程序员是通过不断调试来达到成就的。

第四章注重失效的偏执。按合约设计,如果调用者满足了工程的所有前提条件,工程应该保证在完成的时候,所有的东西都应该是对的。在我们的编程的时候,我们的程序是不会说谎的。代码总是忠实的执行程序员的指令。一切程序员的错误最终将反映到代码上面来,在代码中随时做好踹别人屁股,甚至踹自己屁股的准备,因为崩溃比继续错误的运行更有好处。作者还给我们讲到了分配资源的额问题,分配某项资源的对象应该负责接触该资源的分配,以相同的次序分配,以相反的次序解除。

第五章中得墨忒耳法则:某个对象的任何方法都应该只调用属于一下情形的方法——它自身,传入该方法的任何参数,它创建任何对象,任何直接持有的组件对象。在我们的平常所做的东西中,很多的东西都是要以配置文件的形式来处理的,这样的好处是很明显的,修改这部分的时候不需要重新编译代码。所以,一个清晰易懂的配置对我们编程是非常有帮助的。

时间: 2024-10-25 16:06:14

《程序员修炼之道--从小工到专家》阅读笔记02的相关文章

《构建之法》阅读笔记02

<架构之美>阅读笔记02 今天,我读了<架构之美>第三.四章,第三章主要讲伸缩性架构设计,书中说设计系统架构时,要确保系统在伸缩时的弹性,根据书中的介绍我对系统伸缩性的理解是每个网站在不同时期都会有不同的访问量,有时会很多,有时会较少,当较多的人访问你的系统时,你可能需要数量较多的设备来满足用户与系统的交互,但当访问的用户越来越少时,系统伸缩性如果不够好,很多设备就会被浪费,不能够与系统分离,这对于软件开发者是不可取的.Darkstar项目就是由Sun公司实验室承担的一个将在架构的

《用户故事与敏捷开发》阅读笔记02

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

ijkplayer阅读笔记02

ijkplayer阅读笔记02 1.在这一章主要介绍音视频解码和显示线程的创建和启动,直接贴代码如下: IjkMediaPlayer_prepareAsync{ ijkmp_prepare_async_l{ ijkmp_change_state_l(mp, MP_STATE_ASYNC_PREPARING); msg_queue_start(&mp->ffplayer->msg_queue); SDL_CreateThreadEx(&mp->_msg_thread, mp

《需求分析与系统设计》阅读笔记02

在对于<需求分析与系统设计>第一章的阅读中我知道一个项目的成型的大致流程,一个软件的生命周期以及在不同的阶段我们应该采用什么样的方法.在不同的生命周期阶段当中我们应该做些什么,应该注意什么.对于一个软件的开发的方法. 对于第二.三章的精读之后了解到学习对象技术的主要困难在于缺乏明确的出发点和清晰的研究途径.没有像我们曾经了解的自顶向下或自底向上的一种学习方法.学习面向对象技术是一种“从中间出发”的方法.对于一个对象,我们首先要先确认实例对象,并且区分实例对象和类对象.那么关于对象呢,我们需要掌

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之一

<<需求分析与系统设计>>这本书论述了软件分析和设计的迭代增量式过程,讨论软件分析与设计的原理,方法和技术,并特别关注了设计阶段,对软件体系结构的内容进行了很大的扩充.本书强调对象技术与统一建模语言UML在企业信息系统开发中的应用,并讨论了使用web技术和数据库技术进行开发的方法.这本书集中在面向对象软件开发上,统一建模语言用于捕捉建模的人工制品,主要论述用逐步细化的方式进行开发,并且在整个开发生命周期中都是用UML这种建模语言.系统分析师,设计师和程序员使用同一种语言和工具,但有

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之三

终于把<需求分析与系统设计>读完了,感受很多,虽然理解还不是透彻,但还是学到了不少知识.在软件需求规格说明中,需要用图形和其他形式化模型来说明需求,为了完整地说明一个系统,有必要采取多种模型.UML提供了许多集成化的建模技术来辅助系统分析师来完成这项工作.规格说明的过程是迭代增量式的.对成功的建模来说,使用case工具是必须的.需求规格说明产生三种模型:状态模型,行为模型,状态变化模型.需求规格说明涉及需求确定期定义的客户需求进行严格的建模,重点放在那些系统将要提供的所期望的服务上.在规格说明

《UML大战需求分析》阅读笔记02

软件应能真正的对客户的工作提供帮助,只有客户使用并真正对其有用才能说我们做的软件成功了.客户从开始提出需求时到后期的工作过程中,需求总是不停变化的,所以这就需要需求人员对需求领先于客户.所以活用UML进行结构和行为建模,帮助我们更好的认识客户业务和做好业务流程再造工作.UML进行需求分析的过程: 搞清楚系统的目标和范围 找出该系统的所有关键涉众列出他们要解决的问题 分析业务,确认问题,发掘真正问题 针对问题,提出系统的特性 针对特性,提出系统的用例细化功能需求非功能需求 类图是用的最多的UML图

代码大全阅读笔记02

继续阅读代码大全这本书,感觉是好厚好难啃啊.刚刚开始读不久到了作者说把主要精力集中于构建活动,可以大大提高程序员的生产率.我想就一个项目来说,思路和设计是站着主导的地位的,你如果不能把思路理清,可能随时都有可能卡在那里,而一旦灵感来了,你就会想泉涌一样的来思路,我们也算是做了一个小的项目的了,虽然很low吧,但是好歹也算有点体会.我们总是在设计的时候会走投无路,不知所措,以至于每一次开始时都是没有思路起手都只能积压在那里,实在是不知道该怎么做.我觉得 P28 的那个食物链的例子更有说服力,健康的

人月神话阅读笔记02

贵族专制.民主政治和系统设计 本章主要是围绕着: 1.如何得到概念的完整性. 2.这样的观点是否要有一位杰出的精英,或者说是结构设计师的贵族专制,和一群创造性天分和构思被压制的平民编实现人员? 3.如何避免结构设计师产出无法实现.或者是代价高昂的技术规格说明,使大家陷入困境? 4.如何才能实现与实现人员就技术说明的琐碎细节充分沟通,以确保设计整备正确的理解并精确的整合到产品中? 就第一个问题文章是介绍的编程系统的目的是使计算机更加容易使用.对于功能,能够用最简洁的方式来指明事情的系统是最好的,对