软工读书笔记 week2

《程序员修炼之道》这本书后面一部分则是更深入、更具体、更细致地就程序员应该注意的事项做一些讨论,书中说的很多在过去的经历中都有较深的体会,同时也给了我很多启发。
以下是一些我感悟较深的点:

1、工匠与工具
    工匠在使用工具的过程中,二者互相磨合,工具甚至变成了工匠双手的延伸。这就好像我们学习与适应的过程。在学习初始阶段,我们先精心挑选我们的工具。然后在使用这些工具时,不断地熟悉,不断地适应,工具成为你的大脑的一部分,它能放大你的才干。
但是我们不能总局限于单一的工具,虽然有些工具看起来通用,但是当遇到一些特殊需求时,我们要像工匠学习,定期增加工具。就我自身而言,这方面我就做的不够好。我个人就属于习惯于一种后就不太愿意更改的人。这一点不是很好,我们要乐于超越工具(如IDE)施加的各种性质。
    2、纯文本
    纯文本有很多好处,首先纯文本格式不仅可以被机器理解,也是人可以理解的格式,这也就意味着它能够保存更久。
其次,纯文本格式具有简单性,它也更易于测试。我们可以很轻松的增加、修改测试数据,也可以轻松地分析回归测试输出的结果,或使用一些脚本工具进行彻查。
    3、源码控制系统
    我们应该总是使用源码控制系统。因为我过去没有进行过团队编程项目,对一些源码控制相关的工具也不是很了解。通过近期的认识,我愈发觉得源码控制系统非常重要。它能帮助你对比不同版本直接的对比,帮助你返回之前的版本等。
    团队项目,不论大小,都应该使用源码控制系统。虽然看起来有时候有些麻烦,但是养成习惯后对你整个项目都有非常大的帮助。
    4、调试bug
    我摘下了书中引用的这句话:
    “看着你自己的烦忧,并且知道不是别人、而是你自己一人所致
                                                                  ——索福克勒斯:《埃阿斯》”
    (1)接受事实
    首先我们要接受这个事实。Bug已经出现了,你要做的失去解决它。而调试就是解决问题,我们要据此发起进攻。
    (2)恰当的思维方式
    其次,恰当的思维方式非常重要。不要恐慌,恐慌不能解决任何问题。更不要浪费时间在觉得那不可能上,因为事实就是,这个程序已经错了。在学习C语言或者数据结构的时候,无论是平时上机实验,还是大作业,总会有或多或少的bug。而每当遇到bug,总是调试不出来时,我确实非常容易陷入焦虑情绪。因为在我自己看来,程序完全没问题啊。但是错误的运行结果又确确实实摆在眼前,只能硬调。
    (3)小心近视
书中还提醒我们要“小心近视”。因为有时bug可能是在你以为的地方几步远的地方。而如果总是陷在一个点中,就会像我有时调试bug一样,调试几个小时,结果发现只是一个小小的变量打错了。
    (4)再现bug
要真正解决bug,我们要有能力将bug再现,也就是说我们要知道bug是怎么出现的。只有知道它是怎么出现的,我们才能学会避免它。
    (5)橡皮鸭
    这个概念,是我在数据结构课在大佬们的讨论中第一次听说的。调试bug一个很有效的办法就是向别人解释你的代码,往往在你解释的过程中,你就能发现bug所在。因为bug出现一定是和你的逻辑有关的。如果我们能够从头按正确的逻辑梳理一遍代码,很大概率能发现代码的漏洞。
    (6)不要假定,要证明
    不要轻易下结论“这不可能”,不要轻易放弃任何微不足道的地方。不要理所当然地去假定,而应该去证明它。
    (7)让下次修复更容易
    修复完bug后,我们需要想想,我们可以做些什么,让下次修复更容易。比如书中提到的内建更好的测试挂钩,或是编写日志文件分析器。
    (8)早崩溃
    让程序崩溃是你的最佳选择。这句话虽然单看有些怪,但就程序而言,一个死程序带来的危害要远远小于一个有病患的程序。

原文地址:https://www.cnblogs.com/hytu/p/8613195.html

时间: 2024-10-02 05:04:48

软工读书笔记 week2的相关文章

软工读书笔记 week 8 —— 《疯狂的程序员》

这次接着上一次的进度继续阅读,并将其中感悟较深的几点记录如下.      程序员是一个幕后工作者 书中绝影给医院写软件,而医生(用户)只是评价这个软件好不好用,而不会去评价写这个软件的程序员优不优秀.这看起来对程序员不太公平,我辛辛苦苦写的代码,评价都没有我的份.但是这就是个事实,一个软件开放给用户的只是它的功能.它的界面,用户不会管某一个功能实现起来背后的代码有多复杂,他只是从他用这个软件的感受出发.所以,还是那句话,用户体验是第一位的. 高分和技术矛盾吗 在周总审阅简历的时候,有这么一份简历

软工学习笔记——代码规范

