思考 on 冯威的博客

万维钢思维100讲的7个概念

Sun, 10 May 2026 12:35:00 +0800

看万维钢《现代思维工具 100 讲》的开篇，发现提到了几个概念。这些概念横跨了决策、心理、物理、统计多个领域，却能解释绝大多数复杂问题的本质。

于是用 ChatGPT 给每个概念配了个图。

1. 古德哈特定律

简单说就是：当一个指标本身变成了目标，它就不再是一个好指标了。

比如公司原本用「打卡率」衡量员工产出，当公司把「全勤」直接当考核目标，大家为了打卡而打卡，反而不会关注实际工作成果，这个指标就失效了。

2. 自我决定理论

这是一个动机心理学理论，核心是：人天生有三种内在心理需求，满足这些需求才能真正维持长期的动机和幸福感：

自主感：能自己掌控做事情的节奏和方式
胜任感：能感受到自己在这件事上能力成长
关联感：能和他人产生联结、获得归属感
用这个理论说，比外在的金钱奖励更能驱动人做好一件事的，是满足这三个内在需求。

3. WOOP

这是一套经过验证的「愿望实现四步法」，是四个单词的缩写：

W（Wish）：明确你想要实现的愿望
O（Outcome）：想象愿望实现后最好的结果是什么
O（Obstacle）：直面你实现愿望路上，会遇到的最核心障碍
P（Plan）：提前制定计划：「如果障碍 X 出现，我就用行动 Y 应对它」
比单纯「幻想成功」更有效，它把乐观想象和务实应对结合在了一起。

4. 自由能

这个词最早来自物理学，现在在人工智能、认知科学里用得越来越多，核心思路是：所有复杂系统（包括人脑、生命）都会主动做一件事——减少「意外」，也就是最小化「自由能」（自由能可以理解成「你想不到的不确定性」）。
换句话说：我们会不断调整自己的行为和认知，让世界尽量符合我们的预期，减少不确定性带来的「惊讶」。现在很多 AI 模型、脑科学理论都用这个思路解释智能的本质。

5. 对称性破缺

原本物理里的概念，现在经常用来解释复杂系统的演化：当系统原本是对称均匀的状态，遇到微小的扰动，平衡就会被打破，分化出不一样的结构。
举个通俗例子：一锅温度均匀的水加热，原本各处都一样，当温度到临界点，一点点随机波动就会让气泡冒出来，原本对称的状态被打破，产生了有序的对流结构。放到社会领域，比如互联网一开始大家都做门户网站，后来某个商家先做了电商，整个行业就分化出了不同赛道，就是对称性破缺。

6. 多臂老虎机

这是决策论里的经典问题，用来解决「探索 vs 利用」的平衡：
你面前有好多台老虎机（多个选项），每台的中奖概率不一样，你不知道哪台概率更高——你是一直选你之前赢过的那台（利用已知经验），还是去试没玩过的老虎机（探索新可能），怎么选才能让总收益最大？
现实里很多选择都是这个问题：找工作，你是一直做你熟悉的工作，还是去试新的领域？谈恋爱，你是继续和现在的人相处，还是去认识新的人？这个框架就是帮你做最优平衡的。

7. 布里尔分数

这是用来衡量「概率预测准确性」的打分方法，简单说：它会算你给出的预测概率和真实结果之间的差距，分数越低，预测越准。
比如你说明天下雨的概率是 80%，结果真下雨了，你的布里尔分数就低；如果说明天下雨概率 10%，结果下雨了，你的分数就高（预测不准）。现在做风险评估、气象预报、AI 预测都会用这个指标来评判预测模型好不好用。

2025 年终总结

Tue, 17 Feb 2026 02:16:00 +0800

岁月匆匆，华章日新，今年春节比较晚，现在 26 年都已经过了快 2 个月了。还是来对 2025 年做下总结吧。

整体感觉就是快，时间过得很快，AI 的发展速度也非常快。

怎么应对 AI 时代

从年初的 DeepSeek R1 到现在的 Agent Skills，几乎隔几天就会有新的模型、工具、应用出现。最近爆火的 Seedance 2.0 也在豆包移动端上线了。

我在手机上打开豆包，却不知道要做什么视频，因为我没有任何视频制作的经验。

所以说 AI 工具是在放大专业者的能力，而对菜鸟来说，只能是找点乐子的玩具。

[[AI 时代其实对人的要求更高了]]

放假前，在公司组织了一场 AI 技术应用分享。几乎所有人都用过 AI 相关的工具，但使用程度各有不同，对新技术和工具的了解和使用只是少部分人。很多人还停留在让 AI 协助排错的阶段。

AI 时代，持续学习显得尤为重要，持续关注、持续实践。

近一年也写了不少跟 AI 相关的文章：

[[理性看待 Manus]]
[[12个问题深入理解DeepSeek（含开源周内容）]]
[[在Windsurf中使用李继刚提示词]]
[[MCP 和 Function Calling：概念]]
[[MCP 和 Function Calling：示例]]
[[生成式AI 在 B端软件中实践的思考]]
[[A2A 介绍：概念篇]]
[[如何构建多智能体系统？]]
[[AI 时代，低代码该如何演进？]]
[[Agent Skills 全景指南：从概念机制到实战开发]]

成长

个人成长对我而言，是信息的获取到内化的闭环：输入阶段保持开放，消化阶段保持批判，内化阶段保持实践。

信息的获取源有：公众号、小红书、小报童、读库、得到、X、语鲸、Folo 。

语鲸和 Folo 是聚合工具，可以快速浏览，如果需要看原文的讨论，也能方便跳转过去。Get 笔记是最近比较喜欢使用的一款工具，支持公众号、抖音、小红书、B 站、小宇宙的链接分析。他们自己家的得到 APP 更是可以无缝同步。

[[我为什么喜欢用Get笔记了？]]

输出工具还是使用 Obsidian，而且用的更深入了，最近也准备写一篇 Obsidian 常用插件的使用。在没有找到合适插件的时候，也可以借助 AI 的能力自己写一个插件。

[[插件开发：实现Obsidian同步到墨问笔记]]
[[插件开发：实现 Obsidian 同步到 hexo]]

在 [[2024 年终总结]] 中我提到在 25 年要慢下来，注重消化。我自认为做的还是不错的。比如说我在看一些知识类的视频或书籍时，会选择在电脑端开着笔记工具去看，边看边记录，避免走马观花，觉得自己会了。

2026 年 1 月看了马伯庸和脱不花的长谈，学到了一个习惯：写日记。

这种记录日记的方式，只记录事实，不发表评论，希望 2026 年可以坚持下去，等到年末回顾的时候应该挺有意思的。

跑步

2025 年比赛历程：

3 月，仙桃半马跑到了 133 ，得益于赛道的平坦和天气的给力，425 的平均配速，平时可是连 10 公里都跑不到
4 月，云丘山越野赛 50 公里组别，虽然跑的慢，还是安全完赛
12 月，杭州隆 6 越野赛，42 公里组别，因为赶车而退赛

[[天气和赛道的加持，仙桃半马 PB 9分钟]]

警惕效率的陷阱

Wed, 26 Nov 2025 15:49:00 +0800

企业谈降本增效，个人也是一样，不断尝试各类效率工具。即便是教育小孩，也是希望用最少的焦虑、最短的时间，换来好的结果。总之，就是要高效。

现在层出不穷的大模型和琳琅满目的 AI 工具，其目的也是为了效率的最大化。

关注效率的同时，也需要警惕一些效率陷阱。

忙碌替代产出。

常见现象是为了找一个好用的笔记工具，可以花大量的时间查资料、看评测。但笔记却没有写多少。同类的事情还有囤积电子书、各类资料。主打一个收藏了即看了的效果。

看似一直在忙碌，却没有产出。

就拿记录这个事情来说吧，家里领导就做的很好，先找个工具用着，过程中发现有些需求没有满足，再去寻找新的工具。

目的是产出内容，工具只是辅助。

把指标当目标。

说到指标，就会想到 KPI，很多公司都有 KPI 考核，比如对程序员会有工作量、Bug 量、是否延期等指标。

如果指标不是为了更好实现目标，而是将指标当成了目标，那么这个 KPI 就是失败的。

英国经济学家查尔斯·古德哈特提出了一个古德哈特定律：“当一个指标被设定为目标时，它就不再是一个好的指标。”

比如，如果对程序员只考核工作量，程序员把工作量当成自己的目标，那就会无视代码质量、无视项目进度，只要自己工作量达标即可。

优先级错乱。

四象限法将事情分为：重要紧急、重要不紧急、不重要紧急、不重要不紧急四类。目的就是让我们做事前想想优先级，这样效率更高。

有个项目经理每天应付客户的各种事情，非常忙。负责的项目从测试发布到生产需要用到同步工具，使用过程中，发现同步工具存在很多的问题，这个项目经理就手动进行发布，要多花几倍的时间。

后来同步工具修好了，需要在客户的测试环境中验证，项目经理觉得自己很忙，没时间做这个事情，依然手动同步，耗费大量时间。

有时候忙，并不是真的忙。

忽略协作成本。

在一个组织里要做成一件事，必然会涉及各个部门的协作。如果部门之间各自为政，沟通和协作不顺畅，就会存在 “部门墙”。

这种沟通和协作成本是隐性的，不容易被看见，但最终会体现到结果上。

有一个竖井效应说的就是这个事：

竖井效应指的是公司内的各个职能团队各自为政，每个团队都很高效，但从全局的视角去看却不一定是高效的。

埋头苦干，缺少思考。

当项目的交付时间提前了、或遇到困难了，第一反应是：我们要更努力了、要抓紧时间了、需要加班加点了，而不是停下来分析问题的根源、重新评估方法和策略是否有效。

这就是用战术上的勤奋，掩盖战略上的懒惰。就像在迷宫里找出口，选择了拼命快跑，而不是想办法找到地图。

其实停下来分析、思考，有些事情是可以延后处理，甚至是不处理。

AI 时代，低代码该如何演进？

Tue, 04 Nov 2025 14:49:45 +0800

在数字化转型的浪潮中，低代码平台与人工智能（AI）的结合正成为企业软件发展的关键趋势。

低代码平台以其快速开发、交付等特性，正在改变企业应用的开发方式，而 AI 把企业从 “流程数字化” 推进到 “决策智能化” 。这两者一定可以碰撞出不少的火花。

本文探讨低代码与 AI 融合的方式。

低代码和 AI 有两种方式可以结合

方式一：在低代码平台中使用 AI，把 AI 能力沉淀到平台内部，提升用户体验和效率。
方式二：在 AI 中使用低代码，将平台的核心能力封装成细颗粒度工具，成为大模型与智能体的“手脚”。

这两种方式并非二选一，而是相互增强，根据客户的业务场景进行取舍和选择。

方式一：低代码中使用 AI

低代码的优势是可以快速交付项目，结合 AI ，可以让构建出来的业务系统具备 AI 能力，在低代码平台中 AI 能力了可以通过组件或插件的形式存在。

下面列举几种常见的场景。

企业级智能问答

RAG 现在在企业中使用已经非常成熟了，RAG 中有一个关键点是将内容进行向量化，供用户提问时使用。

低代码平台中天然就有很多的数据：

低代码平台可以搭建各种业务功能，随着用户的使用，业务数据就会累加，可以在平台中根据配置选择性将业务数据纳入到知识问答的范围。
低代码平台中的文件列表，在用户上传文件时，可以对文档内容进行读取和向量化。
在使用低代码平台构建应用时，数据库表的创建是根据平台中的数据模型进行转换的，数据模型就是一份数据库表的元数据。

至于前端的问答对话框的呈现就比较灵活了，可以是单独一个页面、可以放到首页，也可以放到某个功能模块中，针对具体的业务进行提问。

审批流 AI 节点

企业将线下的审批搬到线上，为的就是能提高效率。某些审批环节，如果能使用 AI 加持，就能更进一步。

比如：员工报销流程，财务会对上传的发票和报销金额进行审核，当一个报销单的发票比较多时，人工核对会非常麻烦。

结合 AI ，可以在低代码平台的流程引擎中提供一个 AI 辅助审批节点，发起人提交后，将票据传给 AI ，AI 进行金额的识别和汇总，并根据规则配置和报销金额进行比对，发现问题直接驳回给发起人。

报表多轮对话

我们现在给企业客户开发软件的过程中，根据客户的业务需求，会提供很多的报表，有些是专业的报表工具、有些通过视图关联多表查询出结果展示。

但这些随着需求的确定，功能就固化下来了。客户在使用的过程中只能通过条件进行筛选。

结合 AI ，用户可以在现有报表数据的基础之上进行二次提问，结果以文字、表格、图表的方式提供，让报表变得更加灵活。

文档解析

企业中有很多不同类型的文档和单据，比如：合同、发票等。可以在低代码平台中添加文档识别组件。

利用文档识别组件，可以构建一个专门用来管理票据的功能。
合同管理中在文档识别组件中上传，识别合同基本信息，一键将识别的信息填写到表单中。

除了基本信息，甚至可自动识别文档中的关键节点，如合同中的付款信息与时间等，并同步至低代码构建的事务跟踪系统，显著减少人工查阅与录入的工作量。

方式二：在 AI 中使用低代码平台

AI 只有具备了生产能力，才能真正帮到我们。怎么才能具备生产能力呢？就是使用工具。

我们和大模型进行对话，大模型理解了我们的意图，还能调用工具去进行实现，才是有用的。低代码平台中有各类引擎（表单、规则、视图、流程等），这些引擎的能力可以进行拆解和重组，以 MCP 工具的形式提供给大模型。

