永利集团娱乐官网大家也想成为一名

题图来自Pixabay

前年最后一周,我按安排把《The Clean Coder》读完了,大致100页左右。

不想成为特出程序员的码农,那和鲍鱼有何样分别?李清照有句诗:生当作人杰,死亦为鬼雄。可能我们不必、也说不定永远都不会是最精美的程序员,但大家起码可以变成一名职业的程序员。我们也想变成一名专业人员

第6章 练习

这一章的内容是专业人员怎么着刻意磨练。Bob大伯提到40年来她动用的处理器综合品质(内存硬盘体积和进程,显示分辨率的升高;提及能耗价格等的减弱)提高了10的22次方倍,不过实际总结机程序的真面目并不曾生成,是能够透过有些基础程序的勤学苦练来持续提拔本身的技术的。为了让22次方更形象,鲍勃三伯用了一个Jobs平时用的技能,把它转换成人可以了然的其余东西:是从那里到半人马座阿尔法星的偏离(以埃为单位),是1比索硬币里的电子数,是地球质量与个人质量的比重。

明天,编译不再要求程序员等待。未来依旧有点程序员必须等待构建,这是正剧,也是不够细致的征兆。方今,创设时间应该用秒来衡量,而不是分钟,更不是小时。

打造时间那样细节的问题体现了专业性,比如前段时间大家关怀化解的flex编译时间的题目,只是经过报名更好的机械就把全副项目标编译时间从90分钟缩减到20分钟,那应该是最方便的投资了。可是还没完成Bob岳父说的秒级创设的档次,这里还有更为进步的半空中,不过也必要有专业人士的投入才行,必要学习和品味下flex的增量编译框架fcsh和flex编译支持maven的工具flexmojos,或然会有救助。

对于陶冶形式,小编给出了两种形式,一些操演套路,能够尝试在商家里安排有关的教程。

Chapter 1. 专业主义

卡塔

在武术里,卡塔是一套设计好的、用来效仿打斗一方的招式。与之类似,编程卡塔也是一整套敲击键盘和鼠标的动作,用来效仿编程难题的缓解进度。联系着不是在缓解真正的题材,因为你早已驾驭了化解方案。相反,你是在演习解决那一个难题所须求的动作和表决。

编程卡塔的最后目的,也是逐步操练以高达炉火纯青。反复的演习会练习大脑和手指怎样动作和反应。在持续陶冶当众,你恐怕会发现动作的微小提升,恐怕化解难题效能的宽窄升级。

要学习热键和导航操作,以及测试驱动开发、持续集成之类的章程,找整套的卡塔来操练都是非常实用的。

鲍伯大叔给出了有些卡塔,参考网站http://codekata.pragprog.com,其中包括在《ASD》中给出的保龄球计分程序。今年后备教练训练营的TDD作业,我做的就是这个BowlingGame的程序。

当真的挑衅是把一个卡塔磨炼到炉火纯青,你可以窥见其中的节奏。要旗开马到那点可不便于。

用作一名“专业人员”,不仅仅是一种光荣,它越来越多的代表职分,正所谓欲戴王冠,必承其重。当项目中有某个“临时工”犯了错误,他大可不必承担义务,只须要摊摊手,说几句自作者安慰的话;假设是“职业”人员,你无法不为投机写的每一行代码负责,出了bug必须承受相应的权责。
“职业”的程序员也理应有友好的职业道德,鲍勃三伯把它包含为以下8点:

瓦萨

瓦萨基本得以说是几人的卡塔。其中的招式须要规范地记得,反复彩排。一个人负责攻,另一个人承担守。攻守双方交换时,各个动作要一而再、接二连三地一再。

程序员能够用一种叫“乒乓”的玩耍来开展类似的勤学苦练:多个人挑选一个卡塔,大概一个简练难点,一个人写单元测试,另一个人写程序通过单元测试,然后换成剧中人物。

随机练习

专擅陶冶就是不限制方式的搏击。模拟打斗与编程并不是特意贴合。可是,很多编程磨炼场中都会玩一种名叫“自由磨炼”的游艺。它很像由八个参与者消除难点的瓦萨,只是随意磨练是有广大人涉足的,而且规则是足以持续的。在随意练习中,屏幕被投影到墙上,一个人写测试,然后坐下来,另一个人写程序通过测试,再写下一个测试。桌子边的人一个个轮岗接下去,或许有趣味的人可以协调排队加入。无论怎么安插,都以可怜有意思的。

