读书 on 冯威的博客

再读《人件》

Tue, 21 Oct 2025 18:08:48 +0800

最近有点忙，更新得不太规律。其实也是这个号的初衷，写我自己想写的，没有想写的，就继续沉淀沉淀。

《人件》这本书是汤姆·德马尔科（Tom DeMarco）和蒂莫西·利斯特（Timothy Lister）于 1987 年共同创作的，主要探讨了软件开发领域中的人际关系和组织文化问题。这本书凭借其深入浅出的观点和独特的见解，已经成为软件行业的经典之作。

最近重读了这本书，下面是一些记录。

项目失败不只是技术问题

我们很容易犯一个错误，就像书里提到的一个故事：

一个人在黑漆漆的街道上丢了钥匙，却跑到灯光明亮的地方去寻找，因为那里“更容易看清”。

在软件项目开发中，技术问题就是那片“灯光明亮”的地方。它们是具象的、有逻辑的，容易被发现的，也可以通过调试、重构来解决。

而人的问题，比如：沟通不畅、团队内耗、士气低落等却是模糊的，不太容易发现。所以，我们会下意识回避它们，而把重心转移到更容易看到的技术问题当中。

这种例子非常多：

需求分析和客户之间沟通不畅，导致最终交付的功能并非客户所需。
团队成员之间因为信息不对称，对同一个需求的理解天差地别，导致开发和测试之间天天扯皮。
上下级之间缺乏信任，很简单的任务分配，可能会牵扯到多部门、多层级的资源协调。

这些问题，都是隐性的成本，最终会让项目延期、甚至失败。我们必须将注意力从技术领域转向团队的成员状态、沟通质量上。

做什么样的管理者？

在传统的管理思维中，管理者是“踢屁股”的人，负责分派任务、监督进度。这种模式下，管理者负责思考和决策，员工负责执行。

然而，对于脑力劳动者而言，这种模式早已失灵。创造力、解决复杂问题的能力，无法通过“踢屁股”来激发。如果你把自己归为码农（每天重复做增删改查），那么不在此列。

《人件》提供了一个新的视角：管理的本质不是督促大家去工作，而是为他们创造一个可以顺利工作的环境。

管理者应该像一个“园丁”，他的职责是创造一片肥沃的土壤，提供充足的阳光和水分，然后让植物（团队成员）自然茁壮地成长。

管理者的核心工作应该是：

移除障碍：无论是流程上，还是环境中的干扰，只要是阻碍团队高效工作的，都应该是管理者优先解决的问题。
保护团队：保护团队免受不必要的会议、随意的需求变更和来自组织内部的部门墙的干扰。
提供支持：提供必要的资源、信息和培训，让团队成员能够不断成长。

书中提到了两种截然不同的管理哲学：“西班牙理论”和“英国理论”。

西班牙理论：将员工的工作时间视为可压榨的资源，通过不断施压、鼓励无偿加班来换取产出。这种理论的信奉者，痴迷于“忙碌”的表象，认为“996”是福报。
英国理论：强调“聪明地工作”而非“辛苦地工作”，鼓励员工创新方法、提高效率，将焦点放在成果而非工作时长上。

作为管理者，我们需要时常反思，自己更倾向于哪一种？如果我们只是在不断地施加压力，那么结果往往是“工作得更快，而不是更好”，还有可能让不好的事情慢慢发生。

环境不可忽视

我们应该都听过心流状态。这是一种完全沉浸、物我两忘的状态，在这种状态下，工作会比较高效。

《强风吹拂》里的阿走就多次在跑步时出现心流状态。

他的专注力，有如一根紧绷的丝线，来到濒临断裂前的张力极限；他紧张又高昂的情绪，就像水盛满土钵，再多加一滴就会溢出钵缘。阿走就是保持着这样的精神状态，心无旁骛地向前跑。

但进入心流状态不容易，至少 15 分钟不被打扰才有可能，任何小的打扰，比如：一个电话、一个微信消息、一封邮件、同事的一个问题等，都会让我们从这种状态中跳出来，再想要进入就变得非常困难。

之前看过很多帖子抱怨白天各种会议，到了晚上，才能真正专注写代码，于是不得不加班。这种表面上的忙碌，实际上是效率低下的表现。

作为管理者，应该给团队成员创造一个好的工作环境：

减少不必要的会议：如果有每日站会，控制在 15 分钟内，切记不要发散了。其他会议尽量集中安排。
设立专注时间：每天有固定的专注时间可以集中精力工作，这个时间段内，尽量不被打扰，有问题可以先收集记录，在非专注时间进行沟通。
优化办公环境：为团队提供安静的工作区域，减少噪音干扰。

构建高效团队

一个优秀的开发者固然重要，但一个具有凝聚力的高效团队是可以做到 1+1＞2 的。如何构建一个高效的团队，这是管理者应该关注和思考的。

书中给出的答案是：找到正确的人，并给予他们成长的土壤。

这里正确的人，不仅仅指技术能力强的人，技术能力强是硬技能，是能做好本职工作的必要条件。除了硬技能，软技能也同样重要。

一个沟通能力强、乐于分享、能将团队氛围变得融洽的成员，其价值可能远超一个技术大牛。他们是团队的“催化剂”，正是这种催化剂才能让 1+1＞2 。

下面是一些建议：

1、在面试过程中，考察候选人的沟通、协作和问题解决能力。多问一些“你如何处理冲突”之类的问题。

2、将培训、学习、技术分享视为投资，而不是成本。鼓励员工成长，为他们提供挑战性的工作。

3、确保团队有一个清晰、共同的目标（OKR），而不是一堆零散的任务列表（KPI）。当个人目标和团队目标一致时，每个人就会有自驱力，而不被动接收任务。

4、每个团队中都可能存在一些“超级催化剂”。他们或许不是代码写得最好的、最快的，但他们能让整个团队的沟通更顺畅，氛围更融洽，帮助新人快速融入。这些人的贡献是隐性的，但对团队的健康至关重要，管理者需要能够慧眼识珠。

5、好的工作体验总是伴随着一定的挑战性，没人愿意每天做重复的事情。一味地做没有难度的工作会让人懈怠，而持续的挑战和成功后的成就感，是团队保持活力的关键。

总结

忙碌不等于有有效的产出，代码写的多也不意味着贡献就大。

管理者不能只是埋头赶路，就像越野跑，当你发现前后都没有人时，不一定是跑得最快或最慢，也可能是跑错了方向。

