首页 > 其他分享 ><<梦断代码>>读后感(一)

<<梦断代码>>读后感(一)

时间:2023-04-14 21:59:45浏览次数:30  
标签:读后感 Python 代码 程序员 开源 软件

今天发表《梦断代码》的第一篇读后感。这几天读了《梦断代码》的前四章,有很多不懂的也是必然的,读了很多遍还有好多地方不是很懂。发一下读的内容。

      作者迷恋于一个叫做Sumer的游戏,其可以让玩家打补丁,任何人都能窥探其内部运行机制。花点时间学习简单的Basic语言,改游戏就和玩游戏一样简单:将纸带上的指令装在到计算机,然后开始往程序里加代码。如果代码写得顺利,会全然忘记时间,如果不顺利那便会陷入困境,四顾茫然/举步维艰。但无论是那种情况,时钟都被抛诸脑后。在使用任何一门新编程语言时,程序员总是将“Hello World”作为第一行代码来召唤计算机。它鼓励新手,唤起每个程序员心中乐观的一面。这是关于第0章的主要内容。

     第一章:死定了。在特定的时间里完不成任务可能是每个人都经历过的。建造任何项目之前,现有蓝图。坚决不放过任何问题。发现问题,一步一步的慢慢解决。开源倡导者们喜欢强调free之间的区别:并非所有开源软件产品都免费,但所有的开源软件都可被自由查看、摘选和复用。媒体普遍将开源描写为微软的挑战者,但挑战是非直接的,商业软件为赚取利润而生产。要与微软抗衡,唯有改编游戏目的。开源不仅给出了一种生产和分发软件的替代性经济基础方案,还能彻底改变软件开发的具体过程。

      第二章:Agenda之魂。莲花公司于1988年发布了Agenda软件,这是个简单的列表管理软件,但有几个突出特征让他跻身于软件传奇之列。可以用它来管理日常生活也可以用它来组织学术研究、音乐收藏或是工作项目,需要管理大量细节信息的地方都用得上。Agenda突破了计算机的严格逻辑与人类的语焉不详之间的阻碍。刚开始接受Linux及类似系统时,反对开源的呼声不绝于耳。批评者认为,代码不属于某家公司,就不会得到技术支持。如果程序员太过在意过往那些软件灾难留下的教训,就一行代码也写不下去。每次失败都如此相似,简直令人遍体生寒。

      第三章:原型与Python。把生活中的某些方面融入到软件代码中,就很容易被各种新奇诱惑人的可能性所迷惑,看不到自己放弃了什么。设计良好的程序在提供大多数新特性的同时,并不试图对抗进化过程留给我们的物理世界倾向。Python和其他解释型语言一样,为许多软件开发者所轻视,他们把解释型语言看作“脚本语言”只用来临时拼造短程序脚本,编点快速工具代码,不适用于较为严肃的项目。但这种假设很快被人挑战。完成同样的任务,Python代码以要比c或c++代码少上3、5甚至100倍。不仅代表程序员可以少敲与多次键盘,还意味着当程序员回头添加新特征或修正缺陷时,更容易理解某段代码的功用。在另几个主要方面,Python比其他一些前辈脚本语言更符合业界标准的编程语言。Python开源而且跨平台,同一个Python程序可以在Windows、Macintosh和Linux操作系统上运行。

     我之前总是老师给一个题目,有点思路就开始上手敲代码。总是敲了一点就察觉思路是有问题的,可是这样停了重新来过就感觉太可惜了,不重新来还进行不下去。这是我犯得很多的一个问题。《梦断代码》教给我在上手,或开始之前,脑子里一定要有个进行的蓝图。不是特别清楚就记下来,一定得时时刻刻保持自己对设计很清楚,不能有一点模糊。我吸取教训下次着手敲得时候一定要先在本上写下大概的思路。

标签:读后感,Python,代码,程序员,开源,软件
From: https://www.cnblogs.com/psh888/p/17320039.html