地方那二种格局,无一不是以TDD的不二法门展开,和上一章的始末符合。此外还有在业余时间插足开源社区,也是推荐的演习方法,总而言之,专业人士必要不停的勤学苦练。

好歹,专业人员都需求陶冶。他们这么做,是因为它们关怀本身能落成的最好结果。更要紧的是,他们用本身的岁月磨练,因为它们知道保持团结的技术不落后是上下一心的义务,而不是雇主的职责。锻练的时候你是赚不到钱的,不过训练过后,你会博得回报,而且是松动的回报。

  • 问询您的圈子
  • 咬牙上学
  • 练习
  • 合作
  • 辅导
  • 询问工作领域
  • 与雇主/客户保持一致
  • 谦逊

第7章  验收测试

鲍勃大爷举了一个和业务人士一起以持续探索的不二法门写应用程序的例证,并总计了部分经历。其实是再一回解说了高速的一些尺码,强调转变是听之任之会有些,过早精细化是不须求的,业务方本身很可能并不知道自身要如何。应对办法是推迟精细化,用验收测试驱动开发。验收测试要自动化。几年前测试团队做过有关的品尝,当时认为在验收自动化测试上投入有点高,没有继承开展下去,去年是还是不是可以再品尝一下,改变一下PO和BA的办事方式?

Chapter 2. Say No

验收测试和单元测试

验收测试是写给业务方看的,单元测试是写个程序员的,它们并不另行。它们的根本功能实在不是测试,测试只是隶属功用。它们首先是文档,其次才是测试。

生意的程序员敢于与实际斗争,敢于说“不”。尤达说过:“能就是能,无法就是无法。不要说‘试试看’”。若是某项任务你不能胜任,拒绝接受总比临近交付日期才告知产品经营你无法已毕好;同样的,若是不可以在某个时间内到位,就毫无说“试试看”。试试看意味着你会尝试着去达成,而一大半人都以乐观主义者,那样说一样于一种承诺。碍于情面的人大概觉得不妥,必要提议的是:“say
no”
并不代表拒绝合作,而且为了协会更好的开拓进取。

图形界面的测试

这里提到了充实ID和支行测试服务两种方法,都以先前曾经尝试过的,关键是要找到项目实在的落地。

Chapter 3. Say Yes

绵绵集成

此地关键涉及的是连连集成的纪律,集成失利必须登时修复,那是优先级最高的政工。实际做起来是须求公民意识上的转移的。

只要您以为“say no”让您很难为情,那么,“say
yes”
(做出承诺)也很有挑衅性。做出承诺包括了多个步骤:

第8章 测试策略

“QA应该找不到别的错误”,那是对专业人员的须求。QA的紧要职分不是意识程序员的错误,保证程序没有错误是程序员本人的天职。那QA做什么?

QA在公司中要扮演的是需求规约定义者(specifier)和特征描述者(characterizer)。

急需规约定义者:QA的义务是和业务人士一起开创自动化验收测试,作为系统真正的需要规约文档。

特点描述者:QA的另一项任务是规行矩步探索式测试的规则,描述系统运转中的实际情况,将之反映给开发人士和业务人士。在那项义务中,QA并从未解析要求,而是在辨明系统的实际处境。

  • 口头上说本身将会去做
  • 心里认真相比较做出的许诺
  • 真正付诸行动

自动化测试金字塔

标准开发人员服从测试驱动开发的要求来成立单元测试。专业开发集团拔取验收测试定义系统须要,使用持续集成保障质量逐步升高;同时,那么些测试又属于全局测试系统。拥有一套单元测试和验收测试的同时,还亟需有更高层次的测试,那样QA才找不出任何不当。

鲍勃小叔给出了五层的自动化测试金字塔,和大家平常来看的三层的金字塔不太雷同,从下到上依次是:单元测试、组件测试、集成测试、系统测试、人工探索式测试。

单元测试是程序员本身编写本身使用,并且要做到类似100%的覆盖率,日常在90%上述,并且是真实的覆盖率,而不是那种尽管能由此但并不关心运行结果的谬误的单元测试。