作为管理者，我们需要时常抬头看路，审视我们的管理行为是否真的在为团队创造价值，还是仅仅在制造“无效的忙碌”。

读《华为项目管理之道》

Wed, 07 Aug 2024 08:11:47 +0800

在《软技能》一书中，提到将自己当作一个企业来思考，这其中的一个关键点就是要学会换位思考。做项目也是一样，需要换位思考，同时我们也能将很多事情都能理解为一个项目，例如：写系列文章、组织一次自驾游、产品开发等等，只不过这些项目的甲方可以是自己、家属、老板等。

读《强风吹拂》

Thu, 23 May 2024 08:42:19 +0800

《强风吹拂》是日本作家三浦紫苑创作的长篇小说。该小说讲述了宽政大学宿舍「竹青庄」的十名舍友凑成杂牌长跑队，在队长清濑灰二的魔鬼训练下，从零开始向日本历史最悠久的长跑接力赛「箱根驿传」挺进的故事。

读《笔记的方法》

Tue, 06 Feb 2024 17:31:07 +0800

《笔记的方法》这本书是比较意外获得的，2022 年年底，在小报童上购买了少楠和白光的知识专栏《知识资产》，2023 年年底，《知识资产》被重新编辑整理成书，在得到出版，之前专栏的订阅者，每人都能免费获得纸质书和该书的电子版，算是非常良心了。

读《快速阅读术》

Wed, 19 Jul 2023 08:28:16 +0800

1、我读书很慢，和这本书的作者一样，但这本书的作者现在能一天读一本，甚至是两本，让人很羡慕，所以我看了这本书，想学习下快速阅读的技巧。

五月读的四本书

Mon, 29 May 2023 14:21:44 +0800

我读书很慢，读书慢不是因为读的很认真仔细，而是读书太少，也就是阅读量不够，量不够，质就难以发生变化，跑步如此，读书也是。

读《持续架构实践》

Wed, 26 Apr 2023 11:56:13 +0800

之前看到过一种言论，说相比互联网产品，做 ToB 产品没有那么大的业务量，也没有那么多的用户量，所以非功能性的需求没那么重要，重要的还是业务。

读《认识AI》

Mon, 03 Apr 2023 11:38:15 +0800

1、最近 ChatGPT 越来越热，都已经到了马斯克等千人签署公开信，呼吁暂停开发更强大的AI系统，担心人工智能开发危及「文明控制权」，而我这个 AI 小白决定要系统性的学习下 AI 相关知识了。

读《沸腾十五年》

Thu, 09 Mar 2023 10:24:40 +0800

《沸腾十五年》记录了中国互联网行业从 1995 年到 2009 年的发展历程，深入探讨了互联网行业的商业模式、技术发展、市场竞争等方面的问题，讲述了一群热血青年使用技术改变世界的故事。

2022 年读过的书和 2023 年阅读规划

Mon, 16 Jan 2023 09:15:11 +0800

2022 年读的书不多，可以找到很多的理由，但我觉得根因还是没有养成一个好的读书习惯。年初制定了每月至少阅读两本非技术书籍的目标，看似非常容易，但到现在一回顾，发现差的很远。

读《李诞脱口秀工作手册》

Wed, 11 Jan 2023 09:35:00 +0800

这本书是 2023 年读完的第二本书，第一本是阿加莎的《无人生还》，2023 年的读书效率挺高，希望能延续下去。

读《阅读的方法》

Mon, 24 Oct 2022 08:41:03 +0800

关于阅读的方法，有一本著名的书《如何阅读一本书》，从阅读的层次、书籍的分类、不同类型书籍的阅读方法讲的非常清楚了。

本文要说的是今年罗胖出的《阅读的方法》，虽然书名叫阅读的方法，但书中却没有具体的方法，我觉得叫阅读的意义可能更合适。

书的作者是罗振宇，人称罗胖，得到创始人，最出名的是从 2015 年开始坚持每年举办「时间的朋友」跨年演讲，以及公众号每天早上 6 点准时推送 60 秒的语音内容。

这本书很容易读，我读书非常慢，一个周末也读完了。下面说说我的一些理解。

时隔六年，软技能第二版来了

Tue, 13 Sep 2022 08:20:20 +0800

《软技能》的第一版是 2016 年出版，当时读完这本书有种相见恨晚的感觉，随后便写了两篇读书笔记发布在博客中：

http://fwhyy.com/2016/10/reading-soft-skills-agile-personal-management/ http://fwhyy.com/2016/10/Reading-soft-skills-learning-to-improve-productivity/

读《纳瓦尔宝典》

Mon, 22 Aug 2022 08:20:20 +0800

最早是在量贩冰糖的播客听到介绍《纳瓦尔宝典》这本书，播主写了这本书的推荐序，另一篇推荐序是樊登写的，当时就想马上樊登读书应该会讲这本书了，果不其然，在我快看完的时候，樊登读书就推出了。

下面就看看这本书都讲了些什么。

读《华为数字化转型之道》

Mon, 08 Aug 2022 08:20:20 +0800

数字化转型应该很多人都听过，但如果你做过 ToB 软件，听得更多的是信息化，那信息化和数字化是什么关系呢？

下面用一个小例子来说说我的理解。

读《认知觉醒》

Mon, 04 Jul 2022 08:20:20 +0800

最近发的几篇文章是跟个人成长和工具相关，突然想起几个月前读的《认知觉醒》，这本书从内在和外在两个大的维度让我们在个人精进的道路上可以少走弯路。

后疫情时代，公司的活动少了，家庭的活动也少了，19 年后，没有自驾出过远门，每天家和公司两点一线，一天、一周、一个月过去，大脑没什么记忆点。日子像掉进了 for 循环一样，不断重复着，人就很容易产生疲态。

这本书可以给我们一些指引，让我们实际去做一些事情，丰富我们的生活。

书籍推荐（202204）

Sat, 30 Apr 2022 08:09:51 +0800

最近，疫情不太稳定，五一小长假也没有出行的计划，宅在家跑跑步，看看书也挺好。

前几天翻看相册，看到了一张 2019 年国庆期间在合肥附近一个古镇拍的照片，拥挤的小街上，人来人往，每个人脸上的表情都清晰可见，有点感慨，想想现在，口罩已经成为了出门的必备品。

读《底层逻辑》

Wed, 06 Apr 2022 08:18:13 +0800