场景一

用户指令：创建一个员工信息管理应用，包含姓名、工号、部门和入职日期的表单，以及一个可以搜索和分页的表格。

工具调用：大模型理解意图后，调用低代码平台的 API，自动创建数据模型、生成对应的表单页面和列表页面，并配置好基本的数据绑定。

场景二

用户指令：任务管理中创建任务后，给任务负责人发送一个企业微信通知。

工具调用：大模型理解意图后，分析需要调用的工具集，先调用低代码平台的 API，创建一个用于发企业微信消息的业务流。然后调用 API 将任务创建后的事件和业务流进行绑定。

场景三

用户指令：检查一下我们所有低代码应用的运行健康状况。

工具调用：大模型理解意图后，调用平台的监控API，获取应用错误日志、性能指标（如响应时间）、资源使用情况等，并生成摘要报告。

最后

网上都说，AI 的到来最终会转向无代码，不过从目前来看，让 AI 自己去实现一个复杂系统，还是比较困难，特别是多轮对话后，幻觉比较明显。

低代码平台天生就是构建应用的利器，而且是有规则的，这个规则相比较编程语言，范围更小，更容易被 AI 所理解。

所以，在 AI 无代码变成这条路上，低代码平台如果能转变为底层支撑的工具，将会继续存在。

未来，随着模型能力的持续进化与平台工具的日益精进，人机协同的开发新模式将成为企业数字化转型的核心竞争力。

生成式AI 在 B端软件中实践的思考

Tue, 10 Jun 2025 05:34:00 +0800

我一直认为 C 端软件和 AI 的结合会更顺畅一些，例如，笔记工具“墨问”最近推出了 MCP 功能，允许我在各种客户端中与 AI 交互，并将结果通过 MCP 保存至其中。

这是因为大部分情况下，C 端对准确性的容忍度更高。

B 端软件则不同，其对准确性要求极高，尤其在金融、医疗等行业。本文简单谈谈关于生成式 AI 在 B 端软件中实践的一些思考。

AI 在 B 端软件中的一些场景

1、结合 RPA（机器人流程自动化）、自然语言处理（NLP）、机器学习等 AI 技术，自动化处理重复性高、规则明确的业务流程。

2、利用 AI 进行数据挖掘、模式识别和趋势预测，为企业战略制定、市场定位、风险管理等提供数据驱动的决策依据。

3、对模型进行微调，将法律、医疗等专业领域的知识进行训练，得到垂直领域的专有小模型，为上层应用提供精准的数据支持。

4、RAG 场景，主要用在智能知识问答、智能客服等。

AI 在 B 端软件中的局限

在 AI 应用的场景中，有一部分是生成式 AI。什么是生成式 AI？

生成式 AI 是一种能够创造新内容的人工智能技术。它通过学习海量数据（如文本、图片、音频），掌握其中的规律和模式，然后能够生成全新的、原创的内容。比如 ChatGPT 可以写文章、回答问题，DALL-E 可以根据描述画图，Sora 可以生成视频。

可以看出，生成式 AI 有以下特点：

1、输出具有不确定性。

2、输出结果的质量依赖模型的能力。

而企业应用对确定性要求非常高，比如：统计团队成员的绩效数据、统计销售部门的销售额、统计某些区域的疫苗接种情况等等，这些数据如果出现错误，影响会很大。

B 端软件除了特定的业务系统外，还有一类是平台级产品，我们的零代码产品就属于这一类。

这一类产品通常给技术人员或业务人员使用，让他们能通过平台能力来构建最终的业务系统，如果有 AI 加持，可以提升构建的效率。有一些 SaaS 的零代码产品，可以通过一句话描述生成一个应用。

但仅凭一句话描述生成的应用，往往难以达到实际生产环境的使用标准。因此需要反复进行优化和调整，这个调整的过程会受到模型上下文长度的影响。

此外，生成式 AI 的“幻觉”问题，即模型生成不准确或虚假的信息，仍然是一个未被完全解决的挑战。这种不确定性在高风险领域尤为突出，可能导致错误的决策和操作。

一个对话框就能搞定所有吗？

在生成式 AI 的实践中，无论是 RAG 产品，或是一些编程辅助工具，都是提供一个对话框和用户进行交互。

但仅靠一个对话框搞不定 B 端软件。

我们在使用系统时，跟 AI 进行对话，AI 的具体运作方式和结果的产生过程，对我们而言如同一个黑盒。

这会带来一种不安全感。

所以，一个系统的构建，从 0 到 1 会有很多的中间步骤，这些中间步骤也需要通过可视化的方式清晰呈现，关键步骤需要让用户来进行确认。

而不是直接后台全部生成好，让用户去看一个最终的结果。

ChatGPT 可以根据我们的文字描述生成图片，当我们需要对图片进行局部修改时，可以对需要修改的地方进行框选，然后描述修改要求。这种框选的功能就是中间可视化界面。

CLEAR 范式：渐进融合 AI 与 ToB 软件的路径

我将上面的问题和局限性告诉了 ChatGPT，ChatGPT 给我提供了一个范式：

C（Clarify，明确）：用户明确表达业务需求，AI 基于此进行初步的内容生成。
L（Look，查看）：以直观的可视化界面，将 AI 生成的结果清晰展示给用户，以便快速评估和确认。
E（Edit，编辑）：用户可以直接对 AI 生成的结果进行调整、修正，精细化内容，保证准确性和实用性。
A（Adjust，再优化）：用户根据实际需要，指导 AI 再进行局部或整体的优化调整。
R（Release，发布）：经过前面步骤反复优化，用户最终确认无误，提交并落地于实际业务场景中。

其中，E（编辑）和 A（再优化）这两个步骤体现了人工与 AI 的协同。

从费曼学习法的角度谈谈写作

Mon, 10 Feb 2025 22:21:00 +0800

之前读过一篇文章《Why Blog If Nobody Reads It?》，其中一句话让我印象深刻：

你带着相机在城市中穿梭，看到了光影交错、人情流露的画面，于是你按下了快门，但没有人关注。然而，你并不是为了取悦他人，而是想要捕捉那个美好的瞬间。

写作与此类似。很多人写博客、做公众号，常常会想：“没人看，为什么还要写？” 有的人写作是为了流量，为他人而写，还有一种是为了自己而写。王建硕曾说过，他的公众号的文章首先是写给自己看的，是自己思考的过程。

我也是如此。

平时我们在思考和观察中产生的想法、读书的感悟、学习技术做的笔记，当这些内容变成文字被记录时，就已经存在了意义。也只有当这些内容变成文字时，我们才能真正内化所看到的内容，形成了自己的知识。

费曼学习法强调了类似的思想，即通过输出（教别人）来深化自己的理解，当然也可以是教自己。正因为如此，我们在写作时可以思考怎么与费曼学习结合起来。

费曼学习法是什么？

费曼学习法由诺贝尔奖获得者理查德·费曼提出，它的核心非常简单：通过教别人来更深入地理解知识。主要有以下四个步骤：

1、选择主题：确定你想深入理解的知识领域。

2、教别人：用简单易懂的语言向他人解释知识点，就像教一个小学生一样。

3、找到知识盲点：在解释过程中，发现自己讲不清楚的部分，这些就是需要进一步学习的地方。

4、复习和简化：针对盲点深入学习，然后再用更简单的语言重新讲解。

关键点在于“教”，教的前提是自己有思考，能总结。很多时候看一个学习类的视频教程，听的时候总感觉自己懂了，但动手实践或者转述给其他人时会发现不足所措，原因就是没有真正掌握。

如何通过写作运用费曼学习法？

在写作中践行费曼学习法，可以有效地深入对知识的理解。

首先要在平时阅读和浏览各类信息时，养成及时记录和收集的习惯。无论是书籍、文章还是视频，都要将感兴趣或值得进一步探究的内容记录下来，这样做的目的是明确自己想要深入学习和研究的主题。

当我们开始整理这些记录时，需要将所了解的内容转换成自己的语言进行重新描述，这其实就是在用费曼学习法的方式自己教自己，通过解释的过程发现知识的盲点。

此外，我们还可以将写作的内容与他人分享，可以是私下分享，也可以通过公开发布的方式。

无论是哪种形式，这种输出都会促使我们更加认真地去思考和理解。同时，分享还能带来读者的反馈，这些反馈非常有价值，能够指出我们的理解盲区，帮助我们发现之前忽略的视角和问题。

接下来，我们需要对反馈进行深入思考和记录，再结合后续获取的新信息，这样就形成了一个持续学习和知识迭代的过程。

通过不断重复这样的过程，我们的知识体系会变得越来越稳固，表达也更加清晰，写作能力和理解深度都能得到明显提升。

因此，养成记录、总结、根据反馈再思考的习惯，是在写作中有效践行费曼学习法的重要途径。

如何具体开始写作？

墨问的开屏语是记录即创作。记录看似简单，其实非常难。年初我跟老婆说我今年要学习视频剪辑，平时要多拍素材。结果上周末带女儿出去玩，整个过程都没想起来要拍点什么，还被老婆嘲笑了。

养成一个习惯虽然难，但可以通过练习做到的。

写作也是如此，起初总觉得没什么可写，不知道从哪里开始。有一个方法可以让我们比较简单的开始，比如，看一本书，书上的一句话觉得很棒，很有道理，就摘录下来，顺手写下自己的感想，感想可以写的很长，也可以是“很有道理”、“很棒”这类精炼的评价。

记录的工具选择自己喜欢的就行，可以是纸笔、也可以是 APP。

不要一开始就想着写出一篇“好文章”，那样会给自己太多压力，适得其反。可以先试着每天写几句话，写读书笔记、写生活碎片、写一个小想法，哪怕只是几句话也没关系。关键不是写得多好，而是让“表达”成为一种日常行为。

当你持续记录，慢慢地，写作的逻辑、语言的组织、表达的自信都会悄悄地成长起来。当记录的内容足够多，自然能按照某个主题拎出一连串之前记录的内容，重新组织就是一篇文章了。

写作不是天赋，是可以训练出来的能力。

如何形成长期写作习惯？

长期写作的意义，远不止于“输出内容”，更像是一个持续运行的认知操作系统。很多人把写作当作一次性的任务，用完即弃；但对持续学习者来说，写作是一种主动思考、整理知识、构建认知结构的过程。

要真正发挥写作的价值，就要将其变成一种长期的习惯。

首先，写作可以帮助我们梳理知识、搭建思维框架。在这个信息爆炸的时代，写作就像是过滤器，逼迫我们从海量信息中提炼出真正理解的内容，找到不同知识之间的连接。

比如你近期读了几篇关于 AI Agent 的文章，写一篇总结时，往往会促使你去查缺补漏、弄清逻辑关系，最终内化为自己的知识体系。这也是我为什么认为解决程序 Bug 的过程是成长最快的时候。

其次，持续写作是表达力的长期训练场。要求我们把复杂的想法讲清楚，用准确、简洁、有条理的语言呈现。这种表达能力不仅能提升你在工作中的沟通效率，也能让你在任何知识分享场合更具说服力，比如面试、内部技术分享等。

更重要的是，写作会形成一个正向反馈循环：你开始写作，输出内容，获得反馈，进行反思，然后继续写作。这个过程中，学习不再是孤立的“输入”，而是一个不断进化、反哺自身的系统。

坚持写作，不只是记录所学，更是在打磨思维方式，构建长期竞争力。

2024 年终总结

Fri, 31 Jan 2025 16:30:00 +0800

律转鸿钧，新元肇启。2024 已然过去，这一年有很多的变化，特别是 AI 的发展迅猛，变化是好事，意味着有会带来更多的机遇，关键是我们需要时刻做好准备才能抓住。

下面还是按照我的习惯方式给 2024 年做下总结。

成长

在这个 AI 飞速发展的时代，各种工具层出不穷，按说效率应该更高更快，但我并没有觉得变得轻松了，反倒是更累。因为我们接收的信息需要消化才能转化为自己的知识，而在 AI 时代，同等时间接收的东西更多了，需要消化的就更多了，如果消化能力没有提升，就会很累。

还发现了一个现象，现在很难沉下心来进行长文的阅读，阅读长文需要「慢」下来才行，在 AI 这个「快」的时代，慢下来很难，但也可能会收获更多。

信息的处理工具很多还在探索中，这个探索是没有期限的，但总的来说有四个方面：

信息源：Follow、公众号、得到、小报童、读库
输入：flomo、get笔记
消化：暂无
输出：obsidian

所以 2025 年，我的关键词是：慢、消化。

跑步

2024 年立下的 Flag 基本达成：

跑量 2000+
全马突破 330
跑一次 70 公里的越野（目标赛事：崇礼 168）

2024 年总跑量 3000 整，虽然这个数字是凑出来的（最后几公里），但也体现了坚持的成果。11 月 17 日的光谷马拉松官方成绩是 3 小时 30 分 51 秒，算是勉强达成了目标。7 月去崇礼跑了 MTC 组别（70 公里），安全完赛，这是一个重要的突破。

2024 年的跑步历程：

3 月，PB 计划的训练结束，参加了石家庄马拉松，全马 PB 了 80 分钟
7 月，挑战 70 公里越野
11 月，全马又有小的进步

整个 24 年一直没有停下脚步，也取得了一些成绩。非常感谢跑者日历四群的陪伴。

25 年，已经确定的比赛有 4 月份的云丘山越野，其他就看缘分了。比赛不是关键，关键是能一直健康跑下去。

旅行