零件测试和集成测试都以对准API进行的测试。组件测试针对单个组件,集成测试针对几个零件。组件测试由QA和业务人士编写,开发人士提供救助。常用的工具是FitNesse,
JBehave,
Cucumber。针对GUI的是Selenium或Watir等工具。组件测试要覆盖几乎系统的一半,紧假设马到功成路径。格外路径是要靠单元测试来覆盖的。集成测试主要针对大型系统,是编排性测试,主要不是测试工作规则,而是测试组件装配在联名时是或不是和谐。集成测试一般由系统架构师或主设计师来编排,用于确认系统架构层面的结构是或不是正确无误。集成测试时间运作比较长,一般不会作为频频集成的一片段。

系统测试大约占测试的10%,由系统架构师和技术管事人编写,一般是在GUI层次。

人造探索性测试不是自动化测试,它需求选拔人类的创新能力,对系统进行深切钻研和研商。预先编写测试陈设反而会缩短那类测试的作用。可以考虑部分黎民百姓“抓虫”行动。覆盖率不是革命性测试的对象。

“职业的”程序员对协调做出的许诺会形成言必行,行必果,甚至承担相应的权责,职场上可不允许随便说说而已。

结论

TDD、验收测试那么些整合起来,最后目的依旧让QA找不到其它错误。

Chapter 4. 编码

第9章 时间管理

“职业的”程序员应该负有非凡的编码能力。代码要干净、符合规范,尤其是在赶进度的情况下。Bob伯伯在《Clean
Code》(《代码的干干净净之道》)中说到,一个妇耳鼻喉科医师不会因为日子紧急而答应伤者的央求——不要洗手就做手术,因为如此并不是事情的做法(更别说犯罪)。同样地,职业的程序员不会因为时间热切就写出混乱的代码或许上百行代码的函数,那样谈不上快,只会让进程尤其慢。整洁的代码也亟需从平日不停的教练养成,那上头的书有《The
Art of Readable Code》、Bob伯伯的《Clean Code》、《Code Complete》。

会议

有关会议,有两条真理:

(1)会议是必不可少的;

(2)会议浪费了汪洋时光。

平日,两条真理同时适用于同一场会议。有些与会者认为那两条总括得特别好,有些则以为它们是不错的废话。

你必要为自个儿的年月负责,所以您需要选拔如何会议到场什么会议不到位。Bob公公提到Scrum的四会的题材,相关内容应该可以参照Scrum相关书籍。

Chapter 5. 测试

争论/反对

Kent
Beck曾告知笔者一个深远的道理:“凡事无法在5分钟内化解的争执,都不大概靠辩论化解。”

若是冲突必须消除,就相应须求争持各方在5分钟时间内向大家摆明难点,然后大家投票。那样,整个会议花的日子不会超越15分钟。

鲍伯大爷的书有一个特点(尽管本身只看过两本…),他会在不留意中特地地插入测试方面的情节。看她的书都会对TDD有一定的摸底,此处略去n个字……
任凭是或不是选择TDD的不二法门,“职业的”程序员都必须具备自然的测试能力。最为开发人士,写的最多就是单元测试,固然单元测试不可以确保程序一定不出错,可是写好的单测是对自身代码负责的一种显示。若是代码没有测试过就签入代码库,无异于放进去一个定时炸弹。《Code
Complete》里面介绍了一部分主意,可以在写更少量的单测的处境下覆盖到越多的代码,例如结构化的底蕴测试。

注意力点数

未来是个争抢注意力的一代,每一个人最难得的资源就是注意力,哪个人抢到更加多的注意力就能扭亏。如何保持注意力?

第一需求保险睡眠。Bob叔伯每晚需求睡7钟头。年终有多少个月我曾经每晚睡5小时,想多争取些时间工作和学习,靠每一日早晨的咖啡来帮助,后来发现本身有点扛不住,就硬着头皮往7钟头睡眠靠了。前阵子听樊登讲《睡眠革命》,一个睡觉周期时间是1.5钟头,如果在上床周期中间被闹醒,则整天都会受影响,所以睡眠时间最好是1.5钟头的平头倍,一周累积睡到35个周期就没难点。正在品尝中,貌似挺有道理。

肌肉注意力。体力活动须求肌肉注意力,编程须要心智注意力,两者的必要不一致。不过定期陶冶肌肉注意力能够荣升心智注意力的上限。Bob岳父的做法是骑自行车1-2刻钟,大概30-50km,骑车的时候可以听播客或然音乐。小编本人挺喜欢慢跑的,周天的清晨慢跑听书是一种享受,也是一种放松。可是进入春日阴霾重了就没怎么跑了。可是在家里做些俯卧撑也挺有便宜。