《底层逻辑》本书作者是刘润，他在得到上开设有课程《5 分钟商学院》，我也是在得到上知道的这本书，这本书在豆瓣上的评分不是很高，褒贬不一，不过我看着觉得挺好。

书籍推荐（202202）

Thu, 31 Mar 2022 08:26:00 +0800

时间过得真快，三月就这样结束了，最后一天继续推荐几本书。

一直以来 C# 是我的主力编程语言，学习编程语言基本上看官方文档就够了，但下面这三本关于 C# 的书籍我还是强烈推荐阅读。

低风险发布，再读《持续交付2.0（增订版）》

Mon, 21 Mar 2022 08:26:00 +0800

两年前看了乔梁编写的《持续交付2.0》，收获颇多，还写了一篇读书笔记，今年 2 月，该书出了增订本，增加了一个章节的内容，其他的一些章节内容也有局部的优化。

书籍推荐（202202）

Mon, 28 Feb 2022 08:26:00 +0800

二月的最后一天，继续推荐十本书。

书籍推荐（202201）

Mon, 24 Jan 2022 08:05:00 +0800

这些年陆陆续续买了不少的书，虽然是买书如山倒，看书如抽丝，但买了总是有机会看的。2022 年计划每个月推荐 10 本书，这些书都是我买过或者在微信读书中看过，觉得还不错的。范围包括：

读《好好学习：个人知识管理精进指南》

Mon, 17 Jan 2022 08:05:00 +0800

关于学习的文章之前写过两篇：

《掌握好的学习方法，让你在职场更有竞争力》

《程序员是终身学习的职业，应该怎么学习？》

我们都是终身学习者，我深知学习的重要性，所以每隔一段时间，有些新的心得和想法，便会分享出来。最近看完了成甲的《好好学习：个人知识管理精进指南》，又有了些新的感悟，便有了此篇。

番茄工作法真的有用吗？

Mon, 11 Oct 2021 08:05:00 +0800

辅导小孩写作业总是一件让人崩溃的事情，暑假最后，给小孩在手机上安装了一个番茄钟 APP ，不知道是因为新鲜还是番茄钟本身的魔力，写作业的困扰解决了。

最近又翻了下《番茄工作法图解》，这是一本很小的册子，即便是我这种看书比较慢的也能在几个小时内看完。整本书在讲一种可以提高效率的做事的方法，可以总结成四个字，“专注，坚持”。而专注和坚持恰恰是小孩最难做到的。

有一个广为流传的一万小时理论说的是在某一个领域专注 10000 个小时，平均每天 3 小时，花10年的时间，你就可以成为这个领域的专家，其实说的也是专注和坚持。下面就看看番茄工作法是怎么样来提高我们的效率的。

几个术语

番茄钟：一个25分钟的时间段成为一个番茄钟，最初因为厨房的定时钟长的像番茄而得名，在一个番茄钟内需要专注做一件事情；

活动：指要完成的工作任务；

内部中断：在一个番茄钟内，来自自身的干扰，如想去刷刷微博，或者去看看新闻等；
外部中断：在一个番茄钟内，来自外界的干扰，如电话、邮件、被同事咨询问题等；
预估：对任务需要多少个番茄钟才能完成的判断。

工具

使用番茄工作法的工具很简单，一个番茄钟、一只笔、几张纸质表格即可、番茄钟用来计时用，纸和笔用来记录用，纸质表格分为下面三类：

活动清单
今日待办
记录

方法

每天开始从活动清单中挑选一些重要的活动作为今日待办，选择今日待办中最重要的活动，开启一个番茄钟，开始专注这项活动。番茄钟结束立即立即停止工作，停止前可以稍微整理下思路，然后休息3到5分钟，这个短暂的休息就是一个小的奖励，休息完后就可以进入下一个番茄钟。每一个番茄钟就像是一个小的目标，那个短暂的休息激励着你去完成一个一个的小的目标。

完成4个番茄钟后可以进行15到30分钟的长时间的休息。

番茄钟是不可分割的，如果你预估的一项活动需要多个番茄钟才能完成，需要将活动进行拆分成更小的活动。

一些疑问

怎样挑选今日待办？

活动清单中的活动太多，可以采用比较法来进行挑选，两两比较，如果今天只能做一件事情你会选哪件，最终胜出的优先级最高，以此类推，可以选择出今天的待办列表。

内部中断怎么办？

番茄工作法一再强调一次只做一件事，在一个番茄钟内需要高度专注当前活动，有临时的一些想法，可以先记录下来，再根据优先级在后面的番茄钟里去完成。克制自己时不时就去刷下微博的习惯，克制自己把注意力放到微信消息上，实在不行可以在番茄钟内将电脑任务栏隐藏或者关闭消息提醒。举一个简单的例子：

本来我在看一篇关于 C# 的技术博客；
被文章中的链接带到了一篇介绍 Git 的文章中；
在 Git 的文章中介绍了一个编程大牛的博客；
翻阅大牛的博客发现有很多感兴趣的文章，挑选一些进行翻阅；
我特么最初是想干什么来着，可能已经记不起来了。

上面是我经常会出现的问题，如果用番茄工作法，我应该在看到介绍 Git 链接的时候，将该链接保存下来，然后继续学习那篇关于 C# 的文章。

外部中断怎么办？

外部中断可能是一个很重要的电话；可能是领导突然叫你去谈一些事情；可能是一封不得不处理的邮件，当遇到这些不能推脱的打断的时候，必须停掉当前的番茄钟，回来之后重新开始一个新的番茄钟。

一个番茄钟没完成，活动已经完成怎么办？

番茄钟没结束，活动已经结束了，说明预估出现了误差，此时不应该马上去做下一个活动，可以进行一些过渡性学习，或者回顾一下该番茄钟内完成的活动。

一定要是25分钟吗？

为什么是25分钟，这个得问创始人了，书里强烈建议不管你是否觉得合适，先按照 25 分钟坚持一个星期再根据自己实际情况进行调整，先坚持一个星期目的是为了让我们养成一种习惯，只有在一段时间内去体验了，才会觉得合不合适。而不是根据自己的性子今天 10 分钟，明天 1 个小时。

我的思考

番茄工作法是一种时间管理的工具，如果您高度自律，您可能不需要。如果你在做事的时候会想去刷刷微博、看看邮件、聊聊微信，那么不妨试一试这种方法。

番茄工作法更适合一些个人事务，不是很适合程序员这种工作，程序员这种工作不确定性太多，外部中断太多，每天要做什么事情可能在上班后才会知道。