24 年的国庆长假依旧选择了自驾出行，不过这次多了些不一样的体验。以前的老同事一家和我们一起同行，女儿也多了一个玩伴，使整个旅途充满了更多的乐趣。

行程从武汉出发，途经池州、宣城、泾县、徽州、安庆，最后回到武汉。值得一提的是，出行的这些天，每天都坚持跑步，将运动和旅行完美结合。

公众号

因为始终坚持「为自己而写」的理念，今年的更新比较随性，一共只发布了 38 篇文章。

今年公众号的信息流策略发生了变化，推荐带来的阅读占比越来越大。比如最近写的《信创浪潮下的.NET困境与技术转型思考》就因为推荐获得了 6000 多的阅读量。

这个改变带来了几个影响：

即便是晚上或凌晨发布文章，也不会被淹没
对大众有共鸣的选题或热点事件选题，更容易带来更高的阅读量
标题显得更重要了，当然内容更重要

2025 年还会继续写作，可能更多、也可能更少，保持随性就好。

读书

今年在公众号输出了三本书的读后感：《笔记的方法》、《强风吹拂》、《华为项目管理之道》。但实际的阅读量远不止这些，在得到电子书看了不少书籍，还有读库、follow 上的订阅和大量的公众号文章。

25 年想多看看「闲」书，避免自己掉进信息茧房。有时候，跳出专业领域的阅读，反而能带来意想不到的收获。

播客

Follow 中虽然可以订阅小宇宙的播客，但因为不能登录，无法记录播放时长和评论，所以使用频率不高，主要是看看 shownotes。所以播客主要还是在上下班途中和跑步时听。

除了跑步相关的播客，今年听了很多商业和 AI 相关的节目：

从程序员到架构师，需要做些什么？

Thu, 14 Nov 2024 22:06:00 +0800

最近又面试了不少人，在谈及未来职业规划时，他们大多表示希望走技术路线，并期望未来能成为架构师。在软件开发领域，架构师是许多程序员梦寐以求的职位。它代表着技术能力的巅峰，也意味着更大的责任和挑战。

然而，从一名普通程序员成长为优秀的架构师，绝非一蹴而就。这是一个需要持续学习、实践和思考的漫长过程。

本文想以架构师的职责、误区和程序员怎么做转变，谈谈我的看法。

架构师的职责

在不同规模的公司中，架构师的职责存在差异。尽管一些小公司可能没有设立专门的架构师岗位，但架构相关的工作仍由技术经理或高级程序员等人员兼顾执行。

架构师负责系统的整体设计和技术决策，确保系统在满足业务需求的同时具备高性能、高可用性、高扩展性，也就是俗称的「三高」。架构师需要关注系统的功能性需求，但更重要的是非功能性需求。

架构师需要负责评估和选型适合项目的技术栈、开发工具、基础设施，进行技术调研，分析不同技术方案的优缺点，做出合理的技术决策，选择合适的设计模式和架构模式，以确保系统能够应对复杂的业务场景。

架构师需要制定并推广开发规范和编码标准，确保代码质量的一致性。确立系统设计和代码实现的最佳实践，如代码风格、命名规范、模块划分等，确保团队在项目中遵循相关标准和规范，降低代码复杂度，提高系统的可维护性。

另外，架构师还需要进行技术风险的评估和控制、团队内技术难点的攻克、团队内部的代码评审、培养团队的技术能力、组织知识分享和培训，持续关注技术趋势和行业防战，不断学习和研究新的技术等等。

对架构师的一些误区

1、从零开始设计一个系统

从零开始设计一个系统，还能全程参与，这是可遇不可求的机会。更多的情况是公司都有现成的架构体系。所以以架构师身份入职一个新公司，不太可能一开始就给你一个全新系统进行架构设计，更多的是做一些辅助性的工作。但只有做好每一件小事，当机会来了的时候，才会轮的上你。

2、只跟电脑打交道

估计有些程序员想成为架构师，或许是认为架构师的工作比较单纯，只用跟电脑打交道。但其实架构师作为技术和业务的桥梁，需要与产品经理、业务团队、开发团队和运维团队进行沟通。

沟通能力也是架构师一个非常重要的技能。

3、技术全能

很多人认为架构师是技术全能者，必须精通所有技术栈和工具。然而，架构师并非精通每一项技术细节，而是具备足够的广度来理解系统的整体架构和技术选型，能够做出权衡和取舍。架构师需要深入理解核心技术，并且知道在什么场景下应用合适的技术，而不是精通每一个细节。

4、只专注技术，不管业务

认为架构师只需要关注技术而不用理解业务。事实上，架构师不仅要关注技术，还要深入理解业务需求和业务流程，因为只有这样，才能设计出真正适配业务发展的系统架构。毕竟技术是为业务服务的，缺乏业务理解的架构往往难以支持公司长期战略。

什么是架构？

在说程序员到架构师转变之前，先说说什么是架构。

架构的本质

架构的本质在于为复杂系统提供一种结构化的设计方法，通过明确系统的核心组件、它们之间的关系以及交互方式，来确保系统能够满足功能需求、性能要求和可维护性标准。

架构的本质是抽象和简化，它将复杂的系统分解为可管理的部分，使得开发、维护和扩展变得更加可行和高效。同时，架构还承载着系统的愿景和战略方向，确保技术决策与业务目标保持一致。

架构的分类

按照不同的角度，架构可以有很多分类，但一般来说，主要分为业务架构、应用架构和技术架构。

业务架构描述了组织如何运作以实现其战略目标。包括业务功能、业务流程、组织结构、业务能力等。就是企业要发展，需要哪些业务能力来进行支撑。需要梳理核心业务的处理过程，定义各个业务模块的相互关系。比如：一个零售企业的业务架构可能包括：商品采购、库存管理、在线销售、客户支持等核心功能。

应用架构描述了企业的系统和应用如何支持业务需求，定义了应用的组织方式、交互方式以及应用与数据之间的关系。首先要确定需要哪些应用系统来支持业务，这些应用之间怎么做集成和交互。

技术架构架构描述了支撑应用系统的技术和基础设施，关注硬件、网络、数据库、编程语言、中间件等技术选型和部署。比如：使用什么技术实现应用？部署在什么环境？如何保证高并发、高可用性？如何确保数据的安全性等。

从程序员到架构师的成长阶段

从程序员到架构师的成长可以大致分为以下几个阶段：

1、初级程序员：这是最基础的技能积累阶段，主要学习编程语言、工具使用及完成基本任务。

2、中级程序员：在这个阶段，能够独立完成开发任务，包括需求分析、简单的方案设计。

3、高级程序员：开始指导其他工程师，并关注整体技术体系的建设，形成技术深度和广度。

4、架构师：能够独立完成系统的架构设计，考虑技术选型、系统的可扩展性与稳定性、关注不同模块间结构合理性的问题、关注技术架构的长期正确性。

在小公司可能不会严格按照级别去分，但我们还是需要沿着这个路径去学习和成长。

架构师需要具备的能力

首先一名优秀的架构师一定是一个出色的程序员，能写的一手好的代码。

在此基础上，架构师要有技术的广度和深度。广度尤为重要，程序员在熟悉的领域会钻研的很深，但没有广度，在一些跨系统的沟通场景下很难插上话，甚至连别人说的都听不懂。

能落地的架构才是好架构，所以架构师还需要具备良好的沟通能力，首先是能倾听各种不同的意见和建议，最后确保各方对架构达成共识，愿意采取一致的行动。

资源、时间永远都是紧张的，架构师还需要有良好的平衡和取舍能力，可以确保架构在现有资源约束下是最合理的，优先做最重要的事情，毕竟架构是不断进行迭代，慢慢进化的。

要成为一名优秀的架构师，需要具备以下几个关键能力：

1、技术深度与广度：架构师需要有扎实的技术功底和广泛的技术视野。这包括编程语言、框架、工具、系统设计、性能优化、安全等方面的知识，掌握技术细节是基础，尤其是在不同场景下如何取舍和优化。

2、业务理解能力：架构师不仅要懂技术，还要深入理解业务需求。只有充分理解业务，才能设计出真正符合需求的系统架构。

3、系统思维：架构师需要具备抽象思维、分治思维、复用思维和迭代思维。这些思维方式帮助架构师设计出灵活、可扩展的系统，减少后期维护的复杂度。

4、沟通能力：架构师需要与产品经理、开发人员、测试人员等多个角色沟通。除了架构设计本身，还需要通过文档和会议将设计理念传达给团队，让每个人都理解和使用好架构。

如何培养架构师能力？

1、积累经验：参与不同类型和规模的项目，尤其是复杂系统的设计和开发经验，对成长为架构师至关重要。在程序员阶段需要多进行换位思考，如果是自己来设计会怎么进行，和实际落地的进行比较，分析优缺点。

2、拓宽视野：学习各种技术和架构模式，了解它们的优缺点和适用场景。参与开源项目、阅读优秀的开源代码、参加技术交流活动，都是很好的方式。

3、深度思考：不断反思和总结，将经验转化为自己的知识体系，思考每个技术选择背后的原因及可能带来的影响。

4、保持编码实践：即使成为架构师，也要保持一定的编码实践。这有助于理解开发中的实际问题，验证架构设计的可行性。好的架构师一定是从一线程序员成长起来的，保持与代码的接触，才能设计出切实可行的架构。

5、关注业务发展：深入理解行业和公司业务，预测未来的发展趋势，帮助架构设计更具前瞻性。比如：你的公司如果是做 ToB 业务，又不分行业，那就需要了解多种行业的业务、用户使用习惯，这些都和架构设计息息相关。

6、培养领导力：架构师不仅仅只是在电脑上画画架构图，还需要带领团队将设计落地，因此培养领导力和团队管理能力也是重要的。

结语

从程序员成长为架构师是一个充满挑战和机遇的过程，需要持续学习、深度思考和实践积累。在不断适应新技术与新趋势的同时，程序员需要通过实际项目理解架构设计的原则、掌握架构设计的相关知识点。

只有先具备了扎实的架构设计能力，程序员才有可能在未来抓住机遇，成功转型为架构师。

代码写的好，就可以不写技术文档了吗？

Wed, 23 Oct 2024 16:08:00 +0800

在软件开发中，代码与文档的关系是一个经常被讨论的话题，最近在一个技术群里也针对这个话题展开了讨论，大家各抒己见，以下是群中的一些主要观点，希望对你有所启发。

观点一、代码无法替代文档，文档是必需的

在项目的初期阶段，文档对于需求分析和设计至关重要，它帮助团队理解整体目标和约束。而在实现和维护阶段，代码是核心内容，但文档依然不可或缺，用来补充背景信息、重点逻辑等，确保团队的有效协作。

团队成员水平参差不齐：在大型团队中，成员的编码水平和理解能力不同，仅靠代码无法确保所有人都理解项目的全部细节。文档可以为经验不足的成员提供必要的指导，帮助他们更快地融入项目。
代码难以表达设计思路和决策过程：代码是最终实现的结果，但难以完整传达开发者的思考过程、约束条件，以及为何选择某种实现方式。这些背景信息对于后续的维护和迭代非常重要。
知识传承的需要：代码会随着时间和技术的演进而过时（指的是有些历史代码架构、实现可能都不是最优的，但一直在稳定运行，没就没有去进行重构），但文档能够记录项目的核心理念和设计思路，帮助新成员快速上手，减少摸索的时间成本。
写好代码的成本高于写文档：高质量代码的编写需要丰富的经验和时间，而编写简洁而清晰的文档相对容易，可以迅速传达重要的信息。
文档面向多种读者：代码主要面向开发者，而文档可以针对不同的受众，如非技术人员和管理层，帮助他们理解项目的整体状况和业务逻辑。
避免误解和知识诅咒：开发者通常认为自己的代码已经足够清晰，但对其他人来说可能并非如此。文档可以填补理解上的差距，降低沟通成本。

观点二、代码和文档是互补的，应该同时重视

在小型团队中，沟通相对简单，文档的需求可能较少，更多依赖于自解释代码和口头沟通。而在大型团队中，成员众多且角色多样，文档的重要性显著提高，有助于团队成员理解项目背景、业务逻辑和设计决策，降低沟通成本。

自解释代码减少了部分文档需求：如果代码命名规范且逻辑清晰，部分重复性的文档可以省略，这符合 DRY（Don’t Repeat Yourself）原则。
代码无法替代所有文档：即便代码写得再好，也无法描述项目的背景、业务逻辑、设计决策等信息，这些内容往往需要在文档中进行详细说明。
团队协作需要平衡：团队应通过讨论来确定文档的必要性，确保每个成员都参与到文档的维护中，促进知识的共享和流动。
文档需要更新：过度或形式化的文档可能流于形式，反而成为负担。因此，需要合理的文档管理和及时更新，以确保其质量和实用性。
代码需要达意： 即便有很清晰的文档，开发人员最终还是需要去阅读和修改代码，所以代码本身的质量也非常重要。

观点三：过度依赖代码或文档都会带来问题，关键在于平衡

在敏捷开发中，找到代码与文档的平衡尤为重要。例如，有一个团队在开发过程中采用了「轻文档化」策略，针对关键模块和复杂业务逻辑编写简要的设计文档，而对于简单的实现则依赖于清晰的代码注释和团队协作。这种方式既保证了开发效率，又确保了文档的实用性和及时性。

过分强调代码会忽略知识传递：没有文档的项目在团队人员变动时可能会面临严重的知识流失问题，从而影响项目的长期维护和发展。
过度依赖文档可能导致低效：如果文档过于冗长或没有及时更新，开发者最终还是不得不查阅代码，这无疑增加了时间成本。
培养文档使用文化：如果没有人阅读文档，开发者也就缺乏编写的动力。因此，团队需要培养阅读和利用文档的文化，使文档成为项目不可或缺的一部分。

