读《构建之法》第四章、第十七章

第四章《两人合作》

1.原文:“注释(包括所有源代码)应该只用ASCLL字符,不要使用中文和其他字符,否则会极大影响程序的可植性”

疑问:引擎根本不对空行和注释进行解析,直接忽略掉,它们不参与计算代码行数也不参与程序的执行,对程序执行效率也没有影响,中文和其他字符为什么会影响程序可执行?中文注释不是更容易看到和理解吗?

解决中的发现:python中为什么加上中文注释就会报错? 答:由于Python源代码也是一个文本文件,所以,当你的源代码中包含中文的时候,在保存源代码时,就需要务必指定保存为UTF-8编码。当Python解释器读取源代码时,为了让它按UTF-8编码读取,我们通常在文件开头写上这两行:

#!/usr/bin/env python   //为了告诉Linux系统,这个是python可执行程序
# _*_ coding:utf-8 _*_  //为了告诉python解释器,按照utf-8编码读取源代码,否则,你在源代码中写的中文输出可能会由乱码

解决中的发现:在MyEclipse中的程序中文注释经常会出现乱码,可以点击工程,然后查看属性:如图,修改工程的编码的encode,设置成utf-8就行了。

到这里虽然不知道中文为什么会影响,但是知道了的确有影响

第十七章 《人,绩效和职业道德》

1.原文:加入一个团队时,要弄清楚自己在团队中投入的级别是什么,别人的期望是什么。不要拿着卖白菜的钱,操着卖白粉的心——太不值得。人可以在n个地方做鸡,或者在n*m个地方做鹦鹉,但不可能在两个地方同时做猪,这太难了!

我的想法:在一个团队中把心安好,看清自己的位置是很重要的,但是一个团队需要和谐,有时候能帮助他人还是尽力,因为也许你也有需要别人的时候。就像踢足球一样,队员需要协防,但是在作怪过程中两个人不能抢到一块,还是要以主要责任人为标准。

2.刷客软件和刷票软件的争论抢票软件是走在

个人看法:仔细想想,任何抢票软件,任何“加速包”,其实并不能让更多的人坐上火车。抢票软件看似方便,但会扰乱正常的购票秩序,尤其是短时间内的巨大点击量,容易冲击12306网站的运行。“技术黄牛”客观上是破坏了公平交易的市场秩序,我认为目前抢票软件是走在法律的边缘。当然对于企业来说,既然没有罪刑法定就这么干,用技术抢占市场。现在医院实行网上挂号,有一种刷专家号的软件,这种行为十分恶劣,每天晚上提前输入信息并根据你交的钱在第二天早上为你抢挂号,不会使用手机的老年人真的很可怜,不能因为你有技术你就破坏市场公平吧。所以我不认同刷票软件,长久的企业需要有社会情怀,对于有些利益巨大的东西应该说不。

原文地址:https://www.cnblogs.com/wzylt/p/8683570.html

时间: 2024-08-29 23:08:45

读《构建之法》第四章、第十七章的相关文章

读构建之法第四、十七章有感(作业四)

第四章: 问题: 看到这里的时候,才注意到代码中的"下划线"这个东西,在之前的敲代码过程中并没有怎么遇到下划线,在经过百度后得到了一些答案: 这只是Python中下划线的一部分应用,在不同的语言中,下划线的用处也不太相同,而在原文中作者对下划线的解释很简单,对于"下划线用来分隔变量名字中的作用域标注和变量的语义"这句话也不太理解,我认为作者可以适当地放一些代码片段来说明下划线的用法,如果作者提及下划线的原因仅仅是因为命名的话,我觉得完全可以放在下划线的上一小节&qu

读构建之法第四章第十七章有感

第四章 1.原文:"函数最好有单一的出口,为了达到这个目的,可以使用goto.只要有助于程序逻辑的清晰体现,什么方法都可以使用.--P69" 问题:关于goto,我记得老师讲过,这个在编程中是尽力避免的,所以我在之前并没有了解过它.本书却建议用,这让我产生了困惑. 我的看法:goto语句它可以不受限制的灵活跳转,这样程序员在使用goto语句的时候就很容易因为跳转而略过了一些关键语句.但是它能从多重循环体中跳出,用不着写很多次的break语句.我查了一些资料,发现自从提倡结构化设计以来,

读构建之法8、9、10章有感

第八章.需求分析 书中介绍了一些获取需求的常用方法.流程.及分析框架,看了后才发现原来需求分析还有着者这么多的学问. 以前听人说,需求分析在实际项目开发中所占分量很重,甚至往往需要花的精力比敲代码要多.我听到时不以为然 ,认为需求分析不就是看一下软件要什么功能,要做成什么样而已吗.再后来,我真的接手了一个小商业项目的需 求分析任务,才明白需求分析是一件多么让人崩溃的事情,客户对软件编程一无所知,只是含糊地给我一些文档, 而我又不清楚他们的业内流程.业内术语等,不知道如何去获取对需求,只能像只无头

