Welcome! Lately you’ll find me here scribbling down notes on what I’m learning. If you read anything here and have feedback, corrections or thoughts, I’d love to hear from you.
Python 中的元类
元类(metaclass)是 Python 中一个高级概念,它控制了类的创建过程。在 Python 的开源框架中,可以看到很多元类的相关身影,学习并理解元类也可以帮助理解 Python 中的类的创建过程。 一切皆对象 在 Python 中一切皆对象,类也不例外,类也是一个对象,可以像普通对象一样进行赋值、拷贝以及作为函数的参数使用。我们知道每个对象都有一个类型,在 Python 中可以通过 type() 函数进行查看,一个 Python 实例它的类型是 class 类名,那类这个对象的类型又是什么呢,可以通过下面的一组例子进行查看。 class Foo: def __init__(self): pass foo = Foo() # 也可以通过 obj.__class__ 查看类型 print(type(foo)) # <class '__main__.Foo'> print(type(Foo)) # <class 'type'> print(type(1)) # <class 'int'> print(type(int)) # <class 'type'> print(type(type)) # <class 'type'> 我们可以看到实例 foo 的类型是class Foo, 而 Foo (类本身) 的类型是 type ,更近一步地,查看内置类型以及 type 本身的类型。我们可以发现,类的类型是 type,这实际上就是元类。正如普通对象是类的实例一样,Python 中的任何类都是type元类的实例,我们可以用下面的图来表示这种关系。 <!DOCTYPE html> 图1. Python 类型示意图 创建类:type 类也是对象,可以在运行时动态的创建它们,就像其他任何实例对象一样,例如可以在函数中创建类。另外,借助type,也能动态的创建类。type可以接受一个类的描述作为参数,然后返回一个类。可以像这样使用:type(类名, 父类的元组(针对继承的情况,可以为空),包含属性的字典(名称和值)),使用这种方式上一节中的类可以使用下面的方式创建: ...
记 2023
写在前面 2023 即将结束,这一年我从学校走向工作,为了在不断重复向前的日子里留下点什么,我决定开始写年终总结,并想要养成定期总结反思的习惯。这一年我并没有刻意记录,只能凭借记忆留下一点生活的流水账,记录一些读过的书,写下一些变化带给我的感想,再写写未来我想要聚焦的一些目标以及对新的一年的期许。 流水账 家里蹲 2022年底随着疫情防控政策的放开,高校陆陆续续的让学生提前回家,因此在研究生的最后一年能够提前回家,得以家度过了元旦,这是多年没有过的。 在家的这段时间是轻松惬意的,此时早已确定了毕业后的工作去向,刚刚经历开题,毕业论文的压力还尚未到达眼前,作为准毕业生,也没有安排其他的项目去完成,一切可以按照自己的安排去进行。学业上,在这段时间,我整理了硕士期间阅读过的一些分割方向的论文,并找了一些新的文章,试图从中找到一些能够启发我毕设的点;这段时间我采用 Open MMLab 框架从头搭好了实验框架,并完成了实验数据集上所需要对比的一些实验。总得来说,这段时间,从起床就读论文,然后写代码推进试验,生活上又有家人的照料,没有什么干扰,效率反倒是比在实验室要高一些。 趁着这个自由的假期,我重构了博客主题让它变成了现在的样子,为了看起来不那么业余,搭建了 CI/CD 以及自动化订阅发布。由于博客采用的是 Hugo 构建的,我又实现了一批实用且稍显创意的 shortcodes,并分享在《Hugo Shortcodes 示例》这篇文章中,时至今日,这篇文章也成了我评论数最多的文章。一点小小的创意能够得到别人的赞同或是帮到别人我也还是挺开心的。 至于假期其它时间,也会和家人坐在一起看看热播剧,刷刷手机,聊聊天,虽谈不上什么收获,但也轻松幸福,不觉虚度。特别是今年从学校走向职场,以后可能再难有这样长的时间和家人轻松呆在一起。 毕业篇 二月中旬是学校规定的最后返校时间,考虑到机会难得,我并没有提前返校,在家一直待到了规定的最后时间,而返校之后的关键词也只有一个:毕业论文。 尽管返校之后在与室友和同门交流之后我了解到我的毕设进度并不算慢,但是依然不敢松懈,毕竟四月底就要提交论文盲审,而此时的论文还没有正式下笔。同时,学校这两年对于毕业论文的要求逐步提高,一种紧张焦虑的氛围还是笼罩着大多数的毕业生(可能不准确,是我太菜才有这种感觉🙃)。总之,这两个月身心基本都在论文上,有过早上第一个到达实验室,也有过晚上十一点回到宿舍改动论文、实验到凌晨。根据 GitHub 上的编译记录,论文一共提交编译了 64 次,差不多是每天一次,提交盲审前的最后一次改动也是定格在了 4 月 22 日,之后就是提交盲审之后的等待。 五月初,盲审结果下来两个良好,算是意料之中。之后也就是准备毕业答辩,这中间倒是没有什么波折与意外,剩下就是毕业总会有的一些吃喝玩乐。 大约六月二十多号的时候参加了学校的举行的毕业典礼,毕业典礼坐在下面还是有些感触的,实话讲,倒不是说对学校、老师或者同学有不舍,而是对即将走向社会、走向工作岗位有种兴奋与忐忑,对未来怀有信心但又觉得前路并不明朗。当然,也少不了获得学位的喜悦,尤其在这上面这半年还是下了点功夫的。 <!DOCTYPE html> 打工篇 7月初入职到转正,算下来到现在差不多半年,这接近半年的工作内容在此就不做叙述了。相比于在学校每天早上醒来要纠结下到底去不去实验室来说,上班的日子就规律了不少,不用纠结,班是必须要上的。我是比较适合这种规律的生活的,加之作为新人也没有太大工作的压力,工作内容上也并不排斥,简单的生活也并没有让我觉得枯燥乏味。客观来讲,虽然生活简单规律,但是业余的自由时间相比于在学校还是少了些,工作上的事情追求结果,在可用性和完成情况上也有着明确的标准,不能像在学校一样划划水。 阅读 回顾这一年闲暇的时光,除了小红书、飞书之外也看了一些其他的书,根据我在豆瓣上标记的读完时间,这一年读完的差不多是下面这些,有些并非在今年开始阅读的,比如 《浪潮之巅》和 《亲密关系》就读了很久很久。我的阅读虽然没有什么主题倾向,但伴随着这一年的生活也有些规律可循。上半年,写论文的时候读了《永恒的终结》和《献给阿尔吉侬的花束》两本的科幻小说,阅读小说总是相对轻松,而读一点科幻的作品是想在毕设期间开拓下思维(事实证明对我没用);下半年工作之后,有段时间感觉生活中少了些自由,每天就是不断的重复又找来了《冬牧场》、《寻路中国》和《江城》来读,通过这种方式看看外面的世界,了解一些不一样的生活;工作小半年,手上也算上了一个小门槛,快到年底的时候又读了《富爸爸,穷爸爸》,未来计划做一些投资理财方面的尝试。 9 万历十五年 8.5 忍不住想打扰你 9.3 深入剖析Kubernetes 8.3 富爸爸,穷爸爸 更多 9.1 江城 9 寻路中国 9.1 冬牧场 8.8 代码整洁之道 9.3 悉达多 9.2 李光耀观天下 9.1 献给阿尔吉侬的花束 9.1 永恒的终结 8.6 高效能人士的七个习惯 9.6 数据密集型应用系统设计 9.1 浪潮之巅(第四版)(上下册) 9. ...
![](https://ydj-image-1258588170.cos.ap-chengdu.myqcloud.com/blog/post-images/content/posts/life/year-post.webp)
Kubernetes 整体架构与核心组件
Kubernetes 整体架构 从整体来看 Kubernetes (k8s) 主要由两种节点组成,分别是 Master 节点和 Node 节点,其整体结构如图1 所示。Master 节点由三个紧密协作的独立组件组合而成,分别是:kube-apiserver、kube-scheduler 以及 kube-controller-manager;Node 节点上最核心的是名为 kubelet 的组件以及 kube-proxy。下面结合图1 对一些组件的功能进行说明。 <!DOCTYPE html> 图1. kubernetes (k8s) 整体架构图(来源于网络) 核心组件 kubectl & cliet-go kubectl 是 k8s 官方提供的命令行工具,它通过 HTTP/JSON 通信协议以命令行的方式来与 kube-apiserver 交互。 client-go 则是通过编程的方式来与 API server 进行交互,使开发者能够以编程的方式管理和操作集群中的资源,它实现的功能与 kubectl 相同。k8s 的其他组件与 api server 进行通信也是基于 client-go 实现的。如果需要对 k8s 进行二次开发,也可以使用 client-go。 Master 节点核心组件 kube-apiserver Kube-apiserver 主要负责 API 服务,集群中所有的组件都是通过 API server 组件来操作资源对象,它也是集群中唯一与 ETCD 集群进行交互的核心组件。k8s 中所有的资源对象被封装成 RESTful 风格的 API 接口进行管理。同时,API server 还提供了集群的安全访问机制,如认证、授权、准入控制、审计等。 ...
[译]阅读的重要性
原文:The Need To Read 在我小的时候阅读的科幻小说中,阅读常常被一些更高效获取知识的方式所取代。神秘的“磁带”会将知识加载到一个人的大脑中,就像将程序加载到计算机中一样。 这种情况很可能不会很快发生。不仅因为构建阅读的替代品很困难,而且即使存在一个替代品,也是不够的。阅读关于 x 的内容不仅教给你关于 x 的知识,还教给你如何写作1。 那又怎样?如果我们替代了阅读,还需要有人擅长写作吗? 之所以重要,是因为写作不仅是传达思想的一种方式,还是产生思想的一种方式。 一个好的作家不只是思考,然后将他的想法写下来,作为记录。一个好的作家在写作的过程中几乎总是会发现新事物。据我所知,对这种发现没有替代品。与其他人讨论你的想法是发展它们的好方法。但即使这样做了,当你坐下来写作时,你仍然会发现新事物。有一种思考只能通过写作来完成。 当然有些思考是可以在没有写作的情况下完成的。如果你不需要深入研究一个问题,你可以在不写作的情况下解决它。如果你在考虑两台机器应该如何组合在一起,写作可能对此帮助也不大。当一个问题可以被正式描述时,有时你可以在脑中解决它。但是,如果你需要解决一个复杂而不明确的问题,写作几乎总是有助于解决问题。反过来这意味着在解决这类问题时,写作能力较差的人几乎总是处于劣势。 没有良好的写作就无法进行良好的思考,没有良好的阅读就无法进行良好的写作。我指的是最后一个“好”在两个方面都是如此。你必须擅长阅读,而且要读好的东西2。 只想获取信息的人可能会找到其他获取途径。但想要产生思想的人不能不重视。 有声读物可以为你提供优秀写作的示例,但让别人为你朗读并不能像自己阅读那样教你很多关于写作的东西。 ↩︎ 这里的“擅长阅读”不是指擅长阅读的技巧,相比于阅读技巧,获取文字含义更加重要。 ↩︎
rsync 用法
在不同的机器和服务器之间进行数据同步是一个常见的场景,也有不同的命令工具(如 scp、FTP 等),甚至是不同的图形界面软件(如 Termius 等)可供我们选择操作。本文记录的 rsync (remote sync)也是用于文件同步的工具之一,其最大的特点是会检查发送方和接收已有的文件,并仅传输有变动的部分。rsync 不仅可以在本地不同的目录之间使用,同时也支持本地主机与远程服务器之间进行数据同步。由于其具有仅传输变动、增量备份、 断点续传等特点,在一些场景下非常实用。本文记录了其一些常见的用法,主要关注其在本地主机与远程主机之间同步的操作。 在使用 rysnc 之前需要确保本地和远程主机都安装了 rsync,可通过 rsync --version 检查是否安装,如果没有,可使用下面的命令进行安装: sudo apt-get install rsync # ubuntu brew install rsync # macOS rsync 的基本使用如下: rsync -av [source] [destination] -a: 表示递归同步,并同步元信息 -v: 输出到终端 如果目标位置不存在,执行上诉命令之后将会自动创建。 常用参数 -n 如果不确定执行 rsync 会有什么结果,可以使用该参数查看执行后的结果,并不真正执行命令。 x – + yandaojiang@Daojiang-macbook-pro [ydj-macbook-pro ~ % rsync -anv ./Desktop ubuntu@110.42.182.66:~/ sending incremental file list Desktop/ Desktop/.DS_Store Desktop/.localized Desktop/截屏2023-03-06 14.40.26.png sent 179 bytes received 29 bytes 83.20 bytes/sec total size is 600,104 speedup is 2,885.12 (DRY RUN) [ydj-macbook-pro ~ % --delete 默认情况下,rsync 只是将源目录的所有内容都复制到目标目录,并不会保证两个目录相同,也不会删除文件。因此,如果是想要构建源目录的镜像就需要使用 --delete 参数,这样保证目标目录和源目录相同。 --exclude --exclude参数用于排除文件或者目录,利用该参数指定排除模式。排除多个模式的文件时,可以使用 Bash 的扩展功能。如果需要排除的文件数量比较多,那么可以将其需要排除的文件所对应的模式写入文件,每个模式负责一行,然后利用 --exclude-from 参数指定文件。 与 --exclude 参数所类似的有 --include 参数,用于指定必须同步的文件,二者一般联合使用。 ...
Linux 60秒性能分析
原文:Linux Performance Analysis in 60,000 Milliseconds 当你登陆到一台性能出现问题的 Linux 服务器:你在第一分钟会检查什么? 在 Netflix,我们拥有一个庞大的 EC2 Linux 云和大量的性能分析工具,用于监控和调查其性能。其中包括 Atlas 用于云范围的监控和 Vector 用于按需实例分析。虽然这些工具帮助我们解决了大多数问题,但有时我们需要登录到一台实例并运行一些标准的 Linux 性能工具。 60秒摘要 这篇文章将介绍 Netflix 性能工程团队在命令行下使用标准 Linux 工具进行优化性能调查的前60秒,你也可以使用这些工具。在60秒内,你可以通过运行以下十个命令了解系统资源使用情况和正在运行的进程。查找错误和饱和度指标,然后查看资源利用率。饱和是指资源的负载超过其处理能力,可表现为请求队列的长度或等待时间。 uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top 其中一些命令需要安装 sysstat 软件包。这些命令输出的指标将有助于完成一些性能瓶颈的定位(USE 方法)。这涉及检查所有资源(CPU,内存,磁盘等)的利用率、饱和度和错误指标。还要注意何时检查和排除了资源,因为通过排除,可以缩小要研究的目标,并指导任何后续的分析。 以下部分总结了这些命令,在生产系统中给出了示例。有关这些工具的更多信息,请参阅它们的 man 页面。 1. uptime $ uptime 23:51:26 up 21:31, 1 user, load average: 30. ...
Git 常用命令总结
配置 git config --list # 查看配置 git config -e [--global] # 编辑配置文件 # 设置提交代码时的用户信息 git config [--global] user.name "[name]" git config [--global] user.email "[email address]" 版本管理 版本回退 git reset 版本回退是指将版本库恢复到上个或者某个 git commit 之后。Git 中每次进行 commit 操作会在版本库中保存一个快照,如果把文件改乱了,或者误删了文件,可以从某个 commit 恢复,用到的操作命令如下: git reset [--soft | --mixed | --hard] <commit-id | HEAD> 说明: --mixed: 默认参数,不删除工作空间改动代码,撤销 commit,并且撤销 git add . --soft: 不删除工作空间改动代码,撤销 commit,不撤销 git add . --hard: 删除工作空间改动代码,撤销 commit,撤销 git add . (即完全恢复到某次 git commit 之后) 如果使用 --mixed 或者 --soft 参数回到多个版本之前时,需要注意后面多次修改的内容都会留在工作区或者暂存区 其中 commit-id 可用命令 git log --pretty=oneline 查看。回退的版本较近时可以用 HEAD 表示,在 Git 中,用 HEAD 表示当前版本,上一个版本就是 HEAD^,上上一个版本就是 HEAD^^,依次类推。 ...
![](https://git-scm.com/images/branching-illustration@2x.png)
Hugo Shortcodes 示例
大多数的静态博客会使用 Markdown 进行写作,因为它的格式简单,但是 Markdown 也有它的不足之处。当我们想要将图片或者视频等加入到文章内容中时,Markdown 本身并不能提供很好的支持,因此不得不将一些 HTML 片段加入到 Markdown 内容中。尽管在一些简单的场景中这样做能够解决问题,但是却破坏了 Markdown 文件的简洁性质。另外如果想对一些内容进行装饰也变得非常麻烦,而且不能起到复用的效果。为此,Hugo 引入了 shortcodes,允许我们在 Markdown 文件中以一种简洁的形式书写 HTML。本文记录了此博客中实现和使用到的一些 shortcodes。 图片 在博客内容中插入图片是一个常见的需求,Markdown 语法本身也支持图片的插入。但是如果要对图像的大小,图像的位置进行修改就需要在 Markdown 文件中直接使用 HTML 进行控制,如果更进一步对图像添加描述,或者使用 CSS 对图像进行修饰就变得比较麻烦,为此本博客中针对图像显示问题实现了多个 shortcodes,用于增强博客的图像显示功能。下面是实现的用于插入图片的 shortcodes 的实际效果: 样式一: <!DOCTYPE html> 图1. 通过 Hugo shortcode 插入图片,并在图片底部加入图片描述 样式二: <!DOCTYPE html> Youtube 为了进一步丰富博客的内容,本博客还添加了对视频的支持,在博客内容中对 Youtube 的视频内容进行嵌入,并支持播放和调转到官方网站进行播放,下面是实际效果: Youtube 视频 (由于国内无法直接播放 Youtube 视频,这里采用图片的方式对最终的效果进行了展示) Podcast / Music Markdown 本身并不支持对音频的插入,使用 HTML 虽然能够简单的完成音频的插入,但是其显示效果并不美观,并且仅仅支持播放、暂停。为了让博客支持插入播客等音频内容,本博客实现了一个播放器,效果如下: <!DOCTYPE html> Hold My Hand Lady Gaga Your browser does not support the audio tag. ...
Channel原理与实现
数据结构 channel内部的数据结构表示如下: type hchan struct { qcount uint // channel中元素的个数 dataqsiz uint // channel中循环队列的长度 buf unsafe.Pointer // channel缓冲数据指针 elemsize uint16 // 收发的元素大小 closed uint32 elemtype *_type // 收发的元素类型 sendx uint // channel的发送操作处理到缓冲位置 recvx uint // channel的接收操作处理到缓冲位置 recvq waitq // 当前因为缓冲区不足而阻塞的Gorontine列表 sendq waitq lock mutex } 阻塞的 GoRoutine 等待队列使用双向链表表示,链表中所有的元素是 runtime.sudog 结构: type waitq struct { first *sudog last *sudog } 该结构中存储了两个分别指向前后 runtime.sudog 的指针构成的链表。 创建channel Go 语言中所有的 channel 都使用 make 关键字进行创建,并转换为 runtime.makechan 或者 runtime. ...
个人博客技术选型与实践
技术选型与可替代方案 在搭建博客的过程中涉及到很多的选择,例如我们会考虑博客的类型,是使用静态博客还是动态博客。之后又涉及到博客框架的选择,当前有很多的框架可供我们选择,如果所有的选择都不满意甚至可以考虑自己从头设计一个或者基于一个框架或者主题等进行个性化的修改。我们的博客最终是需要通过互联网可访问的,这又涉及到我们将其部署在哪里,采用何种方式进行部署。下表展示了本站的技术选型以及其他一些可替代的方案。在本文的剩余内容中,我也将从这几个方面对本站的建设进行说明。 技术选型 替代方案 类型 静态博客 WordPress 等动态博客 框架 Hugo Hexo, Jekyll 评论 Twikoo Valine 等第三方评论系统 部署平台 腾讯云 GitHubPages,阿里云 / 华为云 / AWS / Azure / Digital Ocean 等主流云平台 存储 腾讯云 COS 阿里云OSS,七牛云等 持续集成 Github Actions Travis CI,Gitlab CI 等 主题 PaperMode 博客类型选择 目前个人搭建博客通常会有两种选择:静态博客和动态博客。静态博客其格式一般为静态网页。动态博客则是通过与后端数据库交互,再动态渲染而成的。每当用户访问博客时浏览器会发送 HTTP 请求到后端服务,后端服务查询数据库,渲染页面返回给用户的浏览器。因此,动态博客需要更多计算资源和存储资源。相比而言,静态博客的资源占用更少,访问速度也更快,同时安全性更高。因此本站选择的是静态博客这种类型。 框架选择 目前有很多的博客框架可供我们进行选择,那么我们该如何进行选择呢?通常而言我认为需要从以下几个方面进行考虑: 框架的使用者数量要多。选择一个大家都在使用的框架在后面遇到问题的时候能够更好的寻找解决方案。同时,一个使用者数量多的博客生成框架通常也意味着会有更多的主题可供选择。 框架的文档完善。在考虑各个框架的时候我们还要看它的文档是否是完善的。一般而言,文档通常都是英文的,对于英文不好的人还可以考虑是否有完善的中文文档。 框架的性能。由于我们最终部署的是静态网页,因此我认为对于一个框架的性能不是我们主要需要考虑的。 在综合考虑了上面的几个方面后,我最终选择了Hugo 作为本站的构建框架。Hugo 是最流行的开源静态站点生成器之一,有着丰富的主题可供选择,而且其构建过程简单灵活。 评论系统 为了在博客上提供一个交流平台,通常都需要建设一个评论系统。动态博客其服务器上通常有评论相关的数据库可以非常方便的实现评论功能,但是对于静态博客,通常就需要一些第三方的评论系统来进行支持。这方面的选择非常多,但是很多都不是一个完美的方案。对于本站最终选择的是Twikoo,一个简洁、安全、免费的静态网站评论系统,是基于腾讯云开发的。该评论系统的文档是中文的,并且比较完善,参考起文档可以非常方便的进行部署。 部署平台与存储 在网站的部署平台上可分为两大类,一类是使用 GitHub Pages 这样的服务,部署非常的简单,但是问题是访问速度可能比较慢。另外一类方案就是借助一些云平台提供的服务进行部署。国内可供选择的有阿里云、腾讯云、华为云等,但是在部署网站的时候需要进行备案。国外也有很多云平台可供选择,甚至价格更低,但是通常访问速度可能偏慢。 对于一些内容的存储如图片等,我们可以直接选择使用服务器进行存储,但是如果数量比较大的话可能加重服务器的存储负担,因此另外一种选择就是使用一些云厂商提供的对象存储服务。本站采用了腾讯云的 COS 服务作为图像等内容的存储。 持续集成 我们搭建了博客之后通常是需要时常进行更新的,这就涉及到网站的部署与集成,如果每次进行更新之后都手动进行服务器的上传就显得比较麻烦,因此我们可以考虑采用持续集成的方案。如果你使用 Github 托管静态博客的代码,那么 Github Actions 更是你自动化部署的不二选择!使用 GitHub Actions 之后每次我们只用在内容上进行更新,然后将其 Push 到远程仓库的对应仓库就能实现对应的自动化部署,非常方便。当然也有其他非常好的 CI/CD 工具可以选择,如 Travis CI 等。 ...
职业的乐趣与苦恼
摘自 FrederickP.Brooks.Jr 的《人月神话》第一章 焦油坑 职业的乐趣 编程为什么有趣?作为回报,它的从业者期望得到什么样的快乐? 首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样,成年人喜欢创建事物,特别是自己进行设计。我想这种快乐是上帝创造世界的折射,一种呈现在每片独特、崭新的树叶和雪花上的喜悦。 其次,快乐来自于开发对其他人有用的东西。内心深处,我们期望其他人使用我们的劳动成果,并能对他们有所帮助。从这个方面,这同小孩用粘土为"爸爸办公室"捏制铅笔盒没有本质的区别。 第三是整个过程体现出魔术般的力量。将相互啮合的零部件组装在一起,看到它们精妙地运行,得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力,程序化的计算机毫不逊色。 第四是学习的乐趣,来自于这项工作的非重复特性。人们所面临的问题,在某个或其它方面总有些不同。因而解决问题的人可以从中学习新的事物:有时是实践上的,有时是理论上的,或者兼而有之。 最后,乐趣还来自于工作在如此易于驾驭的介质上。程序员,就像诗人一样,几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象,来建造自己的"城堡"。很少有这样的介质–创造的方式如此得灵活,如此得易于精炼和重建,如此得容易实现概念上的设想。(不过我们将会看到,容易驾驭的特性也有它自己的问题)然而程序毕竟同诗歌不同,它是实实在在的东西;可以移动和运行,能独立产生可见的输出;能打印结果,绘制图形,发出声音,移动支架。神话和传说中的魔术在我们的时代已变成了现实。在键盘上键入正确的咒语,屏幕会活动、变幻,显示出前所未有的或是已经存在的事物。 编程非常有趣,在于它不仅满足了我们内心深处进行创造的渴望,而且还愉悦了每个人内在的情感。 职业的苦恼 然而这个过程并不全都是喜悦。我们只有事先了解一些编程固有的烦恼,这样,当它们真的出现时,才能更加坦然地面对。 首先,必须追求完美。因为计算机也是以这样的方式来变戏法:如果咒语中的一个字符、一个停顿,没有与正确的形式一致,魔术就不会出现。(现实中,很少的人类活动要求完美,所以人类对它本来就不习惯。)实际上,我认为学习编程的最困难部分,是将做事的方式往追求完美的方向调整。 其次,是由他人来设定目标,供给资源,提供信息。编程人员很少能控制工作环境和工作目标。用管理的术语来说,个人的权威和他所承担的责任是不相配的。不过,似乎在所有的领域中,对要完成的工作,很少能提供与责任相一致的正式权威。而现实情况中,实际(相对于正式)的权威来自于每次任务的完成。 对于系统编程人员而言,对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程序,而往往这些程序设计得并不合理,实现拙劣,发布不完整(没有源代码或测试用例),或者文档记录得很糟。所以,系统编程人员不得不花费时间去研究和修改,而它们在理想情况下本应该是可靠完整的。 下一个烦恼–概念性设计是有趣的,但寻找琐碎的bug却只是一项重复性的活动。伴随着创造性活动的,往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外。 另外,人们发现调试和查错往往是线性收敛的,或者更糟糕的是,具有二次方的复杂度 。结果,测试一拖再拖,寻找最后一个错误比第一个错误将花费更多的时间。 最后一个苦恼,有时也是一种无奈——当投入了大量辛苦的劳动,产品在即将完成或者终于完成的时候,却已显得陈旧过时。可能是同事和竞争对手已在追逐新的、更好的构思;也许替代方案不仅仅是在构思,而且已经在安排了。 现实情况比上面所说的通常要好一些。当产品开发完成时,更优秀的新产品通常还不能投入使用。事实上,只有实际需要时,才会用到最新的设想,因为所实现的系统已经能满足要求,体现了回报。 诚然,产品开发所基于的技术在不断地进步。一旦设计被冻结,在概念上就已经开始陈旧了。不过,实际产品需要一步一步按阶段实现。实现落后与否的判断应根据其它已有的系统,而不是未实现的概念。因此,我们所面临的挑战和任务是在现有的时间和有效的资源范围内,寻找解决实际问题的切实可行方案。 这,就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。