Chapter 6. 预估

时刻拆分和西红柿工作法

西红柿工作法笔者用过一段时间,有时平时被封堵或然本人心灵没办法静下来;有时又以为25分钟时间好像有点短,专注的做一件工作时刚进入状态,番茄就身故了。看到局地作品说番茄时间设置成1小时比较好。可是根据鲍伯叔伯前边的传教,其实进入心流状态并不是很好。或然25分钟的番茄钟就是很不错的。

要避免的作为是事先级错乱,或许不按优先级依次来拍卖,那一个事情在本身身上也时常爆发,明明代楚有个工作是首要的,但连接拖到最终一刻才做,把温馨逼到死角,搞得很凌乱。

番茄时间也急需回看,感觉番茄工作法就是一个人的Scrum。小编对团结的回想就是对此每项工作的预估时间依然时常偏乐观,或者是因为本人有完美主义的赞同。那个和快速的思路并不太协作,造成本身效用不高,须求调动。

软件开发进度中最常出现的题材就是延期交付,因为速度延期往往导致开发人员须要连接的突击,甚至废寝忘餐的赶进程,而以此日子很多时候都以由于连串组过于乐观的预估。

穷途末路和泥潭

穷途末路:比如选拔了走不通的技术道路,越是坚定不移浪费的时刻越多。要记得,任哪一天候都有采纳。

坑法则:假设你掉进了坑里,别挖。

比死胡同更不佳的是泥潭。泥潭会减慢速度,但不会让您彻底停下来。但万一你使尽全力,你如故可以收获进展。

故此说泥潭比死胡同更麻烦,是因为在泥塘中,你仍然可以见到发展的征途,而且看起来总是比回头路要短(尽管事实上不是这么)。

那五个所以然一看就懂,能够什么分辨哪些是死胡同,哪些是泥潭,哪些是内需坚定不移挺过去的啊?感觉需求大智慧才行啊。

  • 时刻预估——安慕希分析法
    伊利分析法是1957年美利哥海军的潜艇极地航行布署中的一有的内容,是一种对预估的估算办法,这种技能简单而有效,把预估变成几率分布。你可以更具多个数字预估某项任务:

    • O:乐观预估。那是卓殊乐观的数字,约等于我们寻常说的最快时间,快到程序没有充足,开发进度中不会出岔。实际上,为了维持开朗预估有含义,这几个数字对应的可能率应当小于1%(正常分布下实际数字是3个西格玛可能0.13%)。
    • N:标称预估。那些数字几率最大。假如画一张柱状图,标称预估就是最高的丰裕。
    • P:悲观预估。那是最不佳的数字,因为它考虑到种种奇怪,比如沙尘暴啊,战争啊。为了保证这几个数字有含义,它的几率也相应小于1%。

    有了以上多个预估,大家得以如此描述可能率分布:
    μ = (O+4N+P)/ 6
    μ 是天职的梦想成功时间。
    σ = (P – O)/ 6
    σ
    是天职的可能率分布的标准差,用来衡量不鲜明。数字大就象征格外不确定。
    因而一项职分的预估时间就是 μ/σ 。

第10章 预估

预估是软件开发人士面对的最简单易行、也是最可怕的移位之一了。

Chapter 7. 压力

答应和预估

承诺是强烈的,必须要已毕,其余人会依照你的应允制定安顿。不大概达成的承诺是一种诈骗。

预估是一种猜测,预估错误非亲非故声誉。

本人记忆SteveMcConnell的《快捷软件开发》中有过描述,预估总是会交到多少个值,要么是一个区间范围,要么是一个值和几率,而承诺就只有一个值。不佳的是我们付出的多数预估都会被领导当成承诺,因为大家在预估时反复只交给一个值。

特意提一点,依照大家成功职务的时长绘制出直方图,大概上是切合韦伯分布的,而不是正态分布。从小编司的气量数据足以看看那或多或少。借使现身显然不适合韦伯分布的曲线,要么表明任务粒度差距相比大,要么表达那里存在分明的老大,要求关切一下。

常用的预估方法,都以PMBOK中的知识:三点法、DELPHI法等。安顿扑克就是一种DEPLHI法。