上大学以来写了这几年的代码,却一直没怎么关注过代码规范相关的问题,直到软工课上讲了之后,才开始有所顾及.上课的时候回头看看自己写过的那些代码,真是丑死了,几个月前自己写的代码现在就已经读不懂了. 看了书上的相关章节,对于我来说,我觉得我的代码主要注意这几点: 1. 少写冗余代码,已经用不到的代码段就应该删去.(我今天刚刚发现我的昆特牌Online项目中竟然还存在有两个没用的类) 2. 多利用空行来将代码小规模地分段. 3. 大段的无用代码不要一直注释着,该删就删.(我的项目里经常会有一大堆没用的

读书笔记-1 《人月神话》

软工读书笔记1--<人月神话> 第一次接触软件工程这门学科,也是第一次做IT类图书的读书笔记,我选择了<人月神话>这本书,一周的时间很有限我只是大致过了一遍全书,对部分感兴趣的章节进行了精度,我也就拣这些谈谈自己的感想吧. 文章一开头就用焦油坑这个形象的比喻诠释了软件开发行业的本质特征--惨烈,软件开发过程中遇到的各种问题就如同焦油坑,只有少数开发团队能够经受住考验,这样的开场对小白来说简直是个灾难啊.之后文章给出了具体的苦恼和乐趣,看着似乎舒坦了不少. 一方面苦恼在于需要追求完美

《大巧不工》读书笔记

“结构与表现分离”,即在没有引入样式表的情况下,页面也能呈现很好的结构.这是前端开发人员遵守的第一原则. 通常情况下,页面应包含的元素:标识.站点名称.站点导航.搜索框.功能区.边栏和页脚. 清除不必要的<div>标记,使用语义化的标签及命名标识,尽量减少使用<div>标记,格式化代码,并在布局区块加上必要的注释. 选项卡的标签及其对应的内容应放在同一容器中,才能体现它们的关系,易于阅读.这是大部分前端开发人员容易忽视的问题. 模态窗口属于独占资源,用户必须在窗口中做出某种选择,否

《软技能:代码之外的生存指南》读书笔记1

概述 这是我读<软技能:代码之外的生存指南>这本书的读书笔记,夹杂着一些感悟,记录下来,作为我的生活点滴,也提醒我以后的路该怎么走,相信对其他人也有用. 职业生涯属于我自己 你所能犯的最大错误就是相信自己是在为别人工作.这样一来你对工作的安全感已然尽失,职业发展的驱动力一定是来自个体本身.记住:工作是属于公司的,而职业生涯却是属于你自己. 只有你开始把自己当做一个企业思考时,你才能开始做出良好的商业决策. 在一个专业上拥有特长 在你现在或以前工作的公司里,有哪些主要的痛点?你能成为一名专门解决

个人阅读作业2 软工方法论无用?

初步看了推荐的文章以后,我选择了最后一篇文章来阅读,原因是“软件工程的方法论到底有多少用处”这个问题也是我目前很大的一个疑问,于是我决定首先看看这篇文章怎么说. 文章在开头举了一个离我们很近的例子:结对编程到底是解决了代码评审的问题还是无谓地增加了沟通成本?作者提出增加沟通成本的意思很清楚:结对编程非但没有逃避代码评审的繁复,却增加了额外的工作量:沟通,并且这些沟通并没有起到期望的作用:使一段代码由两个人看过以后更加完美.我在结对编程中便遇到了这样的问题,当一个人在写代码时,他的思维运转是比较快

读书笔记 2018-3-7

<构建之法>读书笔记 虽然因为上课的原因,并未能够将这本书全部读完,但读过的一部分章节也给我留下相当深刻的印象.或者说,将我原来的对于软工的印象完全颠覆.在选课之前,我本以为软工就像是和原来的C语言还有数据结构上机实验一样,只要随便写个程序输出一个结果就可以,最多完成一个类似于数组运算器之类的大作业就好.但事实却非如此,正如本书在第一章举出的例子一样,原本那些简单的程序就像是折一个纸飞机,而我们在这门课中需要学习的,却是如何去建造一架真正的飞机.虽然可能并不能够飞的多么高.多么快,但却麻雀虽小

第九次读书笔记——读《代码整洁之道》有感

第九次读书笔记--读<代码整洁之道>有感 "相对于任何宏伟景愿,对细节的关注甚至是更为关键的专业的基础.首先,开发者通过小型实践获得可用于大型实践的技能和信用度.其次,宏伟建筑中最细小的部分,比如关不紧的门,有点没有铺平的地板,甚至是凌乱的桌面,都会将整个大局的魅力毁灭殆尽."看完了这本书,感觉书中的这句话是整本书的核心.个人感觉这本书给我带来的更多的不是能力上的提升,而是思想上对代码整洁有了整体的把握. 首先,这本书让我们在思想层面上认识到了代码整洁的必要性,只有思想有了

Linux内核架构读书笔记 - 2.5.2 数据结构

调度系统各个组建关系如下 激活调度器两种方法:进程睡眠或其他原因放弃CPU,周期性检测 上述两个组件统称为通用调度器或核心调度器. 调度器用于判断接下来运行那个进程,内核支持不同的调度策略( 完全公平调度 实时调度 无事可做的空闲调度进程) 调度器被调用时候 需要执行体系相关的进程上下文切换 每个进程属于某个调度器类,各个调度器负责管理所属进程,通用调度器不涉及进程管理,都由调度器来 下面分别讲述: task_struct 成员 sched.h 1 struct task_struct { 2