码迷,mamicode.com
首页 > 其他好文 > 详细

阅读笔记

时间:2015-06-23 17:37:38      阅读:118      评论:0      收藏:0      [点我收藏+]

标签:

人月神话阅读笔记之一

                                                          2015-3-30

     最大的感触就是,软件工程就是一个焦油坑,不断挣扎,有些人沉溺在里面,有些人走出来了。

    细想想,现状就是这样,虽然现在我接触的编程任务很少,但是真的感受得到编程是一种痛并快乐的过程,不是半路放弃就是坚持到底。对于我自己而言,说比什么都容易,慢慢的积累才是正道。

人月神话阅读笔记之二 

                                                            2015-4-5

书中写道:软件的快乐源自于创造新事物的纯粹的快乐;源自于能创造对人们有意义的东西;工具十分简单,最后可以看到各个组件紧密的咬合在一起;

软件的痛苦在于:寻找bug,这是一个重复而又枯燥的过程;目标是由别人确定的,自己只能根据别人的要求工作。

真心的,就是这样,但是现在我能做的就是体验其中的乐趣,在达到别人要求的前提下,做到最好,比如程序的复杂度,再如涉及到界面设计的,要做到最好。

 人月神话读书笔记之三

                                                              2015-4-9

      在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….

通过阅读《人月神话》,我从中学到了一些东西:

首先,开发一个项目,我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同,有着很大的变化,进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之间不需要相互的交流,而在系统编程中近乎不可能。当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助。调试、测试的次序特性,许多软件都具有这种特征。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手,实际上是延长了,而不是缩短了时间进度。

对于编程,有其乐趣和苦恼。创建事物的快乐 ,开发对其他人有用的东西的乐趣 ,将可以活动、相互啮合的零部件组装成类似迷宫的东西,这个过程所体现出令人神魂颠倒的魅力 ,面对不重复的任务,不间断学习的乐趣 ,工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动,其存在、移动和运转方式完全不同于实际物体。将做事方式调整到追求完美,是学习编程的最困难部分;由其他人来设定目标,并且必须依靠自己无法控制的事物(特别是程序);权威不等同于责任实际情况看起来要比这一点好一些;真正的权威来自于每次任务的完成任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外 人们通常期望项目在接近结束时,(bug、工作时间)能收敛得快一些,然而软件项目的情况却是越接近完成,收敛得越慢产品在即将完成时总面临着陈旧过时的威胁。

开发一个软件,我们要有合理的时间进度,开发人员要少而精,概念完整性必须考虑在内,要尽量做到尽早交流和持续沟通。

同时,文档形成了关键的枢纽,每个项目管理的工作都围绕着它们运转,它们是经理们的主要个人工具。对于计算机硬件开发项目,关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格;对于大学科系,关键文档类似:目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配;对于软件项目,要求是相同的:目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目,我们都会要求书写相关文档,对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。

良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明,是一个非常必要的工具,尽管光有文档是不够的。手册是产品的外部规格说明,它描述和规

定了用户所见的每一个细节;同样的,它也是结构师主要的工作产物。

形式化定义是精确的,它们倾向于更加完整;差异得更加明显,可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则,描述阶段上或层次上的结构,以及提供例子。它可以很容易地表达异常和强调对比的关系,最重要的是,它可以解释原因。在表达的精确和简明性上, 目前所提出的形式化定义, 具有了令人惊异的效果, 增强了我们进行准确表达的信心。

通常,开发一个软件我们还会设立规模目标,控制规模,发明一些减少规模的方法——就如同硬件开发人员为减少元器件所做的一样。规模预算必须与分配的功能相关联; 在指明模块大小的同时,确切定义模块的功能。培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。

调试,是一种检验程序中的方法。然而调试是系统编程中很慢和较困难的部分,而漫长的调试周转时间是调试的祸根。它可以持续一个很长的时间,从而可能影响项目的交付日期。

为了更好的控制进度,我们需要制定一个严格的进度表来控制项目的进度表,进度表由里程碑和日期组成。里程碑必须是具体的、特定的、可度量的事件,能进行清晰能定义。进度表有时可以根据进展情况进行适度的修改。

产品测试时每个产品在提交给用户的一道程序。而这项工作主要由产品测试机构/小组根据规格说明检查机器和程序,充当麻烦的代言人,查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门,来保证其公正性。产品-测试小组则是顾客的代理人,专门寻找缺陷。不时地,细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面的原因,设立测试小组是使设计决策得以贯彻执行的必要手段,同样也是需要尽早着手,与设计同时实施的重要环节。