观点四：澄清对「代码即文档」的误解

代码清晰就不需要文档：某团队在开发初期认为只要代码写得足够清晰，就不需要额外的文档，导致后期新成员加入时对业务逻辑缺乏理解，不得不花费大量时间追溯代码背后的背景信息。
敏捷开发不需要文档：有些团队误解了敏捷开发的原则，认为敏捷就是不写文档，结果在项目需求变更时，由于缺乏文档记录，变更管理变得困难，最终导致项目进度延误。
注释等同于文档：某项目的开发者认为在代码中添加详细的注释就可以替代文档，但注释通常只针对具体的实现，而无法传达整体的设计思路和决策过程，导致项目在维护过程中，尤其是面对复杂业务逻辑时，出现困难。
敏捷宣言的误读：敏捷开发提倡「可工作的软件胜过面面俱到的文档」，但这并不意味着不写文档，更不代表代码可以完全替代文档。
「代码即文档」并非全覆盖：这一观点强调代码的可读性，但并不意味着代码能够表达所有类型的信息，特别是那些代码无法承载的项目背景和业务逻辑。
避免走极端：认为写好代码就不需要任何文档是一种极端做法，不利于项目的长期发展和维护。

我的观点

代码除了让机器执行出结果，还需要人去阅读、修改、维护，所以每个开发人员需要持续提升自己的技能，从变量方法的命名到类之间的结构是清晰的、易读、可维护的。
如果代码质量很高，变量、方法上面的一些废话注释不是必须的，没有这些，代码反倒看着更简洁，但整个项目的整体架构、核心业务的逻辑、算法等还是需要沉淀到文档中，并且随着代码的迭代演进，文档也需要同步更新。
我不认为一个代码写的逻辑混乱的人，可以写出很清晰的文档。所以还是要先从代码入手，让每个人都能写出好到代码，再强调特定文档的重要性。

希望对您有所帮助！

忙碌的陷阱

Mon, 23 Sep 2024 08:35:29 +0800

在一个公司中，当所有人都很「忙碌」时，常常被视为高效和生产力的象征，但如果项目还是不能按时上线、客户投诉比较多，满意度差，就需要思考：这种忙碌是真的高效吗？我们是不是陷入了忙碌的陷阱了呢？

对提升项目效率的一点思考

Tue, 20 Aug 2024 08:17:14 +0800

在一个软件企业中，项目实施效率非常重要，它关乎企业的竞争力，影响项目交付的速度和质量，关系到企业的盈利能力，甚至决定着企业的生死。

2023 年终总结

Mon, 26 Feb 2024 10:01:59 +0800

23 年的总结虽迟但到。

成长

在2023年的一月，我写了一篇关于做减法的文章，这让我意识到持续做加法会带来问题。这个思考引导着我在2023年从各个方面开始转变，包括阅读、信息处理、产品研发和个人的兴趣爱好等。

认真深入做一件事，从跑步开始

Wed, 10 Jan 2024 17:09:43 +0800

去年的 1月 22 号是大年初一，我写了一篇《2023 关键词：做减法》，回顾这一年，做的不算太好，但是朝着这个方向在走，在 2024，我想在做减法的基础上，再多给自己一个要求，就是要认真深入地去做一件事。

为什么会有这个想法呢？还得从跑步说起。

内驱力

Mon, 19 Jun 2023 09:25:55 +0800

最近在群里看到周筠老师征集小孩教育相关的问题，我第一个想到的问题就是：如何让孩子变得有内驱力？

做产品的思考

Mon, 22 May 2023 09:19:28 +0800

在当今竞争激烈的市场中，如何打造出成功的产品是许多企业和团队关注的焦点。结合实际经验，我总结了一些值得关注的关于做产品思考的方面，希望能够为大家提供一些启示。

深入接触客户才能做出好的产品

Fri, 17 Feb 2023 08:07:22 +0800

近些年一直在负责开发低代码平台产品，面向的是企业用户，这款产品一方面给公司内部使用，提升项目交付效率，另一方面，一些合作伙伴或有开发能力的甲方，可以借助我们的产品进行系统的开发，给业务部门使用。

产品的定位非常明确，能够提升交付效率，协助企业进行数字化转型。

正因为是面向企业用户，所以产品的功能增加不能闭门造车，需要深入地接触客户，了解他们的痛点和诉求，再反向体现到产品功能上。

前些天，和公司销售一起拜访了几家公司的重点客户，有些感触。

开始注重效率

记得早些年做企业的信息化建设，更多的是注重将线下办公搬到线上，现在大多数企业已经是在线上办公，就更注重提升整体的流程效率。

企业的增效体现在很多方面，这里主要说的是流程方面的效率，客户其实是很有想法的：

纵向上，按照业务线，将跨不同系统的流程进行拉通，会涉及到各种对接、集成；
横向上，以某个业务点进行扩散，找出关联业务数据进行展示。

信息化、工作流尽管做了很多年，我感觉还是能挖掘出很多对客户有价值的功能。

针对流程本身来说，也可以通过数据的支撑反向找出效率的瓶颈点，比如：

设置超时阈值，从流程到节点到组织和人，找出耗时长的任何事，通过监督来提升效率；
通过流程的通过率，可以找出表单设计或流程设计上的不合理，然后进行优化；
如果有些节点通过率 100%，而且几乎不耗时，这种节点可能没有存在的必要；

除此之外，现在还有专门的公司做 RPA 流程机器人和对流程数据的 AI 智能分析，如何将这些工具和现有的流程平台进行融合，也是值得思考的。

数据驱动业务

随着客户信息化越来越成熟，各类系统中都产生了大量的数据。怎样让这些数据能活起来，为企业所用，这是客户很关注的问题。

一些有开发能力的客户已经在在自己做数据层的东西，底层构建数据仓库，上层提供图形化展示。

现在很多的低代码平台中都提供有 BI 模块，大多数都是展示层，我们的产品中也有对应的模块，相比较专业 BI 产品，功能还是偏弱。为什么都喜欢做数据展示？首先是技术难度不是很高，但更重要的是领导喜欢看大屏展示，最终决策、掏钱的是领导。

在低代码产品中，我认为重要的是能扩展和集成，产品本身不适合在这方面去发力。一个产品如果什么都想做，最终什么都做不好。做自己擅长的事情，然后集各家所长，必能成事，做产品如此，做人也是。

信息孤岛问题依然存在

大型国企现在还存在信息孤岛问题，这个是我没有想到的。

传统企业的信息做了好多年了，10 年前跟客户宣讲，都在说要解决信息孤岛问题。这么多年过去，还是有很多企业忙于解决各种问题，上了几十上百套系统，但系统之间还没有很好地进行联通，甚至连基本的待办消息集成都没有做。

在低代码产品中，添加 SSO、组织机构同步、消息接入等已经算是标配了。但要做好集成不是件容易的事情，涉及到很多利益方，搞定了人，才能搞定事。

客户更希望在整体规划上能提供指导

最近在一个视频号听一个大佬讲：技术人员的一个终极梦想就是做架构师，相比技术架构，现在售前架构师、企业解决方案架构师越来越吃香。

原因就是，客户也不知道要做啥？怎么做？提出的都是一些很宏观的目标，或者直接让提供相关的规划方案。

这其实对售前的要求非常高，要懂客户的行业，了解他们的痛点，能提供解决方案，这样就能牵着客户走，也能得到客户的信任，这种信任会为后续的项目实施带来极大的便利。

反之，在客户不清楚自己想要什么的情况下，售前还只是听客户讲，拿笔记录，最终交付的东西，客户总是认为不是自己想要的，而我们就会埋怨客户总是在进行需求变更。这种情况下，极少数是客户故意刁难，大多数都是没有真正理解客户的意图导致。

因为样本足够小，以上可能都是错的。

2023 关键词：做减法

Sun, 22 Jan 2023 07:25:50 +0800

今天是 2023 年 1 月 21 日，农历癸卯年正月初一，新的一年开始了，祝大家：兔年大吉、大展宏兔、兔然暴富。

很多人都有一个惯性思维就是做加法，这样会比较“心安”，比如：看更多的书、学习更多的课程、让小孩刷更多的题、产品上添加更多的功能，似乎，多就是好。

为什么都爱做加法呢？

在少楠的知识资产中看到，人们爱做加法的原因多半是出于：

首先，我们默认在日常的事物中一切都是「合理」的，不需要减少。比如我们很少会怀疑教科书上有「冗余」的内容，或者使用的工具有什么「多余」的部分。

再次，损失厌恶。毕竟做加法没有什么损失，但是如果要做减法，就得做出断舍离的决策。所以人们默认会倾向于获得更多，而不是舍弃一些。

最后，做加法的效果容易感知，比如多读了一本书，多记了一条笔记，那么很容易感觉到「积累」。但如果少看了一本烂书，删掉了一些无用的东西，这种「减法」的好处很难直观地感受到。

而我决定在 2023 年要做减法，做减法可比做加法难多了，意味着要有更多的思考、更多的断舍离。

这个减法可以体现在很多方面，比如：个人成长、产品功能、代码架构。

个人成长

现在信息摄入的途径和内容都非常多，眼花缭乱。要很笃定的知道自己需要什么，然后把信息消化吸收后变成自己的养分。

所以，这里的减法是指内容的处理和消化。只吸收不消化，跟捡垃圾没什么区别。

枝叶需要进行修剪才能长得茂盛、铁路线越来越多，也需要合理规划、并站才能高效地进行调度，所以信息的获取不能一味的进行增加，还需要我们抽出来时间进行修剪，把核心的连接加强，把无用的节点删除或合并，才能让我们信息慢慢转化为自己的知识。

现在我的信息摄入途径有：

书籍：纸质书、电子书、樊登读书、读库；
社交媒体：即刻、知乎、豆瓣、B 站、小宇宙；
专业 APP：极客时间、得到；
其他：公众号文章、订阅的 RSS 和 Newsletter 。

2023 我想这样来做减法：

不设置读书目标，养成每天都看半个小时或一个小时的习惯；
看过的内容要思考做笔记和回顾；
尽可能地多输出、多和不同的人交流；
定期梳理笔记、抽取主题、形成文章。

个人成长的减法并不是说减少输入的途径，而是增加中间的处理和思考的过程，让积累的东西慢慢变少，沉淀出来自己的东西慢慢变多。

产品功能

做产品也是一样，要做减法，很多时候冷静思考，沉寂一段时间后，发现很多原先紧急的需求都可以不用做了。

为产品做减法，首先就是要搞清楚产品的定位。

定位不准确，就很容易什么功能都相加，加到最后就变成四不像了，看着什么功能都有，但又什么功能没有做到极致，甚至互相之间还是矛盾的。

假如产品的定位就是做一个给开发人员提升效率的低代码平台，明确了这个目标，就很容易知道哪些是可以不做的，比如：

完全配置化，不考虑二开；
按业务人员使用的视角去设计产品功能。

哪些是需要做的也很清晰：

能减轻开发的重复性的操作实现配置化；
提供各种批量操作，比如批量修改表单控件的属性；
提供二开的辅助调试工具，自定义组件、在线脚本能够更好地进行对接和排错。

产品功能的减法不是说啥功能也不做了，而是搞清楚哪些是可以不做的，该做的还是要按照正常的节奏去迭代。

代码架构

在产品的代码构架上会存在两个问题：

初学者使用复杂的架构解决简单的问题，而出现学以致用的幻觉；
因为各种「紧急」，而在项目中添加各种临时补丁或重复代码，这些通常被称为「技术债」，这些「技术债」会在以后有时间就处理，正常情况以后都不会有时间。

越简单的东西越容易理解，越不容易出错，所以在产品架构中要避免出现过度设计，架构方案需要进行评审。

上面提到的技术债，其实也是有时间处理的，比如，你们采用的是敏捷开发模式，在一个迭代周期内，所有人都是为这个迭代目标而冲刺，那么在迭代版本发布前，某些开发人员的开发任务已经完成，除了可以参与测试之外，就可以处理这些「技术债」。

代码架构的减法是通过这个减法让产品代码始终保持一种合理的架构，毕竟，合适的才是最好的。

最后

加法容易，减法难，那么我们选择难的这条路，必然会结出更艳丽的果实。而你也会因为走了这条难的路而更加光彩夺目。

2022 年终总结

Tue, 03 Jan 2023 09:00:23 +0800

往年的年终总结都是在春节期间写，但元旦确实是更好的一个分界线，所以便决定今年开始在元旦左右来写年终总结了。

当谈研发效能时，在谈些什么？

Wed, 01 Jun 2022 00:00:00 +0800

最近翻了下之前写的公众号文章，发现研发效能相关的就有三篇：

怎样提高开发效率
关于增效，需要做好这两点
再谈研发效率提升

从工具使用、业务的理解、团队的沟通协作到流程、组织、分享等内容，我能想到的大部分有关研发效能的点都有涉及到。

结构化思维

Tue, 10 May 2022 08:08:42 +0800

在说结构化思维之前，先看下面两个小案例：

2021 年终总结

Tue, 01 Feb 2022 21:14:11 +0800

年龄越大，会觉得时间过得越快，2021 年已经结束。

四点起床，是疯狂还是自律？

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