番茄工作法只是一种约束自己提高效率的工具，没有必要完全停留在形式上，做到“专注，坚持”就够了。

虽然有人说这本书是将一句话能说明白的事延伸写了一本书，但我觉得一本书能让我们读进去，并能带来一些帮助，就是有价值的。再回到题目，番茄工作法是否真的有用？相信你已经有答案了。

读《沟通的方法》

Mon, 27 Sep 2021 08:05:00 +0800

众所周知，沟通在工作和生活中是一项非常重要的技能，但很多人却用不好这项技能，最近中秋假期，看完了得到 CEO 脱不花写的《沟通的方法》，觉得很有收获。

最近看了两本低代码的书（文末有福利）

Mon, 23 Aug 2021 08:05:00 +0800

因为标题中「福利」进来的朋友直接拉到文章的最底部。

月初写了一篇《你真的了解低代码平台吗？》，介绍了下我对低代码产品的一些认识，随后有朋友送了我两本华章出版的关于低代码的书：明道云的《零代码实战》和微软的《实战低代码》，目前市面上也就这两本关于低代码的书。因为对低代码比较熟悉，所以很快就读完了。

读《中台架构与实现》

Mon, 24 May 2021 08:05:00 +0800

最早是在极客时间知道欧创新老师的，我也是他的课程《DDD实战课》的订阅者，后来欧老师基于这门课程做更多的实践与思考，完成了《中台架构与实现：基于 DDD 和微服务》这本书的写作，最近刚好读完了这本书。

读《精益商业思维》

Thu, 06 May 2021 08:05:00 +0800

五一假期读了程浩的《精益商业思维》，程浩是迅雷的联合创始人之一，现在是职业投资人，全篇从创业者的角度，也从投资人的角度解析了创业的方法论。

书中有大量的互联网公司的案例，都是我们耳熟能详的一些互联网企业，读起来非常顺畅，我读书很慢，但这本书在很短的时间内读完了，可见读书的速度不完全取决于读者，作者也是很关键的因素。

读《有效需求分析》

Mon, 22 Mar 2021 08:05:00 +0800

最近在一个技术群里看到张逸大佬强力推荐一本关于需求分析的书《有效需求分析》，于是在 Kindle 上下单了，读完后有一种相见恨晚的感觉。

重读《打造Facebook》

Mon, 02 Nov 2020 09:52:08 +0800

第一次看《打造Facebook》是在2013年，微博上的一位朋友推荐的，前几天又大概翻了一遍，全书主要讲作者王淮在 Facebook 的从业经历以及离职后对天使投资和创业的一些想法，作者的分享在很多地方是值得我们学习和借鉴的。

读《鞋狗》

Mon, 18 May 2020 11:53:11 +0800

最近读了耐克创始人菲尔·奈特 Phil Knight 的自传，读后感比较零散，所以使用刘韧体来写写了。

读《可复制的领导力》

Mon, 23 Dec 2019 22:56:03 +0800

最近很忙，是特别忙，连上厕所的时间都在回复着各种消息，但还是挤时间看完了《可复制的领导力》，这本书也是领导推荐的。

读《持续交付2.0》

Mon, 25 Nov 2019 23:52:54 +0800

几年前看过《持续交付(发布可靠软件的系统方法)》，感触不是很深，最近看了这本书的译者乔梁编写的《持续交付2.0》，结合工作中的种种，又有一种相见恨晚的感觉。可见好书是需要经常翻阅的，每次都会带来新的收获和思考。

书籍推荐：《C#7.0本质论》

Sun, 11 Aug 2019 07:05:47 +0800

在dotNet平台中有多种开发语言可以使用，C#无疑是其中应用得最为广泛的。学习一门编程语言最好的方式就是找一本好书系统地学习，我读过的关于C#的书籍中，我认为下面三本最为经典：

书籍推荐：《More Effective C#》

Mon, 24 Jun 2019 06:31:53 +0800

很多年前看过Bill Wagner的《Effective C#》第一版，涵盖了C#2.0相关语言特性的最佳实践，教我们怎样更优雅地去编写C#代码，当时觉得受益匪浅。最近拿到了《More Effective C#》第二版，目前看了大概三分之二，让我对C#的的应用有了更深入的了解，书虽没看完，但还是要推荐一下。

读《阿米巴经营》

Tue, 24 Jul 2018 07:02:33 +0800

《阿米巴经营》的作者稻盛和夫一生中创建了2家500强企业，并在70多岁高龄接管日航，扭转亏损的局面，是一位传奇人物。他根据自己的管理思想独创了阿米巴经营方式。《阿米巴经营》一书是他一生智慧的结晶。

阿米巴经营法总结一下有以下几点：

读《软技能》：自学提高生产力

Tue, 25 Oct 2016 22:29:32 +0800

《软技能》这本书内容较多，在读《软技能》：敏捷个人管理一文中主要谈的是个人管理方面的内容，本文将对怎样进行个人管理、怎样提高生产里进行一点思考。

读《软技能》：敏捷个人管理

Sat, 15 Oct 2016 22:53:26 +0800

《软技能》是一本写给技术人员的非技术类书籍，即使你不写代码，读读这本书也可以受益不少。书中涉猎甚广，甚至有理财、健身、心理等内容。读完这本书，有一种相见恨晚的感觉。

本书通篇在讲各个方面个人的成长，个人成长就需要自己对自己进行管理，敏捷的思想我认为核心就是快速迭代，用到个人身上就是要有很多的小目标，以迭代的方式向前进，最终实现大目标，这种方式可以让我们能快速试错，及时调整方向；也能让我们能快速看到一些成果，激励自己向前。

读《构建之法》

Fri, 10 Jul 2015 00:00:00 +0800

《构建之法》刚面市不就就买了纸质版，后来出了多看版后也第一时间购买了电子版。这也是第一本同时购买了纸板和电子版的技术书籍。周筠老师在微博上催过我几次书评，无奈年后一直忙于公司产品的研发，直到最近才看完，进度很缓慢。

读《番茄工作法图解》

Sun, 23 Mar 2014 00:00:00 +0800

《番茄工作法图解》是一本很小的册子，即便是我这种看书比较慢的也能在几个小时内看完。整本书在讲一种可以提高效率的做事的方法，可以总结成四个字，“专注，坚持”。有一个广为流传的一万小时理论说的是在某一个领域专注10000个小时，平均每天3小时，花10年的时间，你就可以成为这个领域的专家，其实说的也是专注和坚持。下面就看看番茄工作法是怎么样来提高我们的效率的。