关于软件推测,McConnell专门写了一本书,可惜没投入时间精心读过。从经验来看,五人齐声拍脑袋做类比臆度是相比较可信赖的,在PMBOK中称之为专家判断。近年来业界的自由化应该是选拔效益点办法或快捷功效点办法,感觉其本质也是类比估量,然而是依照大数目标类比估计,最基本的东西是其积累的大队人马的品种数量音信。

书中有一段描述:

第11章 压力

不怕有压力,专业开发人士也会鲜为人知毅然。尽管压力持续叠加,他如故会服从所受的练习和纪律,他领略这个是他凭借克服由最终期限和承诺锁带来的压力感的最好法子。

本章前边讲述了Bob小叔自身承受压力以及她的答问方法。确实在她40年的软件生涯中,什么都碰着过了。有趣味就阅读原书吧。

你看见自个儿躺在一张手术台上,以为产科医务人员给您做开胸手术。医务卫生人员全力挽救你的人命,不过日子少于……
您期望医师的变现怎么样?你指望她冷静、鱼贯而来吗?你指望他知道准确地命令助手吗?你希望她从严按照当初陶冶时的做法遵从手术规程吗?
依旧想让她汗流浃背、咒骂之声持续?想让他乱扔手术器械、把东西摔的哐当响吗?想让她满腹怨气责怪管理人员设定的不具体的手术时间,一直嚷嚷时间不够用吧?你指望他彰显得像一名专业人员,依旧像大家常见的少数开发人士的那种做派?

维持干净

迅速升高确保最终时限的点子,便是维持整洁。专业人士不会为了快点前进而乱来。他们精通“快而脏”是自相争论的说教。脏乱只会促成急性!

基于经验和自个儿自身的知晓,如若工作三番五次在过渡中,能够找到下一位“接盘侠”,那么咱们在工作中保持专业性的或许就会大大下跌。此前本人维护的程序,作者领悟出了难题都要自个儿去消除,没有其余人可以依靠,所以为了让祥和维护和了解程序的承负轻一些,所以作者会把具有已知的题材都花时间清除掉,那样在遭受难题时小编就不会分心去考虑那些已知的题材。已知的题材概括编译器检查出的装有告警,要么通过修改代码消除掉隐患,要么本身要坚信明白了编译器告警的因由,并且明确那是无害的。事实讲明那些确实有效,作者很为自家以前维护过的程序的稳定性和代码质量自豪。

不错,那时自个儿还不驾驭Clean
Code和TDD,不然作者必然也在团结维护的代码中举行实施。

关于压力,最好的做法就是幸免压力:

风险中的纪律

考察自身在风险时刻中的反应,就足以精晓本人的自信心。即使在危害中仍然依据着您守持的纪律,就印证你真正相信那一个纪律。反过来说,借使在危害中改变行为,就认证您并不着实相信常规行为中的原则。

假如在非风险时刻你会循途守辙测试驱动开发的纪律,不过在风险时刻你放任了那种做法,就表达您并不确实相信TDD是有接济的。假若在平日时候你会小心保持代码整洁,但在危害时刻你却会冒出混乱的代码,就印证你并不确实相信混乱会导致速度下落。假使在危害时刻你会结对工作,但平时却不结对,就注明您相信结对工作比不结对更有效用。

鲍伯叔伯已经说得很清晰了,我完全赞同。意识不到混乱会导致速度降低,只怕是因为还一直不适用的胸襟方式让大家发现到这点。想起CMMI顾问魏先生曾经给过的一个提出:若果公司不为修复程序故障支付薪水,或许只开发一定比例的待遇,大概对大家的交给质量提高会有相比较大的促进功能。

  • 答应:不要随意做出承诺,承诺的时候也要科学地预估,防止超负荷乐观。
  • 保障整洁:快捷发展确保最中期限的章程就是维系清洁。专业人员不会为了快点儿乱来。“神速但脏乱”是自相争持的说法。
  • 危害中的纪律:鲍伯岳丈说过,观察本人在危害时刻中的反应就足以驾驭本身的信心。如果在风险中依旧依照你守持的纪律,就印证您确实相信这些纪律。选用这几个你在风险中如故会遵从的纪律规范,并且在所有工作中都服从那几个纪律。服从那么些纪律规范是幸免陷入危害的最好路子。

应对压力

1:不要慌乱;2:沟通;3:依靠你的纪律规范;4:寻求支援。

如果压力一度暴发,不可防止的,“职业”的做法是决不心惊胆落,而是从容不迫、努力追寻消除方案,同时寻求支援。