如果你在微信读书中搜索「四点起床」，会搜到好几本相关的书籍，其中有一本是《4点起床：最养生和高效的时间管理》，作者是日本的中岛孝志，一位读书狂人。前几天，微信读书系统对我做了这本书的推荐，花了几个小时看完，便疯狂地体验了下。

零代码平台中的服务编排思路

Thu, 04 Nov 2021 08:05:00 +0800

随着企业数字化转型的进程加快，零代码平台的的应用越来越广泛，逐渐被企业级的客户认可和接受。

零代码顾名思义就是在不写代码的情况下可以搭建应用和功能来满足客户的需求，但事实是残酷的，真实的客户需求永远比我们想象的要复杂，传统的零代码产品需要提供各种扩展能力，比如可以让开发人员编写复杂的业务逻辑代码，并对接到平台中。

使用零代码平台构建应用，应该怎样转变思路？

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

最近两年，越来越多的各类零代码产品在市场上出现，与此同时，企业的数字化转型的速度也越来越快，零代码产品已然成为了帮助企业数字化转型的利器。

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

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

程序员是一个需要终身学习的职业，其实不止是程序员，各行各业都在内卷，掌握好的学习方法，学习更多的技能，会有更大的竞争优势，也会让你在未来有机会到来的时候，能够承接得住。

提升心力：摆脱拿着锤子看啥都是钉子

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

从程序员到一个团队的管理者，这中间需要经过一次又一次的蜕变，最终才能变得处理任何事情都得心应手。

韩非子曾说：下君用己之力、中君用人之力、上君用人之智。大部分的管理者可能都处在用人之力的阶段，并向着用人之智前进。最近看了一些关于管理的视频，提到了更高维度的用人之心和用人之愿，如果能做到，那必定会是一支战无不胜的团队。

你真的了解低代码平台吗？

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

从 2020 年疫情之后，低代码这个概念就突然变得火热起来，各大自媒体纷纷推出介绍低代码的文章，InfoQ 也曾发表过一篇《为什么我说低代码是“行业毒瘤”？》引发了热议，明道的创始人任向晖随后在自己的公众号写文章《低代码不是行业毒瘤，你才是！》进行回应，好不热闹。

再谈研发效率提升

Mon, 05 Jul 2021 08:25:00 +0800

最近因为一个版本的发布上线，带着团队兄弟们几乎通宵了，见到了凌晨四点武汉的景色。为什么到这么晚，这背后的原因是值得深思的。归根结底，就是研发效率不高，到了临近上线仍出现各种各样的问题。

你有做 Code Review 吗？

Tue, 15 Jun 2021 08:05:00 +0800

在代码的编写中有一个很重要的环节，经常会被忽视，那就是 Code Review ,据说在 Facebook、Google 这种互联网大公司，要求每一个提交都必须通过审查，对于每个工程师来说 Code Review 是一项十分重要的工作，甚至比写代码本身更重要。

实现多租户系统的一点思考

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

2020年突发的新冠疫情，让在线协同办公在疫情期间成为了刚需。我们也从 2020 年的 2月3 日开始在家远程办公，直到四月份。协同办公软件一下子火爆了起来，钉钉、企业微信、特别是腾讯会议等都在疫情期间表现突出，呈现出井喷式的发展。

目前大部分的企业信息化都是私有化部署，局限于企业的内部网络，无法实现远程协同办公，所以越来越多的 To B 企业逐步转向 SaaS（Software-as-a-Service，软件即服务），SaaS 最早是美国Salesforce公司（1999年创立）创造的新软件服务模式。这家公司的市值在 2019 年已经超过1000亿美元，国内现在还处在发展中阶段，前景还是十分广阔的。

要将传统的私有化部署的软件重构成支持 SaaS 模式，多租户是一个迈不过去的坎，首先需要将系统改造成多租户模式，然后再逐步实现计费、系统监控、用户行为分析等功能。

我觉得多租户的设计应该分为三个层面来进行讨论，应用、数据库和中间件。

应用

现在的项目或产品开发几乎都是前后端分离的开发模式，应用层主要指的是 WebAPI ，WebAPI 的改造有两种方式：

1、每个租户部署一套 WebAPI、上层通过域名或 Url 地址的解析进行路由，当有新租户注册的时候就动态进行对应的 WebAPI 的部署，这种方式改造成本低，但运维成本高，不建议使用，如果时间紧，可以当过度阶段的临时方案。

2、所有的租户共用一套 WebAPI ，在 WebAPI 中需要获取到租户信息（域名、Url参数、请求头信息、Cookie 等），然后进行租户信息配置的切换。有新租户创建的时候无需进行新的 WebAPI 的创建，只需要初始化租户基本信息即可。

在这种方式下，如果 Cluster1 的负载超过限度了，也要能够进行动态切换，将其中的某些租户切换到其他的 Cluester 中，如上图。

在 WebAPI 的代码实现上，可以参考 Abp 框架中多租户的实现，这里给出一个简化版本：

TenantConfiguration：租户配置信息

[Serializable]
public class TenantConfiguration
{
 public Guid Id { get; set; }

 public string Code { get; set; }

 public string Name { get; set; }

 public TenantStatus TenantStatus { get; set; }

 public string DBConfig { get; set; }

 public string CacheConfig { get; set; }

 public string MQConfig { get; set; }

 public string MongoConfig { get; set; }

 public TenantConfiguration()
 {
 TenantStatus = TenantStatus.Enable;
 }

 public TenantConfiguration(Guid id, string name)
 : this()
 {
 
 Id = id;
 Name = name;
 }
}

TenantStore：从缓存或数据库中获取租户配置信息

关于增效，需要做好这两点

Tue, 06 Apr 2021 08:05:00 +0800

最近两会上都谈论到 996 的问题了，那我们实行 996 ，每个人每天都非常忙碌，是不是就效率很高呢？是不是很多时候都在做一些无价值的事情呢？是不是都在加着班写着 Bug 呢？我认为真相远没有我们想象的那么乐观。

春节后的几次公司会议上都在提「增效」，随着公司的发展，人数变多，各种成本也随之增高，所以通过各种方式来增效，才能有正向的发展。以目前我的观察来看，我觉得可以从两个方面入手：沟通和抓住关键点。

在《怎样提高开发效率》一文中主要说的是开发人员硬技能方面的提升，在上面提到的各种成本中，沟通成本是非常重要的一块，这属于软技能的范畴，也是最容易被忽视的。

沟通体现在很多个方面，这里主要想说下提问和 Bug 描述。

前不久，有项目团队同事在企业微信上问我：怎样拉取镜像来进行测试环境的更新？如果考虑到部门之间应该有良好的沟通的协作，我应该告诉他怎么操作，但为什么有这么低级的问题能被问出来，是一个值得思考的问题：

拉取镜像更新是一个每个开发人员必备的技能，为什么还有人是不会的？
有没有做相应的培训，或者培训了，是否每个人都能够理解？
听的时候理解了，实际操作的时候是不是还是不会？

所有有章可循的、都应该形成规范，进行培训、然后考核，保证不同的人按照文档进行操作能够得出相同的结果，如果有开发人员能主动去探究其中的原理并举一反三，那便是锦上添花了。

对于 Bug 描述经常会出现这样的场景：

实施人员：表单上的选人控件加载部门树很慢；

开发：经过一系列的代码检查、运行调试后回复，我本地很快啊；

开发人员时间花了，但并没有解决问题，在描述 Bug 的时候，需要有更详细的场景和上下文信息，比如：

客户的部门和人员的数据量级是多少？
是所有用户还是特定用户，如果特定用户，是否有什么特殊的权限的设置?
客户使用的浏览器是什么版本？
选人控件本身有没有什么特殊数据范围或权限的设置？

有了更多的信息，开发人员就能有针对性地进行排查，也能更容易解决问题。

Bug 只要能重现，处理起来还比较容易，当遇到偶发 Bug 的时候，更是要尽量提供足够的信息，但很多时候描述却是这样的：

实施人员：客户点击某某操作时，会出现系统异常，我们有时操作也会出现，但不是每次都出现；

开发：不能重现，我怎么排查呢？

实施人员在一线，离现场更近，能知道更多的信息，所以在出现问题时需要尽可能多地提供信息：

系统出现异常提示是有日志记录的，是否有对日志进行过初步的分析？
操作的数据中有没有特殊数据，比如附件、富文本等？
是否能收集到客户用的系统以及浏览器的版本？
是否能收集到客户的操作系统的方式？

如果每个一线实施人员都能够去收集一些有用信息，做下初步的分析，然后将整个过程形成文字内容提交给开发，相信会大大提升解决问题的效率。

至于收集哪些有用信息，怎样来做初步分析，随着慢慢地沉淀，也一样可以形成标准的文档和操作手册。

除了沟通，另一个能提高效率的地方就是在工作中能抓住关键点，根据二八法则，抓住 20% 的关键点就能解决 80% 的问题。

下面是最近团队中发生的两个个事情，正好说明了关键点的重要：

产品代码做重构优化，让开发人员按照思路写出类以及空方法，然后进行评审，但开发人员会比较容易关注细节，一动手就想着对象怎样映射，依赖注入应该怎么进行设置等等，浪费了时间；
让开发排查一个 Bug，我便开会去了，一个多小时回来询问情况，得知还没有解决，还在继续调试代码分析原因，最后发现是一个配置项没有添加导致。

第一件事情的关键点是代码的思路，而不是实现，开发人员和产品负责人的目标和思想需要一致，也就是华为管理哲学中所说的「力出一孔」，如果方向偏了，努力越多，错的越远。

第二件事情的关键点是遇到问题的思考，想清楚之后再动手做，最终的做可能是检查配置、寻求其他人员帮助、或者代码调试。而不是任何问题一上来就进行代码调试。

最后总结下：

1、沟通在工作和生活中无处不在，想想沟通的目的，多换位思考；

2、除了上面说的提问和 Bug 描述，还有代码注释、代码提交备注、技术规范文档等等都属于沟通；

3、方向一致、目标明确做起事来才能最高效；

4、多思考、总结、复盘才能慢慢积累经验，经验丰富了才更容易找到关键点。

希望本文能对您有所启发和帮助！

2020 年终总结

Fri, 12 Feb 2021 08:30:00 +0800

2020 年是很特殊的一年，也是过得最快的一年。

疫情贯穿着全年，只要是外出口罩变成了必备品，这些都是和以往不一样的地方，包括到年底的提倡着就地过年，这已经变成一个持久战了，心态一定要好。

疫情改变了我们的生活，封城了两个多月，经历过物资不足的窘迫，也经历过单元楼内有确证的恐慌，两个多月学会了做各种面食，两个月内也第一次体验了在家远程办公，在《远程办公也可以很高效》中介绍了当时办公的场景和方式。

看见的不一定是真实的

Mon, 08 Feb 2021 08:30:37 +0800

年末了，再说说加班的问题，其实加班这个话题之前已经写过两篇了：

蹭个热度，也说说 996
你的加班有价值吗？

为什么这么忙，还依然做不好事情

Wed, 30 Sep 2020 09:46:53 +0800

一直都很喜欢《重来》系列，最近出了《重来3：跳出疯狂的忙碌》，第一时间在微信读书中阅读了，让我们印象比较深刻的就是「冷静」和「效率」，本文主要说说效率的问题。

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

Mon, 24 Aug 2020 09:41:17 +0800

在上一篇《一款用了就不想走的工具》中介绍了一款工具 Notion ，可以做学习的规划、时间的管理、学习的记录等，但学习本身还是需要一些方法的，本文谈谈我对学习的一些感悟。

如何激发团队潜能？

Sun, 28 Jun 2020 12:06:25 +0800

每个技术人员最终可能都会走上管理岗位，从最初的开发 Leader、到部门负责人、甚至到 CTO,这每一个角色的转变，都需要付出巨大的努力去进行思维的转变。最近读的《授权》这本书可以让我们更好地胜任管理这个岗位。

程序员还有35岁的坎吗？

Mon, 23 Mar 2020 07:48:55 +0800

昨天晚上和一多年未见的前同事聊天，提到了程序员的年龄歧视问题：

自己年龄也 30 出头了，在思考 IT 届流传的 35 岁是一个坎的问题；
开始注重提升管理能力，担心35岁之后，一线写代码的岗位不能胜任；
公司在招聘新人的时候，有明确的年龄限制。

远程办公也可以高效

Mon, 09 Mar 2020 07:19:57 +0800

因为疫情，全中国人民都过了一个难忘的春节，而身在武汉的我，更是没有出家门半步，坚决做到不过国家添乱。从开始的2月14到后来的2月20日，再到现在的3月10日，官方发布的复工日期一次次的推迟，我们也做好了长时间远程在家办公的准备。

写公众号的这一年多

Tue, 28 Jan 2020 14:29:57 +0800

2018年五月，在微信发布公众号助手之时我开通了个人公众号「不止dotNET」，到现在已经一年半多的时间了，非常时期，在家自我隔离，没事写写总结。

2019 年终总结

Sat, 25 Jan 2020 14:21:57 +0800

老板每次跟我们开会总会说起写总结的重要性，很庆幸我一直都有这个习惯。依然是要在大年初一到来之前写完这个总结。

你的技术债还了吗？

Mon, 09 Sep 2019 07:03:22 +0800

什么是技术债？

技术债是由沃德·坎宁安在1992年提出，指我们在软件架构或代码编写过程中有意无意地做了错误的决策。随着时间的累积，这种错误会越来越多，就像背负了很多债务一样。

程序员如何学习英语

Sun, 21 Jul 2019 09:57:50 +0800

首先，这不是一篇广告，虽然这个标题很像。