几个术语

番茄钟：一个25分钟的时间段成为一个番茄钟，最初因为厨房的定时钟长的像番茄而得名，在一个番茄钟内需要专注做一件事情；

活动：指要完成的工作任务；

内部中断：在一个番茄钟内，来自自身的干扰，如想去刷刷微博，或者去看看新闻等；
外部中断：在一个番茄钟内，来自外界的干扰，如电话、邮件、被同事咨询问题等；
预估：对任务需要多少个番茄钟才能完成的判断。

工具

使用番茄工作法的工具很简单，一个番茄钟、一只笔、几张纸质表格即可、番茄钟用来计时用，纸和笔用来记录用，纸质表格分为下面三类：

活动清单
今日待办
记录

方法

完成4个番茄钟后可以进行15到30分钟的长时间的休息。

番茄钟是不可分割的，如果你预估的一项活动需要多个番茄钟才能完成，需要将活动进行拆分成更小的活动。

一些疑问

怎样挑选今日待办？

内部中断怎么办？

番茄工作法一再强调一次只做一件事，在一个番茄钟内需要高度专注当前活动，有临时的一些想法，可以先记录下来，再根据优先级在后面的番茄钟里去完成。克制自己时不时就去刷下微博的习惯，克制自己把注意力放到了不停闪烁的QQ图标上，实在不行可以再番茄钟内将任务栏隐藏。举一个简单的例子：

本来我在看一篇关于C#的技术博客；
被文章中的链接带到了一篇介绍Git的文章中；
在Git的文章中介绍了一个编程大牛的博客；
翻阅大牛的博客发现有很多感兴趣的文章，挑选一些一一翻阅；
我特么最初是想干什么来着，可能已经记不起来了。

上面是我经常会出现的问题，如果用番茄工作法，我应该在看到介绍Git链接的时候，将该链接保存下来，然后继续学习那篇关于C#的文章。

外部中断怎么办？

一个番茄钟没完成，活动已经完成怎么办？

一定要是25分钟吗？

为什么是25分钟，这个得问创始人了，书里强烈建议不管你是否觉得合适，先按照25分钟坚持一个星期再根据自己实际情况进行调整，先坚持一个星期目的是为了让我们养成一种习惯，只有在一段时间内去体验了，才会觉得合不合适。而不是根据自己的性子今天10分钟，明天1个小时。

我的思考

番茄工作法是一种时间管理的工具，如果您高度自律，您可能不需要。如果你和我一样，在做事的时候会去耍耍微博、看看邮件、聊聊QQ，那么不妨试一试这种方法；

番茄工作法更适合一些个人事务，不是很适合程序员这种工作，程序员这种工作不确定性太多，外部中断太多，每天要做什么事情可能在上班后才会知道；

番茄工作法只是一种约束自己提高效率的工具，没有必要完全停留在形式上，做到“专注，坚持”就够了。

读《打造FaceBook》

Wed, 27 Feb 2013 00:00:00 +0800

这本书是微博上的一位朋友推荐的，当天就下单购买了，花了几个晚上看完，全书主要讲作者在FaceBook的从业经历以及离职后对天使投资和创业的一些想法。下面是我看完本书后的一些感想。

团队合作

任何的团队都需要团队合作，其重要性毋庸置疑。我们在面试的时候经常被面试官考核的一个因素就是团队合作精神。我所经历的公司中虽然也很注重团队合作，但更多的是在一个团队中、一个开发小组中，而在脸书中将这个高度上升到了整个公司，所有人的目标都是整个公司的发展，一个团队中的老大如果觉得团队中一个牛人在另一个团队中会对公司更有帮助的话会不吝让那位牛人去另一个团队工作，所有人目标一致，劲往一处使，公司才有发展。记得我曾就职过的一家公司，项目组中成员之间够通非常好，成员和PM之间也保持者非常好的关系，但由于公司的一些绩效制度导致需求分析、开发和测试之间经常会为了一个Bug的责任人问题而争论不休，其是Bug早已修复，造成很大的内耗并且成员的情绪也会受到影响，所以说团队合作除了人员的性格和沟通能力外还需要公司有个好的制度支持。

黑客之道

黑客文化其实是对技术的一种追求，在脸书有一个称为黑客马拉松的活动，每三个月举行一次，在活动中所有人都放下手头的工作，根据自己的兴趣进行开发，很多创性的项目就是这样诞生的。当然这种类似的活动在国内公司中是很难举行的，大概有下面两个原因：

为了项目进度，老板们、领导们恨不得让员工一分钟当两分钟用，怎么可能利用上班时间让员工去做让他们看来对项目毫无意义的事；
脸书的招人很严格，他们有一个理念是拒绝和庸人在一起工作，所招之人都是世界上顶级工程师，而国内大部分公司的人员在水平上还是存在差距的，即便遇到一些开明的老板能举行这样的活动，其效果也可能没那么好。

工具文化

俗话说，工欲善其事，必先利其器，人类之所以比动物高级就是因为人会使用工具，好的工具会大大提高做事效率，脸书将工具文化做到极致，他们有专门的工具小组，工具小组中是公司中最好的工程师。这点不管是公司和个人都值得借鉴，我现在所在公司在工具这方面就做的很好，也有专门的工具小组，推出的很多工具给工作带来很多便利。去年下半年我写了一个小工具来给工作中重复切耗时的一些步骤提高方便并最终推广在部门内使用。在工作中要经常思考总结，找出重复的有共性的地方，看能不能工具化，让我们能有更多的时间去做更有意义的事情。

职业发展

作为一个技术人，职业的发展无非就两条路，管理和技术大牛，在国内的公司中很多人都有做管理的想法，即便是非常热爱技术的开发人员，因为做管理意味着更高的地位和更高的薪水，这是的很多热衷于技术的人会背弃自己的初衷，为生活所迫做着自己并不怎么喜欢的事情。在脸书管理和技术只是角色的不同，地位没有谁高谁低，喜欢技术可以成为技术大牛，薪水可能比管理着还高。记得前些年经常可以在网上看见对技术人员年龄以及未来发展的讨论，归根结底还是国内大环境造成的，我是一个很喜欢技术的人，希望有一天在国内软件公司中能出现更多的＂大龄＂一线开发人员。

知识储备