第12章 协作

程序员正是因为不擅长和人打交道,喜欢和机械打交道才选拔了这一个工作。鲍勃公公从程序员与雇主,程序员与程序员多个方面探讨了合营的题材,并且又是用自个儿亲身经历来说法。曾经她做过独行侠,忽略了雇主和商店利益,惨遭解雇的传说。那有些简约易懂,但很有警醒作用,值得读一下。

Chapter 8. 协作

第13章 团队与品类

大多数软件都是靠集体开发出来的,单打独斗与游离于协会之外都以不标准的突显。固然是Linus
Torvalds那种单兵应战能力超强的,也亟需一堆非凡程序员来扶持维护Linux。想象一下deadline到来以前您拼了命赶进程,恨不得多找几人来接济,那时候你是坚决的看重社团花费这些规则的。这为啥平日却不肯相信?
合作主要有两点:

有凝聚力的团队

形成公司必要时日。团队成员要求首先建立关联。他们需求上学怎么相互同盟,要求精通彼此的喜好、强项、弱项,最后,才能凝聚成公司。

有凝聚力的团社团真的有些神奇之处。他们力所能及共同创立奇迹。

有凝聚力的团伙经常有大体12名成员。由12私房组成的上佳团队,人员配备情状是这么的:7名程序员、2名测试人士、2名分析师和1名项目高管。

以此团伙规模不相符5-9人的标准化,可是或然平常我们是觉得分析师(BA)和项目老总(PM)是公司外的人手,算起来也基本上。那么些范畴几乎也是大家原先一个科室的范围,确实感觉到很不利。记得团队在解散的时候科室同事在铺子论坛上留下一个帖子:“钢七连要解散了,实名留念”。小编被外人称作“七少尉”(参考《士兵突击》),感觉这是自身十几年工作生涯中获取过的万丈褒奖。

集体和类型,何者为先?

精算围绕项目来营造团队是一种傻乎乎的做法。根据那种做法,团队永远都不可以形成凝聚力。

标准的成本团队会把项目分配给已形成凝聚力的团伙,而不会围绕着连串来组建集团。一个有凝聚力的团协会可以同时承载八个类型,依据成员分其余心愿、技能和能力来分配工作,会顺利完毕项目。

  • 与开发人员的同盟:那须求大家根据标准写好代码、注释和文档,便于其他程序员更快领会。这也须求程序员要有脍炙人口的表达能力和写作能力。JoelSpolsky在《软件杂谈录》中给统计机系学生的指出中,第一条就是:结束学业前练好写作。
  • 与雇主的通力合营:代码应该是为着工作服务,有的开发人士只晓得为了支付便民,随意的砍须要,只怕想出一些不切实际的想法。所以Joel的指出(3)是:结束学业前学好微观农学。

结论

团队比项目更难创设。因而,组建稳健的公司,让集体在一个又一个门类中完全移动共同工作是较好的做法。并且,团队也得以同时承载多少个档次。在组建团队时,要授予团队充足的时光,让他俩形成凝聚力,平素联手工作,成为持续交付项指标无敌引擎。

第14章 指导、学徒期与技能

那是全书的结尾一章(不算附录,附录说的是工具,和人非亲非故),Bob大爷用自个儿的成人经验做了个总括,表达了对院校规范教学的失望,认为高校的教育并没能教会学生编程,真正的编程是在工作中学习和推敲出来的。那一个真的是现状,或许在炎黄和米利坚都是相仿的气象,小编自认自身只是个中等水平的程序员,那一个力量水平也是在劳作以后读了一部分书做了一些执行之后得到的,刚结业的时候的确很渣。


Bob大爷是雪鸟会议的发起者,某种意义上说可以认为是高速宣言之父,他同时也是软件工艺运动的递进者,他用那本小书向大家解说了何为专业人员,以及怎样变成专业人员,为她的业内精神所折服,推荐程序员都读一读,然后不再自称“码农”。

很欣喜本身在两周内读完了一本书,并且这也是唯一一本作者写完了读后感的书,多谢鲍勃大伯的精简。

对了,其实还有最后的附录工具没有写,里面涉及了配置管理工具svn/git,代码编辑器IDE,持续集成工具,难题跟踪工具,自动化测试工具等,提供的都以最优异的选项,值得学习和参考。


自小编是有底线的

相关文章