其次，我的英语水平也很一般，所以更多的是谈谈一些失败的经历和思考，俗话说，成功的经验不可复制，失败的经验倒可以让我们少走弯路。

英语的重要性毋庸置疑，对于程序员来说更甚，一些最新的技术资料是英文的，很多开源软件的官方文档也是英文的，如果想进入外企英语是必备条件。我就是英文不好，连投递外企简历的勇气都没有。

我的英语水平

学生时代四级最高分58
工作后立过无数次Falg，到现在没有明显进步
听说基本为零，读写凑活，技术相关文档能基本能读懂，借助翻译工具可以和老外书信交流

学英语目的是什么

语言分为听说读写，我们在学习母语的的时候，通常是先听说后读写，而在学习英语时往往是相反的，像我就是，读写强于听说。很多的英语学习方法会建议要按照学习母语的方式来学习英语，我认为也不完全是对的。最重要的是要搞清楚学习的目的是什么，然后对症下药，比如：

出国旅游或者想要面试外企，就要侧重于听说
看英文技术书籍、网站、博客，在Github上参与开源项目，就要侧重于读写

对我自己来说：

需要阅读英文技术资料
经常会在stackoverflow上找一些问题的答案
使用了某个开源代码，需要在issues中寻求帮助
在Linode购买了vps，在Tickets中需要和老外进行沟通

所以我更偏重在读写上的提高，在读写搞定的情况下，再有针对性地去练习听说，YouTube这个庞大的资源库就是要学习好听力的强大动力。

量变到质变

我非常相信任何事物都能从量变到质变，如果质变没有发生那就是量不够。下面是我有深刻体会到两个从量变到质变的例子：

跑步

平常跑步，三五分钟就会大汗淋漓，之前从未想过在冬天的早晨，零下几度，还能跑到全身出汗。直到几年前的一个冬天早晨，出门跑步，10分钟的时候，身上还没发热，二十分钟的时候，也只是微微出汗，等到1个小时左右，完成了10公里时，全身已经汗透。

音乐

2017年春，同学在群里有人推荐了《成都》这首歌曲，非常喜欢，连续一个礼拜的上下班途中，单曲循环听，这一个礼拜的时间，我并没有刻意地练习怎么唱，就是因为不断的重复，使我学会了这首歌。

英语的学习，不管是记单词，还是阅读，或是听说，如果有大量重复的训练，必然会产生一定的效果，但我们常常是三分钟热度就放弃，我也是如此，就像跑步，10分钟的时候，就已经停下了脚步，不管你跑了多少次，始终都感受不到大汗淋漓的畅快。

今年年初，花99元报了一期水滴阅读，需要坚持100天，起初积极性很高，再加上老师在群里的督促和坚持打卡可以赠送书籍的诱惑，开始的一两个月每天都花固定时间去学习，做习题，后面随着难度的增加，间歇性的没有打卡，慢慢也就放弃了，要知道，坚持一件事情很难，放弃可是分分钟的事。

强烈的意愿

每个人都会有惰性，这个惰性体现在是不是你所关注的事情。我老婆经常说我，家里的买的拼装家具，小孩的拼装玩具，每次都要拖很久才去做，你自己买的健身器材的安装就非常积极。

我反思了下，为什么我每次都没能够坚持呢？还是意愿不够强烈，对我来说，英语学习好学坏，对我的工作和生活不会造成什么影响：

工作中查资料遇到有英文的，可以借助翻译工具
生活中就更是更英语没什么交集

什么时候会有强烈的意愿呢？

当我们去准备面试时，我们必需精心地复习巩固面试所需要的专业编程技能，
当在工作中遇到难题时，我们必需通过各种手段去解决，在这过程中，就会有很大的收获

如果您像我一样，英语不是生活和工作中的必需品，而又想学好它时，就要想办法提高自己学习的意愿，我能想到下面一些方式，当然每个人都有自己的方式：

在Github上参与开源项目，可以从提issues开始
找到国外大神的系列技术文章，然后制定一个小计划，比如在1个月内翻译10篇
以赚积分为目标，在stackoverflow上用英文去回答别人的问题

总结

英语和编程一样，需要不断实践才能提高
无所谓形式，是先记单词，还是直接就阅读，语法到底需不需要学习，我觉得不太重要，主动或被动地让自己有强烈的意愿是关键
制定目标，剩下的就是行动了，就像池大说的，让正确的事情持续发生，这其实就是量变到质变的过程

希望本文对您有所帮助。

对产品质量的一点思考

Mon, 01 Jul 2019 06:44:41 +0800

不管是做产品还是做项目，也不管是采用瀑布模型还是敏捷开发，我们都有一个终极目标，就是能按时交付质量可靠的功能，其中质量尤为重要。

本文是我对产品质量的一点思考，如果您所在的团队代码质量很高，很少出BUG，那么可以私信我，我们可以交流下关于代码质量的一些问题。

怎样学习和阅读技术书籍？

Sun, 02 Jun 2019 15:08:16 +0800

技术的更新换代非常的迅速，作为一个技术人，需要持续不断地学习才能不被淘汰。但是学习没有速成的方法，只可能有一些技巧让我们事半功倍，本文是我对学习和读书的一点思考。

蹭个热度，也说说996

Mon, 22 Apr 2019 22:19:10 +0800

最近996很火热，也来凑凑热闹，在文章的开始，先表明我的立场：坚决反对996。

什么是996？

2018 年终总结

Thu, 07 Feb 2019 23:51:42 +0800

一直都有写总结的习惯，一方面思考下一年下来有哪些做的好的，哪些还需要改进。另一方面，若干年后再回过头看看，知道每年都发生了点什么。但写东西这事，不能耽搁，有了想法就要立即动笔记录，否则可能会不了了之。像我前两年的年终总结就是如此。

你的加班有价值吗？

Sun, 21 Oct 2018 23:09:58 +0800

今年一直在忙公司产品的事情，压力比较大，工作强度也比较大，不夸张的说，今年加的班应该比整个职业生涯加起来还多，所以也有了些思考和想法。

怎样提高开发效率（2018）

Mon, 17 Sep 2018 22:49:03 +0800

开发效率可以从个人开发效率和团队开发效率来谈，抛开自由职业者，但凡在一个公司上班的程序员都必然是在一个团队中工作，所以每个人的个人效率最终都会转化为团队的效率。转化率有多大，取决于团队的凝聚力，每个人的劲是不是在往一处使。

团队效率最重要的是沟通，我经常会碰到这样的情况：

我们真的需要KPI吗?

Fri, 03 Aug 2018 22:51:21 +0800

前言

工作十几年，经历过不少的公司，每个公司都有自己的管理方法，其中大公司比较偏爱使用KPI考核，小公司则直接靠人来管理。下面谈谈之前公司KPI考核制度和现在「松散」管理的对比。

严格的KPI制度

之前的公司在武汉研发中心有大概五六百的技术人员，每个团队的项目经理只考虑需求沟通、任务分配和资源协调。完全不用管团队成员是否有认真干活，员工的管理依赖KPI制度。当时开发岗的考核制度大致如下：

工作量

任务系统的任务都会评估出一个工作量，以天为单位。计算方法为在季度末算出整个季度中完成的工作量和总出勤天数的一个比例。表明上看这个指标非常好，公司不用怕员工偷懒，相反员工还会主动去找事情做，因为担心工作量不够。当由于各种任务之间的衔接、各种内耗，往往会造成「忙」的假象。

bug量

bug量的计算方法是一个季度所做的任务的有效bug量和所做任务的工作量的一个比例，最终算出每天的平均bug量是多少，再根据这个bug量来打分。设置bug量这个指标的初衷是为了提高开发人员的开发质量，减少测试与开发之间往返的消耗。但这个指标至少会带来两个弊端：

1、开发人员和测试人员的对立

因为测试岗也有bug量的质量，他们是平均每日找到多少个bug，所以很多时候开发人员都在和测试人员纠结bug有效性的问题，其实开发和测试的目标应该是一致的，都是为了软件能够高质量的交付。

2、事不关己，高高挂起

经常会在项目中发现一些不合理的代码，如果这些代码不是自己负责的，开发人员不会去进行重构，因为可能会带来更多的缺陷，而这些缺陷最终会记在修改者的头上，即便重构不会带来任何的风险，也没有人会关心这个，人们更多关心的是软件能不能正常的运行。正是由于这个指标的存在，随着时间的增长，项目中的坏味道会越来越多。

关键节点达成率

任务系统中的每个任务都会设置关键节点，对于开发来说关键节点就是某个任务提交测试的时间点。计算方法是未超时的任务数和总任务数的比例。这项指标的初衷是保证开发的效率，但也带来了一些问题：

1、互帮互助少了

虽然公司一直都强调同事之间要多沟通，多互相帮助，但正是有了这个指标当你的任务已经快到关键时间点的时候，你就没有多余的时间去顾及其他的事情了。

2、多任务的处理

当你正在处理设置了关键节点的任务的时候，突然来了紧急bug任务，正常逻辑应该是优先响应紧急bug，但也有了这个指标，开发人员就会先保证当前任务不超时，而不会去响应bug需求哦。

「松散」的管理模式

近些年在一个中小公司负责产品团队，团队规模很小，自然也就没有严格的KPI考核制度，开发人员都是有个性的，都不会喜欢被KPI所束缚。但没有KPI制度的管理也会碰到各种问题。

太理想化

我一直想象的理想团队是每个成员都应该是自我驱动型的，当需要通过制度或是人来管的时候，自然是做不好事情的。现实情况是，人都是有惰性的，团队并不会了一个伟大的共同目标去努力奋斗，每天朝九晚九仅仅只是当成了一个工作。起初最典型的一个表现是，分配的任务总是在截至时间的最后时刻完成。

公平

没有KPI这种量化的考核，对团队成员的考评就会偏主观，就可能带有感情色彩，就可能有失公平。做事快的人可能会被分配更多的任务；bug多的人可能会感觉一直都处于「忙碌」的状态；效率高的人可能会被认为不够努力。

总结

任何管理方式都会各有利弊，包括最近两年比较火的OKR，相信在实践过程中一样会遇到各种问题。既然都会遇到困难和问题，我个人还是偏向松散的管理模式。

松散的管理模式，并不是说不管理，而是要努力做到让每位团队成员从“要我做”到“我要做”的转变。我认为可以尝试以下一些方式：

1、领导要对团队成员要有足够的信任，用人不疑，疑人不用； 2、技术人员普遍比较闷，不愿说出内心真实想法，需要经常和他们去沟通，了解他们内心真实想法，能力范围之内解除他们后顾之忧； 3、团队内部需要经常组织一些活动，提升团队凝聚力。比如一个开发阶段完成后，组织吃饭唱歌等； 4、定期给团队内部培训，要让每个成员都了解产品的思想，了解客户真实需求，了解公司的愿景。目的是让大家能够一起为了一个共同的目标努力，而不只是自己负责的一个功能模块。但同时也要阶段性让团队成员看到收益，而不只是画饼子； 5、建立奖惩制度，赏罚分明，公平、公正、公开； 6、如果公司领导允许，或许可以尝试下阿米巴的方式。

坚持很难？是不是没找对方法

Tue, 10 Jul 2018 23:17:40 +0800

最近听到了很多关于坚持的话题。

1、公司的年中会议上，几位领导人的讲话都提到了我们需要找准方向，坚持下去。 2、在dotNET 跨平台的群里，有群友问怎样才能成为像张善友这样的大牛？张善友的回答是：我做技术近20年，坚持每天学习新技术半小时，坚持晚上11点睡觉，早上6点起床。 3、在逻辑思维的公众号中，罗胖坚持每天早上6点半发布一条有价值的60秒语音，就这么一件事，他坚持了2000多天。

这些年我关注的公众号

Wed, 27 Jun 2018 23:45:39 +0800

在现在这样一个信息大爆炸的时代，我们可以用各种途径和方式来获取想要的信息，而且你会发现重要的信息往往都会重复出现，所以我现在主要用来获取技术方面信息的途径是微信公众号。公众号的关注也是动态变化的，时常会关注一些新的公众号，也有些会被清理掉。下面是几年下来一直持续关注的技术公众号，排名不分先后。

近期写作计划

Thu, 24 May 2018 22:43:40 +0800

写博客很多年了，都是想到哪写到哪，更多的是些学习的记录，缺少思考性的东西。最近开通微信公众号:不止dotNET，希望能将工作和学习中更多的思考分享出来。

做产品或项目，都会事先制定开发计划，按照计划往前走，确保最终达成目标。公众号也可以看作是一个特殊的产品，只不过这个产品没有时间节点，需要的是我们持续的思考、学习，并且能够长期的输出。本文就先来制定一个短期的写作计划。

在开篇时说过，文章大概分为四大类：

学习总结

学习的内容大部分是跟工作相关的，也会有自己感兴趣的领域。会涉及但不限于下面的主题：

微服务
dotNET Core
持续集成
软件架构
Docker容器
那些年，我关注的公众号
那些年，我使用过的工具
那些年，我读过的技术书

管理相关

管理分为任务管理和人员管理，会涉及到下面的内容：

敏捷开发方法落地
绩效管理用KPI还是OKR
小公司大公司的区别
怎样管理一个技术团队
程序员怎样阅读技术书籍

产品之路

我理解的产品分为三种：

1、互联网创业公司做的事情，该产品为某种服务，ToB或者ToC，像淘宝就是给广大网民提供购买服务的； 2、公司做企业级应用，随着经验的积累，逐步沉淀出一些产品，如单点登录、AD管理等，这些有的可以开箱即用，有的需要按照客户要求做二次开发，通常是一个大的解决方案中的一部分，更准确的说应该算是中间件； 3、面向企业的一个完整的产品，根据企业要求可以私有云或公有云部署，基本可以满足企业需求，但有时也会做些二次开发。