作为一个技术人员如果不持续地学习充电就会被淘汰，学习有两种，一种是学习自己感兴趣的技术知识，一种是学习和工作相关的知识。很多公司都会鼓励员工学习和工作相关的技能，而我认为工作需要的技能是基本的，除此之外还应该学习自己感兴趣的，前沿的的技术，说到这就不得不提英语了，即便不是在外企，至少也要做到阅读上没有障碍，英文能力直接关系到我们对新技术的了解和获取。记得我之前的一个领导在一次会上说你们在业余时间要好好学习业务、性能优化等和工作相关的知识，像英语之类没用的就没必要学了，对此我持保留意见。总之我们要尽量开阔自己的眼界，不断充电学习。王淮在书中提到他们会利用现成的开源框架去开发内部的工具，如果你没有足够的知识量你就不会之道有什么开源框架可以用，进而去自己动手开发，这样就导致重复造轮子。

书中还有对投资和创业的一些见解，因为我目前还涉及不到，在此不做评论。由于中西方文化差异较大，书中可以借鉴学习的我们可以吸收，不能借鉴的也可以丰富我们知识，成为日后的谈资。

《代码整洁之道》读书笔记(下)

Wed, 16 May 2012 00:00:00 +0800

全书一共400多页，一共17章，第十三章讲并发，并且在附录A中有对并发的补充，第十四到十六章是一些Java代码的案例，第十七章相当于一个总结。本次写读书笔记主要涵盖前十二章的内容，由于篇幅分为上下两篇。本篇为下，个别章节因为能力有限，没有完全弄懂，就先空着了。

第七章错误处理

错误处理简单来说就是当软件出现错误时还能正常工作。错误处理很重要，但不能打乱的原本的代码逻辑。

使用异常处理而非返回码，底层往上抛，最上层集中处理。这点在第三章函数中也提到过，之所以看到有的地方是使用错误返回码，是因为早期的一些语言没有异常处理机制。现在的语言基本都有异常处理机制。

异常的信息应该足够充分（包含出错的位置以及原因）。

不要在catch块中去实现业务逻辑，就是说当出现异常的时候一定要抛出，而不要改变状态或是做其他一些操作，这样会留下很多陷进。

底层的方法不要返回Null值，否则在调用时会添加很多的判断，可以抛出异常或返回特例对象，特例对象是指返回一个函数返回值类型的空对象。

不要传递Null值。

第八章边界

无

第九章单元测试

我工作以来所经历的公司中都很少使用单元测试，以致于我现在对单元测试这方面还不是特别熟悉，只是在自己的个人项目中写过一些单元测试的代码。在DotNet平台下可以使用VS自带的单元测试功能或是NUnit。

现在有一种编程的方法叫TDD（测试驱动开发），意思是先写单元测试，然后写对应的代码，通过修改调试让写的代码通过单元测试。使用TDD，会使测试覆盖所有的代码，测试代码和生产代码的比例有可能会达到1:1 ，所以也会带来成本的问题。TDD三定律：

在编写不能通过的单元测试前，不可以编写生产代码；
只有编写刚好无法通过的单元测试，不能编译也算不通过；
只可编写刚好足以通过当前失败测试的生产代码。

测试代码和生产代码一样的重要，也需要保持整洁。测试代码要随着生产代码的修改而修改，否则只会产生大量无用的测试代码，而且也会给生产代码的修改带来风险。

单元测试的好处：

有了测试不用担心对代码的修改；
有了测试可以毫无顾虑的去改进架构和设计；

整洁测试的三要素：可读性、可读性、可读性，测试中的可读性甚至比生成代码中的可读性还要重要。要做到高可读性，测试代码需要满足：明确、简洁和足够的表达力。

每个测试都可以拆分为三个环节：构造测试数据、操作测试数据、检验操作是否达到预期结果。

双重标准：指的是在测试环境中和生产环境中有些条件不必完全一致。生产环境中有时要考虑内存、cpu等性能问题，而在测试环境中不必做这些限制。

每个测试一个断言，不必完全纠结，但单个测试断言数应该最小化。

每个测试函数只测试一个概念，还是单一职责的问题。

整洁的测试代码要满足“FIRST”原则

快速（Fast）：测试运行应该够快，如果运行很慢就不会想频繁去运行它，就会导致不能及时发现问题。
独立（Independent）：测试应相互独立，某个测试不应成为下个测试的设定条件，应该可以单独运行每个测试。测试如果相互依赖，会导致一连串的测试失败，查找问题比较困难。
可重复（Repeatable）：可以在任何环境中重复通过。
自足验证（Self-Validating）：测试应该有布尔值输出，无论是成功还是失败。
及时（Timely）测试应及时编写，单元测试应该在使其通过的生产代码编写之前编写。按这种要求及时TDD开发了，但在实际工作中并不是总能遇到TDD开发的团队。

第十章类

类通常由变量、属性和方法组成。按照书中所讲的Java的约定，类应该由一组变量开始，如果有静态公共常量，应该放在前面，然后是私有静态变量和私有实体变量。公共函数跟在变量之后，一些供公共函数调用的私有工具函数在公共函数之后。

和函数一样，类也应该要尽可能的短小。但和函数不同不是以代码行数来权衡，而是以职责。如果无法准确的为某个类命名，则有可能是该类的职责过多。

单一职责原则（SRP）：类或模块应该有且只有一条加以修改的理由。

在实际的工作中很多开发人员往往不会思考这么多，他们只想着让代码可以工作就可以了，所以经常出现几千行的大类。系统应该是有许多短小的类而不是少量巨大的类组成。每个小类有单一的职责，只有一个修改的原因，所有这些小类在一起协同工作完成系统的功能。

高内聚：如果一个类中每个变量都被每个方法所使用，则该类有最大的内聚性。

保持内聚性得到许多短小的类。

上面说到每个类应该有单一职责，就是说类之间应该低耦合，但类的内部应该是高内聚的。如果一个类中的每个变量被每个类使用，则该类具有最大的内聚性。内聚性高说明变量和方法相互关联形成一个逻辑整体。

重构函数也会促使类职责的分离，看下面场景：

将一个有许多变量的大函数拆分成小函数，如果拆出来的代码使用了其中4个变量，那么就会将这4个变量作为参数传入到小函数中，如果使用的变量越多，就意味着小函数的参数越多，这时可以讲这4个变量升级成实体变量，小函数就不需要参数了，可以直接使用这些变量。这样就使内聚性变低，因为类中有很多的变量只为少数的函数服务，这时就可以将这些变量和函数拆分出来，单独成类。

开放闭合原则（OCP）

