《高效能程序员的修炼》阅读手记
书籍本身为Jeff Atwood博客的一些文章摘选，内容有技术相关但大部分是与技术无关，很多是作者日常工作的感悟。在阅读时候觉得内容有些零散，本着认真汲取前人经验教训的思想,在通读本书之后，回头认真作此记录。
书籍信息
- 作者: Jeff Atwood
- 出版社: 人民邮电出版社
- 版本: 2013年7月第1版
章/节小计
入门须知
-
你想成为一个程序员 软件开发的整个历程，就是程序员耗尽毕生精力去编写代码，以使其他人能从代码编写工作中解脱出来。程序员的终极目标是让自己失业 :)
当撰写出的程序交给用户手中，用户激动万分试用新功能的样子、将大量人工机械化工作替代的情形会让程序员统统加满自豪/成就/存在感。让我们，为这世界添砖加瓦。
-
程序员的八种境界 我想要你告诉我，不，是告诉全班同学，你究竟想过怎样的生活？！
总是信誓旦旦的向周围人道着自己长大后要成为程序员的理想、假装在写程序却在玩游戏、连程序能做什么都说不明白的小男孩。如今成了书中定义的倒数第一级别——烂程序员，你还想要什么！ “书中定义的倒数第二级别程序员”
-
如何培养写作习惯
- “通过清晰的注释和技术文档，让其他程序员能够读懂他们的代码，这也意味着其他程序员能够重用他们的代码而不必重新去写“。所写下的每一行代码都要发挥他的最大价值
- “书面沟通有助于理清我们的思路。当你要向其他人详细解释某样东西的时候，你会惊讶地发现自己的无知。于是，你不得不开始一个全新的探索过程” 前阵子一还在学习编程的朋友问我：“别人都说程序员要多写博客，是为什么？”，后期补充： “人容易偷懒，学东西总会觉得知道了就行且误以为自己真的知道了，写博客会让自己强行思考，总结与归纳。在知识不参透的情况下人是不会轻易表达出来的，人们会害怕暴露自己的无知。”
把一堆烂事搞定的艺术
- 学海无边
- “如果你想造一艘船，就不要催着工人们去收集木材，分派工作，发号施令，你应该教会他们的是对无边无际大海的渴望” —— Antoine de Saint-Exupery 因为我知道，你和我们一样，渴望着无边无际的大海。
- 多少程序员在做不会给他们带来任何经济收益的作业时会比做他们的本职工作更满足。
- 我们热爱编程
- 磨刀不误砍柴工
- 一路向前冲
- 快速迭代向更好，记得要快
- 关于多任务的神话 夏天的时候人们很容易因为飞来飞去又无法除去的苍蝇变的暴躁，一天过后回想一整天都做了些什么，除了纷扰的苍蝇与自己的暴躁好像确实就没什么了
高效编程之原则
- 第一条法则：永远都是你的错
- 公司有天有位客户前来造访抱怨施工业务的种种不良的地方，一个责任人则向客户一个一个的解释不良的原因是什么，有一些类似的对话：“墙面有的地方粉刷不均匀” “墙面不均匀是因为粉刷工没做好” “我房间有个开关居然都不通电” “那是因为水电班组的问题” “柜子还没装” “杂工那天请假了” 客户有些不耐烦了：“那粉刷工、杂工、水电班组不都是你们公司请的？” …… 同样的情况在软件开发上这些解释却听起来会合理很多：这个问题是因为那个第三方的问题，这一定是操作系统的原因，这估计是编译器的原因…… 但是这些绝对不应该是我们遇到问题的第一反应，要总是假定问题处在你的代码里并且根据这个假设采取行动：“嘿，这是我的错——让我把它弄个水落石出”
- 同时也想起前段时间阅读的《阿里巴巴java开发手册》中对关于NPE的问题的规约“本手册明确防止NPE是调用者的责任”也表达了同样的思想
- 大道至简
- 我们在编写代码时所作的每一个决定都是一个折中，我们想要的是一个实用而明智的策略，以缩减一个程序员在想要了解程序的工作原理时所需阅读的代码量。
- 从代码的简洁度开始然后再依据测试的结果按需去提升其它维度
- 代码简洁度
- 功能的完整性
- 执行速度
- 编码所花费的时间
- 健壮性
- 灵活性
- 避免写注释
- 代码编写中要将对代码中可命名的元素作最大的利用，给一个类、函数、变量起一个显而易见的名字。我们最终的追求应该是代码最大限度的自解释，而不是代码间堆满注释，注释的存在意义是讲解程序为什么这样做
- “为了让你的程序员同伴们更容易阅读和理解你的代码，你需要不断地改进你的代码，但如果你已经重写、重构甚至重新设计了很多遍——当你始终一筹莫展已经想不出任何办法让你的代码变得更浅显易懂，这时候，才应该在百般无奈之下加些注释来解释它们”
- “注释是旁白，它们有自身的价值，但却不能用来代替情节、人物和场景”
- 我深信当我要撰写一个api时，用户所关心的是该api将会造成的结果，所有对用户调用该api以达到结果的过程中的任何阻塞，都不应该存在。当用户想使用调用结果时，用户为什么要查阅我的注释以了解可能特殊的情况、前提条件、所需的执行顺序？我恨不得在撰写从集合中查找某个元素时没查找到的情况下都想要抛出一个checked exception，这样用户即可根据这个函数的命名、入参、返回值及必须要处理的异常即可知晓该函数的所有功能及可能发生的任何情况而无需进一步翻阅关于该函数的任何内容。（当然在编码过程中由于checked exception对代码可读及简洁的太大侵入性，对一些简单的功能一般还是用特殊值来代替结果:)
- 学会读源代码
- “很多时候你可以让其他人其他人在上游把问题修复；但是更多时候，你得自己动手解决”
- “不管文档上怎么说，源代码才是最终的事实，是你所能找到的最好的、最确定的、最新的‘文档’”，且该事实永远不会改变。 (相信大多开发人员会觉得文档的撰写与维护是一件麻烦事，谁又没遇到过阅读源代码的时候发现的注释与实际作用毫无相关性)
- “如果一个软件在我的机器上运行，那它就是我的软件。我要对它负责，我必须把它弄明白，从源代码开始构建是一条必须遵循的原则。我必须控制我的环境，我还要控制所有我依赖的东西”
- “在大多数情况下，菜鸟程序员认为漂亮的，往往止于肤浅；而他们认为丑陋的，往往是骇客大师们所写的经久考验的产品级代码”，何不多多学习
- 向橡皮鸭求助
提出问题的良好组织过程实际上促使我们自己诊断问题
- 我碰到一个问题
- 我决定把这个问题提到 Stack Overflow
- 我很笨拙的写下我的问题
- 我意识到这个问题根本说不通
- 我花了十五分钟重新思考该如何提出我的问题
- 我意识到我正在一个完全错误的方向上解决这个问题
- 我从头再来，然后很快就找到了解决方案
- 创新以人为本/执行更重要 说来容易，去执行吧，关注于构成你的应用程序的所有微小细节
- 你的团队能通过电梯测试吗
- 软件开发者认为他们的工作就是编写代码，其实不然。
- 在交付完整的解决方案的过程中，编写代码只是其中一环。编码本身并不是目的。
- 你团队里的每个人都应该能通过陌生人主持的“电梯测试”——在60秒内清晰地解释他们在做什么，以及为什么人们会在意他们正在做的事情
- 性能致胜
- “在一段长时间的开发过程中，你很容易就会忽略这里那里的几百毫秒延时，当你有一天回过头去看的时候，你会发现一次执行“反常”的花掉了太多时间。所以，一定要把软件性能的实时执行时间展示在可以很简单看到的地方，这个简单的做法迫使开发者去修正所有性能方面的退化与疏忽，随之，性能也变成了一种骄傲”
- “要么很快，要么已经死去”
招聘程序员须得其法
- 为什么程序员不会编程 作者讲解了200个应聘者其中199个不会写代码的悲伤故事 :(
- 怎样招聘程序员
“工作关系是你在有生之年每周都要花上40小时甚至更多时间的一种重要关系”
- 做一些简单的在线测试 有一些网站会提供相关的服务: Interview Zen, codility
- 看看他们的文件夹 查阅一下他在互联网上留下的蛛丝马迹：blog, github, stackoverflow, 微博, 推特？ 去理解应聘者所做过的东西，判断其擅长于不擅长什么
- 只雇佣认同公司文化的人 感觉工作态度也很重要，哪怕是认同公司文化，但是工作态度很差劲岂不是也很糟糕
- 进行一个电话面试 电话面试的目的不是聊天，而是要淘汰不合格的人
- 给他一个“试镜”项目 感觉这个测试在不知道应聘者是否有很大意愿加入公司的话好像不太合适 - - 不过这条方法的最后说利用雇佣合同的试用期也是可以的，它们在概念上非常相似
- 面谈，最后定夺 “让候选人对其专业领域作一段时间的演讲与展示” 大多数面试情况下时候都是让应聘者先做个自我介绍，然后就是面试官把握接下来的节奏了，想来也是，让应聘者对其工作内容专业领域等作下自我见解的演说就能直接看得出应聘者的主动思考能力、对所做事情是否有一定的热情、对专业领域是否有很好的认识、良好的沟通能力；而不是严肃的一问一答形式的尬聊
- 如何做好电话面试筛选 [本节作为参考，用于补足自身基础知识用途]
- 工作经验年数之神话 “软件开发者最擅长的就是学习，工作经验年数与编程技能之间是没有必然联系的。” 半年的工作经验的高效学习为什么不会比一年的经验用了五年更强？
- 与程序员面谈
30分钟时间里如何识别出有潜质的开发者？
此段作者引申了一些他人的建议，且在最后表示了自己最终的方法（已经在怎样招聘程序员中表述过）
“人的一生可能会做好多份工作。工作可以得到，也会失去，而永远留在我记忆力的是那些曾经与我共事过的’人’”
- 自我介绍
- 针对最近的项目提问
- 在一个专业技术领域深入试探 就像大厂们面试时的问道你答不上来位置 - -
- 让他们评论一件事情（或一样东西）
- 请他们解决一个问题
- 查看他们的代码
- 给他一段代码，问他是否满意
- 用难题来挑战他 (《编程之美》书籍已在手:)
- 询问他们看过什么书 觉得这个很重要，几乎可以知道开发者大多闲暇时间是用来王者荣耀或是不断提升自身能力
- 把他们招进来试用
- 史上最难的面试难题 与作者想法相同，面试过程太依赖谜题太冒险了。并且个人觉得太复杂太混淆目的性不强的谜题没有意义，除非你能够说服大多数旁观者你的谜题对于考察应聘者的某项能力真的是必须的且一针见血 （我做不出来大部分谜题:(
促使团队紧密协作
- 不管怎么说，那总是人的问题 项目的成败通常都是因为流程和人员的问题——你每天的工作方式；你的架构师、你的经历以及和你一起工作的编程团队成员；你是如何沟通的，最重要的是，当流程和人员出现问题时，你是如何解决他们的。让你陷入困境最快的方法你通常认为技术是决定性的因素，且你相信你能轻易解决其他方面的问题。但事实上技术之外方面的问题最可能让你止步不前。
- 领导须以身作则
最有效的一种技术领导就是以身作则
- 保持谦虚，总是先假定自己是错的，努力确保自己的观察结果是正确的
- 提出建设性批评时要小心。人们更容易接受非正式的建议和具有巧妙引导性的问题
- 要想赢得信誉与尊敬，最好的方法就是努力工作并且取得实实在在的成绩
- 百说不如一干。不只是单单声明这些主意是你想出来的，对自己新提出的内容付出实际行动，做好充分准备，虽不能保证团队对倡议一呼百应，但团队会意识到：你付出了努力，你在积极推动它，而不是试图捡便宜
- 结对编程与代码评审
- “对于代码评审，似乎没有人愿意花时间去真正理解那些并不简单的新代码，所以反馈通常是非常笼统的。当有人要在原有代码的基础上添加功能或者修改错误的时候，这是人们才会有很多的反馈(骂着别人写下的代码…)”
- “结对编程的优势就在于它的即时性，当负责复查的人就坐在你边上的时候，你是不可能忽略他的”
- “保证有超过一双眼睛在看你所写的代码”
- 会议是浪费时间的绝佳去处
努力使必须要开的为数不多的会议开得更有效率更有意义
- 会议绝不应该超过一个小时
- 每个会议都应该有一个清晰地目标声明
- 开会之前预先做好功课
- 会议变成可选项 每一个出现在会议上的人都应该是因为他们想要在那里，或者他们需要在那里。一个大家都想要参加的会议那一定因为它真的很有用
- 在会议结束时概括下待办事项
- 处理坏苹果&坏苹果是团队的毒药
- 当你积极地对项目宣战并以你的团队成员为敌时，你就成了项目的一个负担
- 团队的绩效可以从团队里最差的那位成员准确地预测出来
蝙蝠洞：程序员的高效工作场所
- 程序员的《权利法案》
- 每个程序员都应该有两台显示器
- 每个程序员都应该有一台快速的电脑
- 每个程序员都应该自己选择鼠标和键盘
- 每个程序员都应该有一把舒适的椅子
- 每个程序员都应该能快速接入互联网
- 每个程序员都应该有安静的工作环境
- 电脑工作站的人体工程学 抽空根据书中内容予以实验试试感觉，毕竟自己的余生大多还是与电脑打交道
- 购置优质的电脑椅 同样觉得椅子很重要，毕竟自己的余生大多还是与电脑打交道，顺便坐着椅子，但是暂时没条件用:(
- 多显示器能提高生产力吗 是的，请尽量
- 背景光的功效 对功效持怀疑态度，不过像作者说的那样：试试也无妨
设计时要把用户放在心上
- 你永远不会有足够的奶酪 你不太可能有足够的奶酪让人愿意去克服哪怕最微弱的电击
- 细节决定成败
程序是所有微小细节的集合
- 把最主要的功能做的基本正确
- 善于倾听用户的反馈，并且每天都在根据他们的反馈积极地改进产品的细节
- 用户界面代表了软件
- 用户界面须优先设计 在你草拟用户界面的时候，你必须置身于技术开发环境之外
- 分页显示该休矣
一旦你有了几千条信息，你要解决的不是分页问题，而是搜索和过滤的问题
在理想情况下，每次搜索都应该只返回用户最想要的那个结果
- 分页还是一种摩擦阻力。何不使用自动加载更多使用户想要向下读的时候移除下一页的点击阻力呢？ 书中还讲了一些对自动加载更多的体验优化
- 对待弱视的用户 想到自己有时候在冲着一个目标去的时候去浏览网站，真的是不管提示都全部忽略:) ，不过做了开发者之后大多时候还是会很认真的去读读文档、说明书~ 作为产品方也要汲取教训尽量将产品做得无限简单，必要的一些提示等内容用一种用户最容易看到的方式给用户展示，毕竟，他们唯一愿意看的地方也就是他们要看的地方了
- 再谈浏览器底栏 “底栏原则”虽已经不复存在，但是重要的内容让用户能够一眼看到或被吸引依然很重要 碰巧跟浏览器低栏齐平的生硬的水平线是阻止用户滚动页面的唯一因素，因为页面看起来已经完整呈现了 说到这一条，我现在在用的编辑器Typora的官方网站就有点这个问题，网站的底部边线与浏览器低栏对齐了(对的如此齐让人觉得还是故意的:)，且页面中部的logo还有个像是进度条的东西一直在跳动，让人误以为当前页面是一个等待页面，等加载出来之后还有内容一样
- 费茨定律与无限宽度
- 单元测试的终极失败 当用户搞不明白怎么去使用你的软件时，当用户抛开你的软件而选择了其他更易用或更简单的软件时，那便是单元测试的终极失败。那才是你应该想尽办法去解决的问题
- 第一版做的不好，但照样发布
- 在启动项目的时候，你憧憬着你的软件会成为软件工程历史上一座光彩夺目的丰碑。然后再开发周期结束的时候，你最终做出来的却只是那座丰碑的黯淡影子
- 你觉得，往开发计划中添加更多的时间，你就能在软件发布之前把它做的更好
- 其实，这个项目里很多很多东西都做砸了，且在用户看到项目之前，你不知道自己哪里做砸了 很喜欢作者在这里引申的Donald Rumsfeld的一首诗 我们知道， 有些事情是我们知道的。 那是些我们意识到自己知道的事。 我们也知道， 有些事是我们不知道的。 言下之意， 我们意识到自己在某些事上的无知， 然而这世上还有一种未知的无知， 那是些我们不知道的事， 但我们尚未意识到他们的存在。
- 即使第一版做得很差劲，也要坚持把它发布出去并且对用户的反馈快速做出响应
安全基础：保护用户数据
- 所有的网络通信都应该加密吗 是的，请务必 在没有包袱的情况下自己怎样无所谓，有了包袱，则必须保证包袱的安全，这是义务与责任，不可推卸
- 防范字典式攻击 一定要限制用户登录失败后重试的时间间隔或对其作着实有效的人机验证
- 快速哈希
- 如果你是一个用户，确保你的密码至少12位
- 如果你是一个开发者，想要用哈希来保密信息，只能考虑bcrypt或PBKDDF2
- 关于网络密码的可怕真相
- 不要多个网站使用相同的密码 其实自己本身也知道这个情况，只是还是觉得用不同的密码太麻烦，但是后来我觉得这么多需要授权认证的地方，又要使用不同的密码，这个事情好像不应该是人脑来记的，我需要一个外部的记录方法。以致于我现在的账户密码都是交给Lastpass来存储管理，每次注册账户的时候也是生成一个看起来像是乱码的安全密码(实际上自己并不知道密码是什么)
- 尽量使用可信任机构第三方登录功能进行一个网站服务的使用
加强代码测试，别让它太差劲
- 与客户患难与共
- 把开发人员带到客户的’战壕’里去是至关重要的，因为开发人员交付代码之后，客户才是真正与代码休戚与共的人
- “很多时候，软件开发者对他们的代码来说只是匆匆过客，代码是他们写的但是他们并不会像他们的客户那样经常性的去使用。虽说他们也会时不时的回头去看看，但他们缺乏用户的视角，也无法理解用户，而这些用户却要伴随着那个糟糕的软件度过他们的每一天” (最近我用开发的软件想着一个流程应该怎么做时，我们的用户居然直接就说你可以这样这样啊——完美达到目的的解决方案:)
- 让开发人员短期轮换着去做客户支持，奇迹就会出现
- 结交“混世魔猴” “混世魔猴”的工作就是捣蛋，它会随机杀死我们系统架构的组件或服务 想来这也是安卓开发中的monkey命令的功能吧:)
- 代码评审：说做就做
同级评审：软件交付物原作者以外的其他人帮忙检查缺陷、促进提升的一种活动，是提高软件质量最有效的工具之一
- 生产率提升(感觉应该是相对规模稍大的项目)，缺陷率降低
- 找到一位你尊敬的开发人员，然后留出专门的时间来做这件事
- 加大测试力度
- 在经过强有力的测试之前，不要相信你的代码不会出问题(好吧，虽然经过了强有力的测试我也不相信不会出问题:(
- 我同情那些不写单元测试的傻瓜
- 测试先行的12个具体理由
- 单元测试可以证明你的代码是否能真正解决问题
- 你可以获得一个底层模块的回归测试工具
- 你可以在不破坏现有功能的基础上持续改进设计
- 一边写单元测试一边写实现代码，这种工作方式很有趣
- 它们可以用来真实的展示开发进度
- 单元测试可以被用作示例代码
- 它逼着你在写代码之前做好计划
- 它可以降低bug修复的成本
- 单元测试甚至比代码审查的效果还要好
- 它实际上为程序员消除了工作上的障碍
- 单元测试可以催生更好的设计
- 它比不写单元测试而直接写代码的效率更高
- “任何时候当你想把某些信息打印到屏幕或输出给调试器，你都应该把它改写成一个单元测试”
- 其实正常编码过程中程序员都会在之后写一写代码进行测试，测试没问题之后即删除，所以其实撰写测试用例并不是一个新的无端增加劳动力的工作，而是把之前的测试代码规整规整加以良好的管理
- 测试先行的12个具体理由
- 单元测试与Beta测试的对比
- 单元测试难以划分优先级
- Beta测试理应比单元测试的优先级高
- 低保真的可用性测试 所有的代码层次的测试的目标都是测试程序是否符合预期 而可用性测试的测试目标则是测试程序在用户手中能否符合‘预期初衷’工作 (该测试的具体指导方法书中描述的很棒，实施时候可以作为参考)
- 比程序崩溃最糟糕的是什么
- 程序崩溃的各种场景
- 程序能正常工作，从不崩溃
- 程序在极少数情况下会崩溃，而这些情况几乎没人会碰到
- 程序在正常使用的情况下会时常崩溃
- 程序在正常使用的情况下会出现死锁并停止响应
- 程序动不动就崩溃，根本没法用
- 程序导致用户数据丢失，或者引起系统崩溃(不过个人感觉引起系统崩溃这个锅不该应用层程序背:)
- 我个人对程序崩溃的处理方式与书中引用的Jim Shore的描述想法一致 “有些人倾向于通过自动绕开问题来使软件表现的更加健壮。这也导致了软件会‘慢慢的死去’。在出现一个错误之后，程序还是能继续工作，但在后面会以一种诡异的方式再次失败。而在一个‘快速失败’的系统里，做法恰恰相反：当有问题出现时,立即以一种看得见的方式失败。‘快速失败’不是一种很直观、容易理解的技术——‘立即失败，并且让人看到’，听起来像是让软件变得更加脆弱，但实际上它能让软件更加健壮。这种做法使得问题很容易被发现，然后被修复，而在软件正式发布的时候bug会更少。”
- 当然从用户的角度来看，各种错误的对话框只会干扰他们做事情，致使他们烦心，既然如此，我们必须尽量两者兼顾
- 如果开发者能够安全的修复问题，那就为自己的程序负起责任来，不要把所有问题都直接抛给用户，而开发者却在一边逍遥自在，要积极为他们排忧解难(用户能看到的问题必须是最最最少的)
- 如果不能安全的修复问题，则要竭力保护用户数据。 如果程序崩溃与丢失数据选一个的话那肯定会是程序崩溃
- 程序崩溃的各种场景
创建并管理社区，同时从中受益
- 倾听社区的声音，但别被它们牵着鼻子走
- 大部分人在发现你的软件满足不了他们的需要时，都只是静静地走开，并且永远不会回头
- 90%社区反馈都是垃圾，但是还有10%的宝石
- 用户所云不一定为他们想要的
- 反馈与需求要根据自己的产品方向区分组为合理与不合理的，考虑做合理的，并给予”礼貌”的拒绝
- 除了用户所云，你还需要参考统计数据，数据永不会说假话
- 对合理的需求/反馈及数据挖掘出真正需求，然后给予‘优雅’的实现
- 游戏化
- 游戏化通过利用人们参与游戏的心理倾向来达到目的。所用的技术手段能够鼓励人们去做一些通常认为是很枯燥的杂物。声誉系统、战绩、身份、投票积分机制……
- 游戏是学习的助手 通过游戏这种方式引入要学习的知识怕是最轻松简单且印象深刻 每次看到小孩学会的东西都会想如果是我的话将这些抽象的知识教给他们是何其难，再看到他们老师领着他们将学习内容穿插到的游戏中，甚妙。生长至此，我们童心一直未变。
- 游戏促使人们齐心协力 没有什么与有共同的目标/敌人更能让人动力满满了
- 暂停，禁止，或者打入地狱 无论如何处置扰乱者，我们的目标只有一个，那就是：为所有人建立一个文明、理智、安全的在线社区
揭露营销技俩，以及如何规避
- 谨防九种营销诡计 作者：“老实说，除了软件本身之外，其他所有相关的商业行为总让我欲哭无泪。我只是想专心做一些很棒的东西，仅此而已”
- 网络广告该休矣 看看中国的广告……
- 从《偷天情缘》看A/B测试的问题
- 准备看一遍《偷天情缘》
- “A/B测试就像是砂纸，你可以用它来打磨一些细节到极致，但达不到创新的目的” 非产品稳定进入细节优化阶段不能过度看重/依赖A/B测试
- 如果流于俗套，请即刻改变 自己这么做是因为别人也这么做了？那别人为什么这么做？
- 软件定价：我们深谙其道吗 卖出去第二份软件，软件本身所需付出的成本为0
轻重缓急，了然于心
- 程序员，你幸福吗
“最难的是，你要搞明白你没日没夜的拼命工作到底是为了什么”
- 金钱能为你带来幸福
- 当你的收入超过了贫困线三倍多些的时候，金钱本身能给你的幸福只会这么多，不会再由着金钱的增多而幸福感再增多了
- 幸福是一种能力，就像你擅长一些东西不擅长一些东西 (当自己有钱的时候可以参考书中对如何花钱更能得到幸福的描述加以实验:)
- 赚钱不容易，幸福更是
- 来也匆匆，去也匆匆，到头来两手空空 “最难的是，你要搞明白你没日没夜的拼命工作到底是为了什么” “临终前，去史蒂夫·乔布斯对他在工作上倾注的毕生精力后悔了吗？”
相关描述内容
- 软件：RegexBuddy
- 电影：《偷天情缘》
- 电影：《Startup.com》
- 电影：《Code Rush》
作者推荐书目
个人在业余时间打算试着阅读的推荐的部分书籍
- 《代码大全 (第二版)》
- Steve McConnell
- 电子工业出版社
- 《人月神话》
- Frederick P. Brooks Jr.
- 清华大学出版社
- 《快速软件开发》
- Steve McConnell
- 电子工业出版社
- 《人件》
- Tom DeMarco / Timothy Lister
- 清华大学出版社
- 《GUI设计禁忌》
- Jeff Johnson
- 机械工业出版社
- 《编程珠玑》
- Jon Bentley
- 中国电力出版社
- 《程序员修炼之道：从小工到专家》
- Andrew Hunt / David Thomas
- 电子工业出版社
- 《精通正则表达式》
你的余生，多是与字符串打交道
- Jeffey E.F Friedl
- 电子工业出版社
读书本身总结
或许下次在看书的时候就作此种记录会比看完一遍后再来补交会更省时间，我需要一个能够良好作笔记与思考的办法，整天抱着电脑看书好像也不像话