读构建之法 第四章:两人合作

程序员写的代码最终是人在看,所以代码规范很重要,原则是:简明,易读,无二义性. 不光是程序书写的格式问题,还牵涉到程序设计.模块之间的关系.设计模式等方方面面. 代码复审的正确定义看代码是否在代码规范的框架内正确的解决了问题 代码复审的目的在于: 1.找出代码的错误,比如: 1)编码错误,比如一些碰巧骗过了编译器的错误 2) 不符合团队代码规范的地方 2. 发现逻辑错误,程序可以编译通过,但是代码的逻辑是错的 3. 发现算法错误,比如使用的算法不够优化,边界条件没有处理好等 4. 发现潜在的错误

构建之法第四、第五章读后感

第四第五章着重讲了合作的重要性,从两人合作到团队合作,编程开发都不是一件容易的事情,要注意许多要点. 代码书写的规范. 你写的代码不仅仅是给机器看的,给你看的,也是给其他人看的,是给合作的队友看的,在写的过程中要注意规范,要注意缩进.行宽.对齐等格式. 代码设计的规范. 函数中,你就只实现函数的具体功能,如构造函数,简单初始化所有数据成员即可. 代码复审. 找出代码的编辑错误.逻辑错误.算法错误跟潜在错误. 合作需要讲究技巧,要运用合理的方式影响合作的对方,尽量运用逻辑加感情,使对方能快速地接受

构建之法第七,第十七章读书有感

第四章 两人合作 关于合作中算法的使用 在第四章的叙述中,我们看到了代码的编写规范,代码的命名规范,我们还知道要写注释,要有良好的代码设计和错误处理.而这些都是我们在使用语言进行编辑中的问题.我们要阅读结队队友的代码,了解功能实现,明确函数意义.之后还要进行代码复审. 但是我们同时也知道,在代码实现的过程中,我们的分工是有侧重的.而同一个事情的完成是可以使用一些成型或自己的算法进行优化的.而如果我们在使用一个比较"复杂"(是指思想复杂而实现简单,例如dp,kmp,manacher算法等

构建之法第四章学习心得

今天我学习了构建之法第四章,主要讲述了两人合作的理论和知识点.合作,无论在任何领域,都是不可缺失的,往往能产生不可替代的效果.同样在软件设计中也是如此,经过我的学习,我了解到软件设计中两人合作主要包括包括代码规范.极限编程.结对编两人合作的不同阶段以及影响他人的技巧. 其中最让我印象深刻的是代码规范.包括:代码风格规范和代码设计规范,代码风格规范主要是文字上的规定,看似表面文章,实际上非常重要:代码设计规范牵涉到程序设计.模块之间的关系.设计模式.等方方面面的通行原则: 同时,我了解了代码风格规

读《构建之法》第4,17章有感

读<构建之法>第4,17章有感 第四章:两人合作 原文:另外,注释(包括所有的源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 我的问题和看法:对于英语水平没有那么高的人来说,不允许中文注释真的太难了.刚开始学习代码的时候,老师就教导我们编程的时候一定要写注释,但是并没有非常严格的要求我们必须要用ASCII字符.我上网查找了一些资料,发现大部分公司对于注释并没有明确的要求.注释是为了方便让别人理解你的代码的,所以简洁易懂应该才是最重要的,在水平达到的情

读《构建之法:现代软件工程》第一章有感

在阅读了<构建之法:现代软件工程>第一章绪论后,我软件工程有了一定的了解,同时以一名机械学生为立场也有所感悟. 以前我只是简单的认为软件就是一个应用,你只需要去点击.exe文件就可以使用这个软件.而在阅读了邹欣老师的<构建之法:现代软件工程>后,我懂得软件=程序+软件工程,我们现在不应再停留于软件的用户体验.交互界面,更应该看到软件背后支撑它的程序代码等.软件工程是一个学科交叉的过程,它与许多学科都相关:计算机科学.计算机工程.管理学.数学.项目管理学.质量管理.软件人体工学.系统

读《构建之法》第4、17章有感

    诗云:半亩方塘一鉴开,天光云影共徘徊.问渠哪得清如许?为有源头活水来. 这是宋代理学大家朱熹对阅读一本好书的感受.这几天我看了邹欣老师写的<构建之法>第4.17章之后,产生了一点点类似的感受.下面我来点评一下. 关于"第4章 两人合作"的点评: 问题一: 原文(见第68页):另外,注释(包括所有源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 个人见解:可移植性是指代码在不同平台能否执行.注释会被执行吗?不会.那么,注释就与