依赖倒置原则（DIP）

第十一章系统

这一章主要讲的是怎样在较高的层级–系统层级来保持整洁。

将系统构造和使用分开：软件系统应该将启始过程和启始过程之后的运行时逻辑分离开，在启动过程中构建应用对象，也会存在相互缠结的依赖关系。

本章提到的一些技术概念，下面提供一些参考学习链接：

工厂模式

http://blog.fwhyy.com/2009/11/design-patterns-notes-3-abstract-factory-pattern/

依赖注入（DI）

控制反转（IOC）

http://www.cnblogs.com/leoo2sk/archive/2009/06/17/1504693.html

扩容：不可能一开始就把系统做对，实现好当前客户的需求，然后重构，扩容来实现新的客户需求。

软件系统与物理系统可以类比。他们的架构都可以递增式增长，只要我们持续将关注面恰当的切分。

AOP

http://www.cnblogs.com/zhugenqiang/archive/2008/07/27/1252761.html

第十二章迭进

Kent Beck关于简单设计的四条规则

1 运行所有测试

不可测试的系统是不可验证的，不可验证就不应该部署；
只要系统是可测试的，就会导向保持类的短小和单一的职责；
紧耦合的代码是难以编写测试的，所以编写测试越多，就会导致使用依赖注入、面向接口编程等来使代码解耦。

2 不可重复

3 表达程序员的意图

选好的变量名、函数名和类名；
要记住，下一个阅读你代码的很可能就是你自己；
添加适当的注释。

4 尽可能减少类和方法的数量

重构

上面的2-4点都可以通过重构的方法来达到；
重构的目的：提升内聚、降低耦合、切分关注面（AOP）、模块化系统性关注面、缩小函数和类的尺寸、选取好的名称等；
好的函数、好的类、好的系统是重构出来的，没有人能一开始就把事情做对；
重构应该要及时，发现了坏味道要及时重构，当然这个需要测试来做保障。

《代码整洁之道》读书笔记(上)

Sun, 13 May 2012 00:00:00 +0800

全书一共400多页，一共17章，第十三章讲并发，并且在附录A中有对并发的补充，第十四到十六章是一些Java代码的案例，第十七章相当于一个总结。本次写读书笔记主要涵盖前十二章的内容，由于篇幅分为上下两篇。

第一章整洁代码

代码的质量非常重要，糟糕的代码有可能会毁了一个公司。对于一个很注重代码质量的人来说呆在一个只关注交付而不关注代码质量的公司是很痛苦的。

什么是整洁的代码，不同的人又不同的定义。我认为整洁的代码应该是符合所使用语言代码规范的；可复用的；便于维护的；简洁的。

糟糕的代码想做太多的事情，意图混乱；整洁的代码的每个函数、类和模块都全神贯注一件事，不受周围的干扰。

“破窗理论”：指的是窗户破损了的建筑让人觉得似乎无人照管，于是别人也不关心，任由窗户继续破损，最终自己也参与破坏活动，在墙上涂鸦，任垃圾堆积，一扇破损的窗户让该建筑走向了倾颓的道路。在程序中也是一样，一处出现了有坏味道的代码，有可能导致整个项目的代码都满目疮痍。所以到嗅到代码有坏味道的时候就要重构，我认为整洁的代码是重构出来的。

美国“童子军军规”中有条说道“让一地比你来时更干净”，映射到我们编码中就是我们每日在提交代码的时候要确保代码时整洁的，否则就进行重构。好的代码是靠大家一点点积累出来的。问题发现的越早，修改的成本就越少。

第二章有意义的命名

本章主要介绍在程序中命名的规范，命名随处可见，变量、函数、类、模块、命名空间等都需要有好的命名。一个名称如果能让阅读者一看就知道要表达的意思，就可以认为是一个好的名称。

不要使用单个字母来做变量名，时间一长，自己都不清楚自己当初的命名是什么意思。小方法体，如循环中的计数器除外。

不要使用有误导性的字母作为变量名，比如小写字母l和大写字母O，因为他们和数字的一和零很像，有的字体还比较好区分，但大多数字体很难分辨。

“匈牙利命名法（HN）”：该命名法是一位叫 Charles Simonyi 的匈牙利程序员发明的，后来他在微软呆了几年，于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。在当时那个时代编译器并不做类型检查，程序员需要使用HN来帮助自己记住类型。现在的一些高级静态编程语言具有更丰富的类型系统，编译器可以很好的做类型检查，所以使用NH纯属多余。使用NH的几个弊端：

增加了名称的长度；
使名称变得不可读，而在本章的2.5小节有强调要使用可以读得出来的名称；
增加了修改名称的难度，修改了变量的类型，变量名就要随着修改，否则会造成误导。

本章中讲到对接口的命名不要使用“I”作为前缀，这点我持保留意见，可能因为我一直是从事的Net上的开发，DotNet的类库中的接口基本都是使用“I”作为前缀的，而且在《NET 设计规范》一书中也强调接口要使用“I”作为前缀。

类名使用名词或是名词短语，而不应当使用动词。

对于方法名做到每个概念一个词，应该保持一致，比如对于绑定数据的方法，不要有的地方用BindData，而另一些地方使用DataBind 。

最后想说的是命名除了一些通用的法则外，对于一些规范性的问题还是要遵循所使用语言或平台规定或是约定俗成的惯例。比如方法名C#中推荐使用Passcal风格，而在Java中则是使用Camel风格。

第三章函数

函数一直都被要求要短小，有不少书中都以行数来作为标准，比如一个行数在20行以内被称为小函数，或是要在5行以内才是小函数。以行数来要求似乎有些苛刻，有一些极端的情况，比如初始化一个Model，里面有几十个字段，这时这个初始化函数中就有几十行代码，而且是无法拆分的，所以我认为，函数只要是在做一件事情就可以了。通常来说如果函数只做一件事，自然就不会很长。我对函数长度的极限是横竖都不要超过一屏。

函数应该只做一件事，判断函数时候只做一件事，看函数中是否很能够拆分，如果可以，就果断进行重构。

当函数中有Swicth语句的时候，就不可避免的要做多件事情了，而且函数会随着Switch条件的增加会越来越长。因为函数中做了多件事情，违反了SRP原则，因为随着增加条件我们要去修改这个函数，违反了OCP原则。这个问题可以通过工厂模式来解决。

函数的名称要使用描述性的名称，让人一看名称就知道该函数是做什么的。当函数只做一件事情的时候，取名就容易多了。还有比较重要的一点，风格要保持一致。