后面两种已经经历过，第一种也即将会经历，在整个做产品的过程中，踩过很多坑，犯过很多错误，同时也有很多的感悟，希望通过一系列的文章分享出来。

之前博文整理

设计模式总结
程序员学英语
读书笔记：代码整洁之道
读书笔记：打造Facebook
读书笔记：番茄工作法
读书笔记：构建之法
读书笔记：软技能
Git工作流程
C#破解dll
对加班的一些看法
一年跑3个马拉松是怎样一种体验

总结

随便一列，好像还不少，做任何事情最重要的是坚持，也希望自己能坚持下来，计划每周更新一到两篇。

谈谈加班

Thu, 08 Sep 2016 23:22:06 +0800

今天谈谈加班这个敏感的话题，相信大家在职场中都或多或少的经历过加班。特别是 IT 这个行业，加班更是家常便饭。加班通常有这么四类：

2014 年终总结

Thu, 19 Feb 2015 00:00:00 +0800

本文已是今年写的第三篇总结了，为了得池大大的一本书写了第一篇总结，还好结果还算不错，《第一本Docker书》已在邮寄的途中；第二篇是公司要求写的个人总结。本篇还是以生活和工作两方面来写下2014年的点点滴滴。

生活

2014年5月16日，女儿顺利降生，这是今年最大的事情了。有了女儿，家里更热闹了，不过时间也更少了。现在每天的生活都是这样的：

1、白天上班，不加班的话下班到家将近7点；

2、9点之前我跟女儿的互动时间，这期间老婆做饭、吃饭、跳操等等；

3、9点后老婆哄女儿睡觉，我就有自己的时间了，或处理工作上的事情、或看书学习、或写写代码，或看看电影美剧；

4、如果没有特殊的事情，通常都会在12点前睡觉，早上一般5点半或6点起床，7点40驱车上班。

早在老婆怀孕的时候，和老婆商量无论生男生女都叫”fengzihan“这个读音，随即就注册了fengzihan.me的域名，作为女儿的个人网站。前不久将之前的空间迁移到了Linode的VPS，并将女儿的站点搭建起来，由老婆执笔记录女儿的成长。

工作

2013年底才来到现在这家公司，公司很小，项目型公司，研发人员有的在公司，有的在客户现场。公司之前的代码各个项目是分别管理，有的用snv，有的用tfs，有的甚至都没有使用源码管理工具。

所以2014年上半年我做的第一件事就是将公司所有代码进行梳理，并迁移到git上，这样再也不用担心这种分布式的人员了。因为当时公司外网服务器的原因，使用的是开源中国的git托管，目前准备使用gitlab在公司服务器上搭建git环境。最近开源中国的git托管做了升级，越来越有github的味道了。

2014年上半年第二件事是将公司的主后台管理平台进行重构:

1、使用Bootstrap进行UI重构，后面的项目实施中有不少客户觉得很高大上；

2、项目的组织方式进行了重构，这可以算是比较大的一个手术，需要了解整个平台的很多细节。调整后的好处是更便于项目的分模块开发和部署。

2014年下半年也做了两件事，由于公司项目太多，人手不够，我被推到了项目经理兼技术经理的位置，带着3、4个人历时5个月做了一个项目。小公司就是这样，可能会涉及很多的角色，这不，第二件事就是负责招聘，整个下半年面试了近百人，只招进了5个人。

总体来说，整个2014年很忙碌也很充实，2015年会做更多基础平台完善和团队建设的事情。

2015年展望

1、老婆顺利考到驾照；

2、女儿健康快乐成长；

3、书架上的书能慢慢看完并消化；

4、2015年冠上了产品部经理的头衔，15年要带领团队好好做产品；

5、团队建设。

2013 年终总结

Sat, 22 Feb 2014 00:00:00 +0800

从毕业后几乎每年都会写一篇总结，而且习惯子农历的新年前写，在我的思想观念里，农历的新年才算过年。今年也不例外，不过由于一些原因推迟到年后了。还是从工作和生活两方面来总结下即将过去的2013年。记得去年的总结最后写的对2013年的展望是这样的：

能尽快的把驾照拿到手；
准备要小宝宝；
买车；
工资有所突破；
职位有所突破；
深入研究几种技术，性能优化为主。

除了第六条，其他的都已达成，还是比较欣慰的。

工作

去年利用业余时间做了一个工具，并在部门内使用起来，在年终获得了一些奖励。不知道是不是因为这个原因，今年年初的人才盘点我的职位被调成了Team Leader，公司的Team Leader主要职责是技术攻关和团队建设，而团队成员的积极性方面则不需要过多操心，因为有绩效制度在鞭策。

2013年夏天，一个做企业信息化的小公司希望我能加入他们，经过几次沟通后，我最终决定了加入这家小公司。之前的公司算的上是一个中型公司，在武汉这边的研发就有4、5百人，而且也基本上做到了行业老大的位子，部门老大对我也很不错，上升空间还是很大的，按理说我应该不会离开才对。但正是因为公司比较大，各种规范流程比较繁琐，而且还有很“不合理”的KPI考核，尽管每年都在做优化，每个人员都各司其职在条条框框内做事。这些方式方法的存在肯定有其道理，作为管理者来说，依赖这些规则可以节省成本，提高效率，但我却很不喜欢，所以我选择离开。

经过半个多月的交接，9月1日到新公司报道，在这里的自由度相对较大，也能做自己喜欢的事情，自己所学的东西在工作中能够得以施展。到现在已经近半年的时间，工作还是很开心的，希望能再接再厉。

生活

12年的一次错误决定，导致我现在得时不时的回家去，因为在家里报的驾校，起初的原因是户口在老家，而且当时老家的报名费比武汉要便宜1000多，现在看来真是得不偿失。体检得回去、科目一的测试得回去、科目一的考试得回去，当然这些都只是周末，最后发现到练车的时候不是仅仅周末回去就能解决的。无赖之下请了一个月的假回家专门学车，正值夏日，每天早出晚归，其实也只能练习5、6次，其余的时间都是在等待中，等待中的时间除了聊天还是聊天，驾校里会有形形色色的社会人或是学生，与人聊天或是听人聊天感觉也还不错。一个月的时间就这样机械化的度过了，也顺利的考过了科目2，最终10月份拿到驾照。

9月份的一次检查得知老婆怀孕，也没有什么特别的感觉，因为一直也在准备在事。之后老婆说能感觉到胎动的时候，我用手也能感觉到的时候，特别的兴奋，可能在这个时候才真正感觉到这个小生命的存在，之后的每天睡觉前，我都会和小宝宝说说话。让人欣慰的是从怀孕到现在的产检都比较正常，现在很期待在5月份看见宝宝的样子时的感觉。

2014展望

5月宝宝能顺利出生；
工作上能跟进一步；
持续学习，不局限于编程。

2012 年终总结

Wed, 16 Jan 2013 00:00:00 +0800

在我的2011年总结是以年度记事作为开头，2012虽然特别，但对我来说还算是比较平淡的一年，并没有很多事情发生，所以2012年的总结就以工作和生活两个方面来说。

怎样提高开发效率

Sun, 21 Oct 2012 00:00:00 +0800

前言

给你一个任务,限定5天内完成,如果你实际用了6天,可以说是开发效率不高,或者同样的一个任务,你花了6天,而你的同事却只用了4天,也可以说是你的开发效率不高,影响开发效率的因素有很多,下面就我个人的理解来谈谈怎样提高开发效率.

工具

俗话说，工欲善其事必先利其器，使用得心应手的工具必然会提高开发效率，做微软平台开发的肯定离不开VS，就VS本身来说，除了常用功能外一些常用的快捷键一定要能熟练运用，例如下面是我认为比较有用的几个快捷键：

注释： Ctrl + K + C
取消注释： Ctrl + K + U
全屏： Shift + Alt + Ente
设置标签： CTRL + K, CTRL + K
下一个、上一个标签： CTRL + K, CTRL + P 、CTRL + K, CTRL + P
列出成员： Ctrl + J
显示参数信息： Ctrl + Shift + Space
转到定义后返回： Ctrl + –

熟练使用快捷键对于代码编写的速率和跟踪代码的速率会有大大的提高。

有时候开发工具自身的功能受到了限制，这是就需要使用插件来丰富功能，这里推荐两款插件，VS中的ReSharper和SqlServer中的SQL prompt5，ReSharper是功能很强大的一个VS插件，但会拖慢VS的速度，就看怎么去权衡了，我在之前的博文《强大的VS插件—Resharper》做过简单介绍。SQL prompt5是SqlServer的一个插件，功能也非常强大，有很强的智能提示功能，所提供的SQL Search功能可以对数据库对象进行快速查找，还提供代码片段功能，在我之前的博文《SqlServer开发利器—SQL Prompt5》中也做过介绍。

除了我们每天都离不开的VS和SqlServer之外还有一些辅助的开发工具也可以来帮助我们来提高效率，我经常使用的有以下几种：

SqlDbx：很小巧的一款数据库管理工具，但功能非常强大，支持多种数据库，经常使用他的智能提示和生成脚本等功能，但也有缺点，对中文支持的不是很好；
Aptana：该工具可以说是做Web开发的利器了，我有时写JS会用到该工具，有一个亮点之处是智能提示能够显示不同浏览器是否支持；
Free Javascript Editor：可以很方便的写一些简单的HTML和JS代码并运行，可以直接选择JS的代码片段进行执行，对JS的调试也很方便。

还有一些其他的工具也非常有用，比如我在平时的工作中会经常用到Total Commander和Everything：

Total Commander：资源管理器的代替工具，支持多标签，可以很方便的对文件进行操作；
Everything：一款搜索工具，速度奇快，以前也做过介绍《软件推荐：磁盘搜索软件Everything》。

代码沉淀

有点规模的软件公司都会有自己的开发框架，这些框架都是多少年积累的产物，目的就是为了提高开发效率，作为一个开发人员平时对于一些常用的代码也应该有自己的沉淀，不光自己沉淀，在组内也应互相分享，记录这些沉淀的代码就可以根据自己的喜好了，记事本、Word、Excel、OneNote等都可以。沉淀的代码还可以使用VS的代码片段功能来进行管理，VS2010中对代码片段支持的很好，上面提到的SqlServer的插件SQL Prompt5也提供了数据库中的代码片段功能。

VS中给我们提供了很多现成的代码片段，要使用自定义的代码片段最方便的就是使用代码片段制作工具，工具点击此处下载，当然也可以自己创建代码片段文件，然后在VS中导入即可，代码片段文件其实就是一个xml格式的文件，后缀为snippet。

代码质量

代码质量好了，产生的bug就少，和测试的交互也就少了，也就不会因为前面产生的bug而影响后面的进度，效率自然就高了。代码质量可以分三个方面来看：

1 代码出错少，能够正常的运行；

主动学习，提升自我的编程技能；
勤思考，对干过的错要经常总结，一些规范性的原则要牢记，这些常常会出现一些低级错误；
一个任务做完后需要进行充分的自测。

2 代码的运行效率高，在大数据、高并发的时候能够高效运行；

高性能的开发得从点滴做起，不放过每一个细节，可能一个小的细节点就是一个性能的瓶颈；
要有重构代码的习惯，好的代码是重构出来的，高性能的代码也是重构出来的；
多学习一些原理性的知识，不光要知其然还是知其所以然，基础扎实了，一些性能的问题就知道怎么去优化了；
之前翻译过几篇关于C#代码简化的博文，参见《C#/Net代码精简优化技巧（1）》、《C#/Net代码精简优化技巧（2）》、《C#/Net代码精简优化技巧（3）》

3 代码最后的运行结果要和客户的要求一致；

做需求之前把自己的理解跟需求分析进行沟通看是否能达成一致，如果是直接和客户进行沟通可以先做出小Demo，然后给客户演示，根据反馈不断改进；
在做的过程中如果遇到有疑问的地方一定要和需求或客户进行沟通，不要根据自己的想法想当然的去进行代码编写；
必要的时候可以引导客户，我们的主要目的能以最有效的方式帮客户解决问题，不能盲目的按照客户的要求来，有时客户说需要一双雨鞋，可能一把伞就可以解决问题。同样对于需求分析写的文档，开发也需要有质疑的精神。

业务知识学习

做任何的系统都避免不了有业务背景，熟练的了解业务知识可以使我们更清楚的知道我们是在做什么。很多的开发人员可能只喜欢钻研技术，对业务往往没什么兴趣，代码写完了，可能还不知道做出的模块时做什么用的，这样写出来的代码的质量就可想而知了。

学习业务可能很枯燥，但却是一劳永逸的事情，所以不管是否有兴趣，还是应该硬着头皮啃下来；
小组内可以成立兴趣小组，探讨的方式来进行学习，互相分享各自的学习内容，关键是组内的氛围要搞起来；
如果是直接跟客户沟通，需要用客户能听懂的语言，比如图文配合或是一些小Demo，否则当开发术语碰上领域术语就可能都是在对牛弹琴了。

总之，作为一名开发人员，要时刻想着怎样来提高开发效率，开发效率的提高是你在工作中一个良性循环的开始。如果您有好的方法和建议，欢迎一起分享。

谈“绩效考核”

Mon, 23 Apr 2012 00:00:00 +0800

前言