一个已开发的项目,我们需要对它进行后期维护。其维护基本上不同于硬件的维护, 它主要由各种变更组成, 如修复设计缺陷、新增功能、或者是使用环境或者配置变换引起的调整而且维护总成本通常是开发成本的40%或更多。维护成本受用户数目的严重影响,用户越多,所发现的错误也越多。在每次修复之后,必须重新运行先前所有的测试用例,从而确保系统不会以更隐蔽的方式被破坏。其实,对于一个项目,我们要尽量做到完美,减少以后的维护困难和成本。

在计算机技术进步的同时,计算机相关学科知识也在飞速发展。兴趣太多,令人兴奋的学习、研究和思考的机会也太多——多么不可思议的矛盾啊!这个神奇的时代远远没有结束,它依然在飞速发展。更多的乐趣,尽在将来。

程序员修炼之道阅读笔记之一

                                                            2015-4-26

     在《程序员修炼之道》一书中,Dave和Andy告诉我们以一种我们能够遵循的方式编程。本书中提出了许多著名的哲学理论,总结如下:

     遵循"破窗户理论"。做软件也一样,如果出现问题而不及时修正,那么整个软件就会随之恶化。即使bug不能被修复,也要及时标注。

    提供多种选择,不找借口:出现了各种各样的问题之后,应该提出各种解决方案的选择,而不是找借口。不要说事情做不到,要做什么来挽回局面。

知道何时止步:代码不可能完美,不要做一个完美主义者,这不适合程序员。    

无处不在的自动化:自动化能够避免重复劳动提高效率,保持可靠的一致性与可重复性,排除人工操作可能产生的错误可以自动化的项目包括但不限于:项目编译,回归测试,构建与发布,通过单一数据源生成数据的其他表示。

程序员修炼之道读书笔记之二

                                                             2015-4-29

      投资知识财产我们喜欢把程序员所知道的关于计算机技术和经验视为他们的知识资产,你的资产是有时效的资产,会随着新技术,语言和环境的出现而变得过时。

   多交流且会交流:听别人说话时,要把自己当成傻子,给别人将东西时,要把别人当作”傻子“,一定要讲清楚自己所要表达的意思。

   维持正交性:正交就是两个事物中一个发生变化,对另一个无影响,这就是所谓的正交性。正交的好处有两个,一个是提高生存率,另一个则是降低风险。让代码维持正交性,可以消除无关事物之间的影响。

   无处不在的自动化:多使用python,shell等脚本语言,将工作的重复性任务自动化实现。对于编程中的重复代码,通过脚本自动生成代码。在工作中多总结,提炼小系统,让流程和代码都自动化。

   新方法和新工具:有个新工具或新方法在项目组中推广,但不要低估采用新工具和新方法的代价,可能你的项目需要花上太多精力来熟悉这个方法,而第一个采用这方法的项目,可能就只能是实验品。批判的看待方法学,从中提炼适用团队的精华。

 

 程序员修炼之道读书笔记之三

                                                                  2015-4-30

     读完了,印象深刻的一点就是“解耦合(decoupling)”    一下几点是作者十分强调的:    1. DRY - Don‘t repeat yourself.    2. Decoupling. 解耦合    3. Be responsible. 对自己的工作负责,对代码负责    4. Be good at tools. 善用工具    5. Don‘t program by coincidence. 不要用巧合编程,不要臆断某些逻辑

大道至简读书笔记之一

                                                              2015-6-10

      在复杂的工程也是由一些基本元素构成,无非是顺序,分支,循环,所以只要把复杂庞大的工程,

分解,“一切从简”,也是可以完成的。

  事情分析清楚,事件的先后逻辑关系和依赖关系搞清楚,然后再去代码实现。

  积极工作和勤于思考都要占时间。要给自己留下思考的时间。要经常整理自己学过的东西,条理清晰,方便使用。

大道至简读书笔记之二

                                                              2015-6-10

      管理员,要了解团队的进度,但是不能参与进去,先了解发现规律,在尝试改变其中的一些负面规律。开发人员与客户之间要有沟通,要了解客户的需求,不能只懂得代码,机器语言;也要知道,如果自己不懂程序,该怎么做。换位思考一下。

  做工程的时候不光要做好注释,。同时也要做好历史记录,当自己不在的时候,为自己或者后来维护的人留下方便。做程序,既然做就是为了实现,要努力去做,即使最后无法完成。但是也要在过程中

学习到东西。为下次总结经验,有所进步。

大道至简读书笔记之三

                                                              2015-6-10

    作者讲的都是经验之谈,把自己十年的经验总结了下来,都是实实在在的感想。这本书的确很薄,很快就读完了。这本书没有将什么编程技术,讲的是一种境界。招数是有限的,在武侠小说里,最高境界是无招胜有招。我们要了解本质的东西,才能在招数不灵的时候可以知道从哪里解决。

 

阅读笔记

标签:

原文地址:http://www.cnblogs.com/revenge/p/4595769.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!