函数的参数要尽可能的少，书中要求是最好不要超过3个参数，当超过的时候就要将参数提取为一个对象，但实际中很难做到，通常都是为了省事，但有N多参数的函数会给阅读者带来障碍，特别是当参数名还词不达意的时候。

在一个函数中不要去调用职责之外的另外的函数，尤其是底层的函数，否则给高层调用带来风险。举个简单的例子：比如在用户登录的时候我们可能会有一个CheckPassword的方法来验证登录的用户名和密码，如果在CheckPassword函数中在验证成功后调用Session.Init()来对Session进行初始化，就会存在隐患。根据名称来看只是检查密码用，如果有人在非登录的情况下调用了该方法，会更改当前会话。

使用异常代替错误返回码，如果使用错误返回码会要求立即处理错误，当在高层调用很多底层方法时，每个方法都要去根据错误返回码进行处理，会造成函数逻辑混乱，如果使用异常处理则只需要在catch中处理即可。

远离重复，拒绝重复，方法有很多，抽象到基类或放到底层公共类库中。

没有人能一次性就将函数写的很完美，好的函数是通过重构得到的。

第四章注释

注释是一把双刃剑，好的注释能够给我们好的指导，不好的注释只会将我们误导。注释是弥补代码子表述不足的一种手段，就像设计模式是用来弥补语言不足一样。

代码是我们获取信息的准确来源，注释随着项目人员的更替反复的修改最终可能词不达意了，因为很多开发人员在整合代码，修改方法的时候并不是总是同步修改注释。

有时候看到一个函数的代码写的很糟糕，逻辑很混乱，有开发人员可能想，给这个函数加上几行注释，这样有可能起到适得其反的作用，这时要做的是将函数整理干净。

代码即注释，很多书和大师都这么讲，意思是我们要用代码本身来解释我们的意图，那就要求我们要控制好函数只做一件事，函数名和变量名要规范和可读。

当然也不是所有的注释都没有用，像下面几种类型的注释是有必要的：

具有警示性的注释；
描述一些负责业务场景；
有些函数现在还是一个空壳，但在将来可能有用，有必要写。

当我们不得不写一些注释的时候，要确保言简意赅，能够很好的表达意思，不要造成误解，也不要写多余的废话。

还有一种日志被称为日志式注释，一般出现在一个类的开始部分，记录每次修改时的时间、人员名称和修改内容。随着时间的推移这类注释会变得非常冗长。这类注释在一些项目中很普遍，而且有时会被严格要求写，但书中强调现在的源代码都会有源代码工具来进行管理，修改记录在源代码工具中有保存，这种日志式的注释应该全部删除。

有的开发人员喜欢在注释中签上自己的名字，这种做法也没没有必要，因为我们有源码管理工具。

项目代码中经常会出现被注释掉的代码，这对后面的维护人员会造成困扰，也会使代码变得混乱，这种代码同样可以删掉，因为我们有源码管理工具。

第五章格式

代码并非可以工作就了事了，还要有良好的代码格式规范，开发人员在维护代码的时候经常会埋怨别人的代码写的很烂，如果不严格要求自己，以后就会成为别人眼中的“别人”了。

代码格式规范，我认为首先要保证和当前使用的语言、平台保持一致，再就是整个团队中要保持一致。当公司项目的代码规范和使用语言、平台的规范有冲突时尽量说服团队和语言、平台保持一致，实在不行只能和项目组保持一致，像我现在所做的项目由于一些原因还在使用匈牙利命名法，虽然这让我很郁闷，但我还是和他们保持一致。如果是一个新项目则可以团队成员在一起来讨论制定代码规范。

合理使用空白行，同一类的有关联的放在一起。

变量申明尽可能靠近使用的地方。

实体变量放在类的顶部，因为设计良好的类，实体变量会被大多数的方法使用。

相关函数（一个函数调用了另一个函数）放在一起，也包括的重载的函数。

一行代码的宽度：120字符之内，最好不要拖动横向滚动条。

横向空格，比如一个表达式中的符号左边和右边与符号之间加空格，这个在VS中的代码格式化会自动帮我们做了。

缩进，只有一行的也按缩进规则来。

第六章对象和数据结构

暂略

读书 on 冯威的博客

再读《人件》

项目失败不只是技术问题

做什么样的管理者？

环境不可忽视

构建高效团队

总结

读《华为项目管理之道》

读《强风吹拂》

读《笔记的方法》

读《快速阅读术》

五月读的四本书

读《持续架构实践》

读《认识AI》

读《沸腾十五年》

2022 年读过的书和 2023 年阅读规划

读《李诞脱口秀工作手册》

读《阅读的方法》

时隔六年，软技能第二版来了

读《纳瓦尔宝典》

读《华为数字化转型之道》

读《认知觉醒》

书籍推荐（202204）

读《底层逻辑》

书籍推荐（202202）

低风险发布，再读《持续交付2.0（增订版）》

书籍推荐（202202）

书籍推荐（202201）

读《好好学习：个人知识管理精进指南》

番茄工作法真的有用吗？

几个术语

工具

方法

一些疑问

怎样挑选今日待办？

内部中断怎么办？

外部中断怎么办？

一定要是25分钟吗？

我的思考

读《沟通的方法》

最近看了两本低代码的书（文末有福利）

读《中台架构与实现》

读《精益商业思维》

读《有效需求分析》

重读《打造Facebook》

读《鞋狗》

读《可复制的领导力》

读《持续交付2.0》

书籍推荐：《C#7.0本质论》

书籍推荐：《More Effective C#》

读《阿米巴经营》

读《软技能》：自学提高生产力

读《软技能》：敏捷个人管理

读《构建之法》

读《番茄工作法图解》

几个术语

工具

方法

一些疑问

怎样挑选今日待办？

内部中断怎么办？

外部中断怎么办？

一定要是25分钟吗？

我的思考

读《打造FaceBook》

团队合作

黑客之道

工具文化

职业发展

知识储备

《代码整洁之道》读书笔记(下)

第七章 错误处理

第八章 边界

第九章 单元测试

第十章 类

第十一章 系统

工厂模式

第十二章 迭进

1 运行所有测试

2 不可重复

第七章错误处理

第八章边界

第九章单元测试

第十章类

第十一章系统

第十二章迭进

第一章整洁代码

第二章有意义的命名

第三章函数

第四章注释

第五章格式

第六章对象和数据结构