译者序
素养强调的并不是天赋的神秘,也不是技艺的高深,而是持续积淀的结晶:一方面,它体现了能力和素质;另一方面,它又强调了持续的积累和养成。
真正的解决办法,是约定共同认可的验收测试标准。笔记:甲方就不要一直问有没有更好的,应该用定量的数据说话,达到要求就可以了,不断提高上限有刁难的味道。
序
负责技术方面工作的项目经理笔记:或许可以做为自己的职业目标
负责业务方面的项目经理笔记:是负责技术方面的项目经理的合作伙伴
必读引言
请把本书看成我的错误大全笔记:错误才有学习的价值,与其告诉你怎么成功,不如告诉你怎么避免失败,因为成功不可复制,错误动动脑子就可以避免
第1章 专业主义
1.1 清楚你要什么
实际上,专业主义的精髓就在于将公司利益视同于个人利益,看到了吧,“专业主义”就意味着担当责任。
没有对例行程序进行测试就交付软件是不负责任的。
1.3 首先,不行损害之事
(1)开发的软件有bug会损害软件的功能。
(2)软件开发太复杂了,不可能没什么bug。但很不幸,这并不能为你开脱。人体太复杂了,不可能尽知其全部,但医生仍要发誓不伤害病人。笔记:我觉得本质上是一样的
所谓专业人士,就是能对自己犯下的错误负责的人,哪怕那些错误实际上在所难免。所以,雄心勃勃的专业人士们,你们要练习的第一件事就是“道歉”。道歉是必要的,但还不够,你不能一而再、再而三地犯相同的错误。
什么样的代码是有缺陷的呢?那些你没把握的代码都是!
测试驱动开发(TDD)
但是有些代码不是很难测试吗?是的,但是之所以很难测试,是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码,最好是先写测试代码,再写要测的代码。
所有软件项目的根本指导原则是,软件要易于修改。
要想证明软件易于修改,唯一办法就是做些实际的修改。
为什么大多数开发人员不敢不断修改他的代码呢?因为他们害怕会改坏代码!为什么会有这样的担心呢?因为他们没做过测试。
1.4 职业道德
将自己的职业发展寄希望于雇主的软件开发人员将会很惨。笔记:所以跟雇主不要强调潜力,说“我可以学”,这是你自己的事,你要跟他说有马上就可以为你带来什么样的价值的能力。
雇主也没义务给你留学习的时间。
你应该计划每周工作60小时,前40小时是给雇主的,后20小时是给自己的。在这剩余的20小时里,你应该看书、练习、学习,或者做其它能提升职业能力的事情。
因为所谓“术业有专攻”那也是需要投入时间去追求的。
或许你会觉得工作就该在上班时间完成,不该再带回家中。赞成!
桑塔亚纳的诅咒:“不能铭记过去的人,注定要重蹈覆辙。”
不懂就学,不要畏难。笔记:自控力和畏难情绪是阻止进步的两大首要因素。
最糟糕、最不专业的做法是,简单按照规格说明来编写代码,但却对为什么那些业务需要那样的规格定义不求甚解。笔记:因为做传感器系统的开发,就有必要去了解传感器的相关知识,才是负责任的做法。
第2章 说“不”
“能就是能,不能就是不能,不要说‘试试看’。” ———尤达笔记:“我可以学”,那就说“能”。
奴隶没有权利说“不”。劳工或许也对说“不”有所顾虑。但是专业人士应该懂得说“不”。笔记:大部分人对自己的定位都是劳工。
2.1 对抗角色
“为什么”远不如“事实”重要。事实是,“登录页面”还需要两周才能完成。而为什么需要两周,则只是个细节。
有时候,提供太多细节,只会招致更多的微观管理。
2.3 要有团队精神
许诺“尝试”,就意味着你承认自己之前未尽全力,承认自己还有余力可施。
2.4 说“是”的成本
多年的从业经验让我渐渐明白,是客户需求阻碍我写出自己想要的真正高品质的应用程序。
2.5 如何写出好代码
专业人士常常会成为英雄人物,但是这样的荣誉并非是他们所刻意追求的。他们之所以成为英雄人物,是因为他们出色地完成了任务,不但按时,而且符合预算。而John却是一门心思想成为风云人物和救世主,从这点上看,他表现得并不专业。
成为英雄及“解决问题”的诱惑诚然巨大,只是我们要明白,牺牲专业原则以求全,并非问题的解决之道。舍弃这些原则,只会制造出更多的麻烦。
第3章 说“是”
3.1 承诺用语
你只能承诺自己能完全掌控的事。
如果你无法兑现承诺,那么最重要的就是尽早向你的承诺对象发出预警,越快越好,越早越好。
第4章 编码
能够感知到错误非常重要。对于一切事情莫不如此。具备“出错感知能力”,说明你已经能够非常迅速地获得反馈,能够更为快速地从错误中学习。要精熟掌握每项技艺,关键都是要具备“信心”和“出错感知”能力。
4.1 做好准备
如果感到疲劳或者心烦意乱,千万不要编码。
奉献精神和职业素养,更多意义上指要遵循纪律原则而非成为长时间工作的工作狂。
大脑里还有一个后台进程在运行。笔记:我时常感觉有的人和事一直在我大脑后台运行。
4.2 流态区
流态:一种意识高度专注但是思维视野却会收拢到狭窄的状态。问题在于,在流态状态下,你其实放弃了顾及全局。
4.3 阻塞
和别人一起工作,会发生一种生理上的变化。笔记:“男女搭配,干活不累”是有道理的。
“创造性输出”依赖于“创造性输入”。笔记:平时要广泛阅读,多元接受各种信息。
4.4 调试
出于某些原因,软件开发人员会认为调试时间并非编码时间。笔记:所以调试时间也是编码时间。
4.5 保持节奏
创造力和智力来自于大脑的高速运转,当你感到疲劳时,它们就不翼而飞了。
埋头忙于解决问题时,有时候可能会由于和问题贴得太近,无法看清楚所有的可选项。由于大脑中富有创造性的部分被紧张的专注力所抑制,你会错过很棒的解决方案。笔记:短暂地抽离出来,会更新思维,获得更大的解决问题的视角。
4.7帮助
要清楚团队伙伴的状态。如果有人看起来遇到了麻烦,就应该向他提供帮助。帮助别人所带来的显著影响一定会让你感到相当惊讶。给他们提供帮助并非说明你比人家聪明许多,而是因为你带来了一个新的视角,对于解决问题起到了显著的催化作用。
第5章 测试驱动开发
5.2 TDD的三项法则
(1)在编好失败单元测试之前,不要再编写任何产品代码。
(2)只要有一个单元测试失败了,就不要再写测试代码;无法通过编译也是一种失败情况。
(3)产品代码恰好能够让当前失败的单元测试成功通过即可,不要多写。
5.3 TDD的优势
事后写的测试只是一种防守。而先行编写的测试则是进攻,事后编写测试的作者已经受制于已有代码。
第6章 练习
6.3 自身经验的拓展
保持不落伍的一种方法是为开源项目贡献代码。
第7章 验收测试
7.1 需求的沟通
做业务的人和写程序的人都容易陷入一个陷阱,即过早进行精细化。业务方还没有启动项目,就要精确知道最后能得到什么;开发方还没有评估整个项目,就希望精确知道要交付什么。双方都贪求不现实的精确性,而且经常愿意花大价钱来追求这种精确。
7.2 验收测试
单元测试是程序员写给程序员的,它是正式的设计文档,描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。
验收测试是业务方写给业务方的。它们是正式的需求文档,描述了业务方认为系统应该如何运行。关心验收测试的是业务方和程序员。
第9章 时间管理
9.1 会议
关于会议,有两条真理:
(1)会议是必需的;
(2)会议浪费了大量时间。
凡是不能在5分钟内解决的争论,都不能靠辩论解决。争论之所以要花这么多时间,是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实,而是信念。
9.2 注意力点数
注意力是稀缺的资源,它类似魔力点数。如果你用光了自己的注意力点数,必须花一个小时或更多的时间做不需要注意力的事情,来补充它。笔记:人一天可以高效学习和工作的时间是有限的。
在你不集中注意力的时候,注意力点数可以缓慢恢复。
肌肉注意力有助于改善心智注意力,而且不仅仅是简单的恢复。我发现,定期训练肌肉注意力,可以提升心智注意力的上限。
9.5 死胡同
坑法则:如果你掉进了坑里,别挖。
第10章 预估
“是的,我觉得花的时间太多了,但是我知道你在努力解决这个问题,而且有切实的进展。这就是我们真正需要的。所以,我一点儿也不生气。”笔记:有努力,有进展,两个条件,缺一不可。
10.2 PERT(计划评审技术)
三元分析法:乐观预估,标称预估,悲观预估。
第11章 压力
我决心通过高质量的工作,而不是愚蠢的劳作来享受自己的职业生涯。
11.1 避免压力
在压力下保持冷静的最好方式,便是规避会导致压力的处境。
观察自己在危机时刻中的反应,就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律,就说明你确定相信那些纪律。反过来说,如果在危机中改变行为,就说明你并不真正相信常规行为中的原则。
第12章 协作
12.1 程序员与人
专业程序员最糟糕的表现是两耳不闻窗外事,只顾一头将自己埋在技术堆里,甚至连公司业务火烧眉毛行将崩溃了也不闻不问。你的工作职责就是要让业务免于陷入困顿,让公司可以长久发展下去。
12.2 小脑
也许你认为自己一个人工作时会做得更好。也许确实如此,但是这并不意味着你一个人工作时,整个团队会做得更好。
第13章 团队与项目
13.1 只是简单混合吗
有凝聚力的团队通常有大约12名成员:7名程序员、2名测试人员、2名分析师和1名项目经理。
分析师开发需求,为需求编写自动化验收测试。测试人员也会编写自动化验收测试,但是他们两者的视角是不同的。两者虽然都写需求,但是分析师关注业务价值,而测试人员关注正确性。分析师编写成功路径场景,测试人员要关心的是那些可能出错的地方,他们编写的是失败场景和边界场景。
项目经理跟踪项目团队的进度,确保团队成员理解项目时间表和优先级。
(完)
本文地址: 《代码整洁之道——程序员的职业素养》 读书摘记