相关文章

  • 敏捷测试高效实战-测试架构师成长记的读后感
    序测试工作的最终目标是服务于产品的商业价值;产品质量必须是由测试人员和开发人员共同负责的;测试团队不仅要提升自身的效率,也要提升整个研发团队的交付效率;正如《Google软件测试之道》一书中提到的,测试团队属于工程生产力团队,以产品交付和效率提升为己任;自动化测试平台建立了......
  • 《软件方法》读后感
    前言近日,苦于不知道该怎么提升自己了,在原来老大的建议下,决定去学习一些关于建模和软件设计领域的书籍,来解决解决自己“感觉不对,但是说不清楚为什么不对”以及“感觉这么搞就对了,但是不知道为什么这么去规划,这么去划分就对”第一本看的是潘加宇老师的《软件方法(上)业务建模和需求......
  • 《人月神话》读后感——第三篇
    ——众所周知,一名孕妇需要36-42周才能够产下胎儿,那么如果有10名孕妇,产下胎儿的时间可以缩短到一个月以内。如果您真的着急,希望在2周之内要个孩子,那么我们只能够再添加一倍的人手。——写在最前。一般来说,本人读书之后,都会在一两个星期之内总结并且完成读书笔记,不过《人月神话》是......
  • 《人月神话》读后感
    人月这个词组是一个考察工作量的度量单位,一个人月也就是一个人在一个月能够完成的工作量。在软件工程里,经常用多少个人月来估算项目的工作量。作者用了一个孕妇生孩子的案例说明了人月这个单位混淆了工作量和进度这两个概念。一个孕妇生一个孩子需要10个月,那么为了加快生孩子的过......
  • 《人月神话》读后感1
    人月神话的含义:人是程序员,月是时间,,如果1人干10个月如果等同10人干1个月,那就成神话。这涉及到工作量与进度,比如:20个人10个月的工作量是10个人干10个月的工作量的2倍,但是这个工作量并不代表20个人的进度就比10个人的进度快,因为中间有些因素要考虑,比如20个人去完成一个项目,那么20......
  • 《人月神话》读后感2
    作为一本二十多年前出,讲三十年前软件专案管理问题与经验的书,直到今天依旧出现在我们面前,必然有其重要意义。作为一名大学生,没有什么工作经验,仅能从书中获得些许感悟,也许不久的将来我会亲身经历。初看书名,以为是一本神话体系小说,还有点诧异老师为什么推荐我们阅读,直到翻阅本书,才......
  • 《人月神话》读后感3
    今日阅读了人月神话中,20年后的人与神话部分,其中提出了人月神话的核心观点:概念完整性和结构师。概念完整性。一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型,这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略,。用户所......
  • 人月神话读后感
    《人月神话》是由著名计算机科学家弗雷德里克·布鲁克斯所著的一本著名著作。这本书以其深刻的见解和对软件开发的深入理解而闻名于世。这本书的主旨是软件开发中的管理问题。布鲁克斯认为,软件开发是一项复杂的任务,需要认真的计划和协调,以确保项目能够按时完成,而且还需要确保开发......
  • 构建之法读后感 1
    软件开发,第一步要做的,便是需求分析,我们要知道做的是什么,有什么要求,不然当我们投资了许多人力、物力,到最后做出来后却没人要,白白浪费时间。所以我们事先向用户了解需求,通过焦点小组、深入面谈、卡片分类等方法调查,对功能进行定位。然后通过初始阶段了解软件系统的大概构成,系统的风......
  • 《人月神话》读后感(三)
    第十二章是干将莫邪。主要讲的是工具很重要,需要专门人员开发。“仿真装置”很重要。不确定性是所有情况中最糟的,因为它剥夺了程序员寻找BUG的能力。第十三章是整体部分。主要讲的是系统各个组成部分的开发者都会做出一些假设,而这些假设之间的不匹配是大多数致命和难以察觉的BUG的......