在工作以来就职的几家公司中，目前就职的这家公司有非常完善的“绩效考核”制度。绩效工资大概占工资的百分之二十左右，绩效的最高系数为2，就是说如果你的工资的20%为2000，绩效最高可以拿到4000 ，当然很难达到最高的系数。公司推行“绩效考核”的这种制度出发点是刺激员工的积极性，同时也让表现好的员工能有好的回报，但我却发现了其中的一些“弊端”。

我们的绩效分为两个维度：业绩考核和行为态度考核。行为态度主要是实际工作中的一些突出事迹，成就客户之类的东西，如果不是和客户直接打交道的比如实施类的岗位，在行为态度上要想有所表现比较困难，所以本文将围绕业绩考核来谈，并且只针对开发岗。

业绩考核又分为很多的指标，每个指标根据完成的情况得到不同的分数（0、2、3、5），再根据每个指标占的不同比例算出业绩考核的总分，业绩考核的指标有：工作量，bug量和关键节点达成率。下面分别来说下这几个指标。

工作量

任务系统的任务都会评估出一个工作量，以天为单位。计算方法为在季度末算出整个季度中完成的工作量和总出勤天数的一个比例。表明上看这个指标非常好，公司不用怕员工偷懒，相反员工还会主动去找事情做，因为担心工作量不够。看上去挺好，但实际操作中却存在很多问题，有些时候两个工作之间不能很好的衔接，造成工作量的流失；有些时候由于需求不明确等问题需要反复沟通造成严重的内耗；有时候。这样就会造成这样一种现象，平时会发现公司里的人貌似都非常的忙，但到了季度末统计工作量时却发现还不够。

bug量

bug量的计算方法是一个季度所做的任务的有效bug量和所做任务的共走量的一个比例，最终算出每天的平均bug量是多少，再根据这个bug量来打分。设置bug量这个指标的初衷是为了提高开发人员的开发质量，减少测试与开发之间往返的消耗。但这个指标至少会带来两个弊端：

1 开发人员和测试人员的对立

2 事不关己，高高挂起

经常会在项目中发现一些不合理的代码，如果是在以前的公司，如果是出现在我负责的模块，我会进行重构，但现在我可能不会去碰那些代码，因为可能会带来更多的缺陷，而这些缺陷最终会记在我的头上，即便重构不会带来任何的风险，也没有人会关心这个，人们更多关心的是软件能不能正常的运行。正是由于这个指标的存在，随着时间的增长，项目中的坏味道会越来越多。

关键节点达成率

基本上任务系统中的每个任务都会设置关键节点，对于开发来说关键节点就是某个任务提交测试的时间点。计算方法是未超时的任务数和总任务数的比例。这项指标的初衷是保证开发的效率，但也带来了一些问题：

1 互帮互助少了

2 多任务的处理

当你正在处理设置了关键节点的任务的时候，突然来了一个紧急任务，可能是一个比较紧急的bug任务，如果是在以前的公司，肯定不会有什么顾虑，优先响应紧急的任务，手头正在做的事情就自然往后顺延了。但有了这个指标后就会担心我优先响应bug任务了，那手头正在做的超时了怎么办。

总结

很多公司没有绩效考核制度一样可以管理的很好，我个人也不是很喜欢这个绩效制度，我认为这个公司对员工的一种不信任。当然绩效制度如果使用合理也可以起到良性的作用，而且不同的公司应该制定适合自己公司的制度。制度就是一种约束，约束太多了总会让人感觉不爽，我认为最好的方式是领导能够利用自身的个人魅力感染员工，提升员工的责任感，很有幸我曾遇到过这样的领导，当时提倡的公司理念是“快乐工作，健康生活”，那段时间每天都很有激情，每天早上起来都很想去公司上班，但这样的公司和领导也是可遇不可求的。

2011 年终总结

Sat, 14 Jan 2012 00:00:00 +0800

2011年记事：

2月从北京返回武汉
3月进入一家做信息化的IT公司A
5月和老婆领证了
7月因A公司频繁出差，跳槽到了B公司
8月买房子
10月结婚 2011年对我老说是重要的一年，人生中的几个重大事情都发生在这一年。

回武汉

在北京呆了还不到一年的时间，按照之前的计划本不应该选择在2011年初回武汉的，但因为计划2011年结婚，婚前必然有很多的事情要准备，所以经过多方面考虑还是决定2011年回武汉，这次回了就是要定居武汉了。

进入公司A

选择回到武汉，那么回来后的工作是首要问题，经过朋友介绍谈好了一家做企业信息化的公司，电话中沟通过几次，后来回到武汉去公司和开发部的经理以及公司老总进行了面谈，双方感觉还不错，3月份顺利入职。可能是之前沟通的不够充分，入职后发现后想象的不一样，频繁的出差让我不能接受，可能有些朋友喜欢出差，但对于即将结婚的我确实不太适合。再三考虑之后我提出了离职，老板和部门经理强力挽留，说把我调回到武汉的一个项目中，不用去外地，但我的态度很坚决，最终还是辞了。因为即使这个项目在武汉，下一个可能有得去外地了。对于这次离职我心里感觉不是很舒服，毕竟老板和部门经理对我不错，而且也极力挽留，只能说我的需求和公司的特点不适合。

领证

5月20日是老婆定的，也算是一个比较有纪念意义的日子。关于领证那天发生的事情，请看-纪念日-领证

进入公司B

其实在公司A的后半段我就已经将51上的简历更新了，随后就接到了很多公司的面试电话，基本上都被我推掉了，最终也就面试公司B一家，之前对B公司也有一定的了解，而且以前有同事在B公司也跟我介绍了一些情况，面试顺利通过，但由于面试是发挥的不是很好，薪资还不如在A公司的。之所以选择B公司有以下三个原因：

1 公司规模大，开发流程规范；
2 不用出差；
3 每周公司都有篮球活动。

买房子

老婆一直都想买市区的房子，比如软件园附近的。我们也去看过“锦绣龙城”的房子，那会二手的毛坯房也得6000多一平，这个价格在武汉来说也不算很贵了，但算下来交首付然后每个月几千的还贷压力还是不小。经过一番周折最终买的是老婆亲戚家还建的房子，离市区稍微远了点，但价格便宜。还不到3000一平，80平的房子也就在市里买房的一个首付。老婆后来一直都抱怨说应该买市里的房子，嫌那个太偏了，不过我倒是觉得挺好：

1 到鲁巷的车程也就20多分钟；
2 离老婆家很近；
3 不远的地方就是一个高速的入口，如果有车走高速1个小时我就可以回家了；
4 买这房子压力相对小，以后买车就变得现实了。

买房子期间老婆家里人忙前忙后帮了很多忙，真的是非常感谢。也请老婆放心，我会努力赚钱早日买车，这样你就不会嫌远了。

结婚

结婚是在10月3号，所以去了不少同学，为了热闹还请了我们市里面的婚庆公司来策划。对于我们那小地方来说也算是不错的了。有关结婚的详细情况，请看-结婚小记，婚后我和老婆去的三亚度的蜜月，这可能是很多新人在国内蜜月的首选，我们也没能免俗。蜜月1–我的蜜月之旅

这就是我的2011，经历了很多事情，一年下来忙碌而充实着，人也成熟了很多，期待更精彩的2012。

回顾2010 计划2011

Wed, 05 Jan 2011 00:00:00 +0800

2010年对于我来说是不平凡的一年。

2010年我脱离了单身，找到了属于我的幸福。

2010年我不远千里从武汉来到北京，一方面寻求事业上的发展，同时和小妹也算有个照应。

2010年3月2号是个很特别的日子，就是在这一天我脱离了单身。也是在这一天我们相聚又别离了，我来了北京，她仍在武汉。1个月后我在北京西站接到了她，从此便开始了近一年的甜蜜蜗居生活。

北京的工作相对于武汉来说有更多的机会，所以找工作还算比较顺利，两个星期的东奔西跑迎来了3份offer，再三思考权衡之下选择了工资不是最高但最有发展最能学习技术的公司留下了，也就是现在就职的公司。

在公司的8个月的时间里也发生了不少事情，第一个项目的搁置、长达一个月时间的无事可做、换项目组、头的离职乃至公司内部的一些变动，尽管这些让人感觉有些动荡，但也学习到了很多，并且公司的一些制度还是非常人性化，弹性时间的上下班，平时有事请假可以算到日后调休等等。所以我还是很希望自己能在这里长期待下去。

2010端午节老婆的姐弟来北京玩，短短几天的时间跑遍了很多地方，很累但很难忘。

2010年国庆节我们为了一张回家的车票起很早去排队，最终还是不得不请了3天的假提前回家。这次是离开学校后离家最长的一次，所以回家的心情也格外激动。还有件更重要的事情就是十一要去老婆家上门，还好整个过程非常顺利。

总体看来2010年还算是比较顺利，顺利让女友来北京；自己顺利找到工作；幸运的找到现在所租的房子；国庆顺利的上门，年底顺利的买空间域名搭建我和老婆的小窝。希望在2011年各方面能做的更好。

2011年对我来说是充满期待的一年。 2011年我将会走进婚姻的殿堂，延续我的幸福。

2011年我也许会从北京回到武汉，找个稳定的工作，过上稳定的生活，当然仅仅是也许。

2010年很多事看上去很顺，但缺少规划，一切都是按部就班，顺其自然的在进行，这个主要是指技术学习方面。所以2011年在技术学习上要有计划，基本要按照计划来执行，比如学习一门动态语言Python，学习一门函数式语言F#等。

2011年应该是很忙碌的一年，春节后可能面临着工作的变动，五六月份要和老婆去照结婚照，10月举行婚礼，希望这些都能顺顺利利。

2011年对于技术的学习，大致规划如下，具体可能根据实际情况做相应调整。

学习Python
学习F#
关注软件架构方面研究（涉及设计模式、并发、性能等）
根据需要学习DotNet相关的框架
所买的书争取看完，关键是要吃透

写于2011年1月5日北京天通苑

程序员怎样学习英语

Sat, 28 Nov 2009 00:00:00 +0800

英语的重要性已经毋庸置疑，对于程序员来说更甚，一些最新的技术资料是英文的，如果想进入外企英语也是一个很重要的条件。对于程序员来说怎样学习好英语，在此谈一下我的一些学习经验。希望对英语像我这样不怎么好的朋友有所帮助，也欢迎大家提出意见和建议。

英语的学习不外乎“听说读写”，按照通常的英语学习来说“听说读写”这个顺序是有道理的，语言最大的用处就是用来交流，听说排在首位无可厚非。不过对于程序员来说我认为读应该是最重要的，良好的阅读能力对于我们查阅资料、使用一些英文软件、订阅国外大牛的blog都会带来很大的方便。我个人将英语的学习分为三个步骤：单词、阅读、听说，下面分别来说一下。

单词

单词英语学习的基础，上学时记单词总是抱着本四六级之类的字典，从A开始往后记，这样很费时间而且也没有针对性。对于工作了的朋友来说时间应该不会像在学习时那样多了，在业余的时间要关注新的技术，有的人可能还会接点私活，挤点时间出来了可能还要陪老婆逛逛街，所以不太可能每天专门抽出固定时间来记单词。我的做法是利用每天的若个的“小时间”，这个“小时间”是指上班的公交车上或地铁上（在车上有座就看书没座就记单词），上下班的路上时间可能很长，这个时间可是很宝贵的，不能浪费了。类似这样的“小时间”每天会有很多，这个因人而异。至于单词的来源我都是在看英文资料，博客，等的时候出现不认识的我都会记在一个小的便签本上，这个本随身携带，所有的“小时间”都可以拿出来看上一眼，像我每天晚上都会去健身房，有的人在跑步机上会听音乐看电视，而我在边跑步时也会不时掏出小本看一下，二十几分钟下来也能记住不少。很多人都说没有时间，我觉得只要肯挤总会有的。

阅读

阅读我主要是看一些国外技术网站，博客，还有就是一些原版的技术书籍，不过看英文书籍的时候不多，主要原因还是水平不够，所以还是以博客为主。就像上面所说的遇到不认识的单词我会记到便签本上，然后在每天的“小时间”去搞定。对于英文的东西，很多人会有抵触心理，当初我注册Twitter的时候，一看全是英文的，也差点就直接点关闭了，不过最终还是注册并使用了，现在也很适应那种全英文的界面了。所以说适应是很重要的，随着词汇量的增大，会发现看懂英文的文档或博客文章没有想象的那样难。

听说

听说才是语言的根本，在这里却排在了后面，因为在很多的程序员的工作中，更多的是需要查阅英文的资料或文档，而实际用英语来交流的相对较少。但是如果在您有很好技术的同时还够讲一口流利的英语，那肯定会使您在职业生涯中获得更多的机会。我很喜欢看美剧，所以理所当然“听说”我也是从美剧入手，《老友记》是用来练习口语的一个很不错的片子，够长也够生活化。第一遍用中文字幕，先了解大概故事内容，然后就可以使用英文字幕看了，并记录常用的语句，同样还是利用“小时间”去记住它。光记住了还不行，得开口说，如果没有对话环境就自己对着镜子练吧。相信看完10季的《老友记》看完听说的能力一定会提升一个台阶的。当然看视频时很费时间的，这个得每天抽出点时间来看。不要舍不得那点时间，听说能力练好了，老赵辛苦上传的那些视频我们就能享受到了。

总结

上面说了一些自己的一些学习方法，目前来看利用“小时间”记单词的方法是很有效的。其实每个人都有适合自己的学习方法，关键就是是否能持续学下去，坚持下去。如果您有什么好的学习方法欢迎和大家分享。