C++ 传参时传内置类型时用传值(pass by value)方式效率较高
这篇文章从《Effective C++》的经典条款出发，深入探讨了一个C++开发者常感困惑的问题：函数传参时，应该用传值（pass by value）还是传引用（pass by reference）？作者指出，这个选择并非一概而论，而是取决于参数的类型——文章特别对比了内置类型（如int、指针）与自定义类型之间的行为差异。 为了验证这一结论，文章提供了清晰的代码示例和关键的汇编代码对比。核心发现在于：对于int这类内置类型，传值（`int f(int i)`）编译生成的x86汇编指令更简洁，参数直接通过寄存器传递，效率最高；而传常量引用（`int g(const int &i)`）则多了一次内存间接访问的步骤，尽管微小但在极热路径上可能产生影响。文章也点明了反向情况：当面对存在构造与析构开销的自定义类型时，传引用才能避免不必要的复制成本。此外，STL中的迭代器与函数对象本质上是指针，因此遵循内置类型的规则。 作者通过这次代码级的验证，不仅重申了一个有效的实践准则，更通过底层视角加深了理解：效率的考量必须结合类型特性。这提醒我们，在追求代码“优雅”的同时，也不应忽视特定场景下符合硬件行为的朴素写法所带来的切实性能收益。
struct与class区别联系
这篇讲的是C和C++中`struct`这个看似相同的关键字，其实内核大不相同。作者开篇就指出了核心区别：C中的`struct`是“原生”的，仅仅用来将一组属性打包成一个整体，没有任何面向对象（OO）的特性。而C++中的`struct`则是在此基础上做了深度扩展，它完全兼容C的用法，但更重要的是具备了OO特性——事实上，C++中`class`能干的事情，`struct`几乎都能干，包括继承和多态。 文章通过一个直观的代码示例验证了这一点：如果在纯C环境下（例如用GCC的C模式编译），在`struct`内部直接定义成员函数会导致编译报错；但同样的代码在C++中则毫无问题。这生动地说明了“原生”与“扩展”的差异。 那么，在C++中`struct`和`class`到底还有何区别？唯一的、关键的不同在于默认的访问权限：`struct`默认是`public`，而`class`默认是`private`。这个细微差别决定了代码风格和设计意图。通常，我们用`struct`来封装纯数据的聚合体，而用`class`来定义那些需要隐藏实现细节、提供接口的抽象数据类型。这篇小文通过对比和代码解析，清晰地帮你厘清了这个C++程序员常会遇到的疑惑。
代码审查清单可消除更多的bug
这篇文章的核心主张是：在代码审查中引入并维护一份“检查清单”，能系统性地提升发现缺陷的效率，从而消除更多潜在的bug。 作者开篇就指出问题的普遍性：软件工程协会的研究表明，程序员常犯的错误集中在15-20种。因此，如果在审查时依赖纯粹的个人经验，这些常见问题就很容易被遗漏。清单的作用，正是将这些高频错误固化下来，确保每一次审查都能覆盖到这些关键点。 文章提供了一份经典的清单模板，涵盖了从“总体”（代码功能、可读性、规范、冗余）到“安全”（输入输出校验）、“文档”和“测试”等多个维度的具体检查项。它强调清单不必大而全，应聚焦于团队实际发生的常见问题。 更关键的是，清单并非一成不变。作者建议团队在实际审查中记录遇到的问题，以此作为数据来优化自己的清单，剔除不相关的项目，加入特有问题。通过这种集思广益和定期更新的方式，清单会越来越贴合团队实际。 最终，一个经过优化的、具体的清单，能帮助团队在审查中稳定地捕获更多瑕疵，避免审查质量因人而异，从而实质性地提升代码质量。
我的git笔记
这篇讲的是作者从 SVN 转向 Git 并深度使用后，沉淀下来的一份实用命令手册。作者从两年前通过《GotGitHub》入门 GitHub 讲起，分享了自己从最初使用 GitHub for Windows 图形客户端被自动换行符问题困扰，到后来通过学习《Git详解》系列文章转入命令行的进阶过程。 如今作者已在 GitHub 上开源了 60 多个项目，为了在这些项目间高效穿梭，也为了自己“用时能快速查阅”，他系统地梳理了 Git 的常用命令。文章按使用场景分类，涵盖了安装配置、新建与克隆仓库、本地文件增删改查、分支的创建合并与变基、远端操作、多源管理以及标签管理等方方面面。 特别值得一提的是，作者不仅列出了核心命令，还补充了像 `git revert` 和 `git stash` 这样实用但容易记混的操作细节，并在最后附上了包括《Pro Git》、《图解Git》在内的八份经典参考资料。整篇文章就像一个经验丰富的开发者在跟你分享他的“私人笔记”，对于需要快速回顾或查询 Git 命令的读者来说，是一份非常顺手的速查指南。
调试工具之GDB
这是一篇关于调试利器GDB的实用指南。不同于常见的C/C++调试教程，这篇文章特别展示了如何用GDB调试PHP脚本，视角相当独特。 文章从GDB的安装讲起，涵盖了yum、rpm包以及从源码编译这几种常见方式。核心部分围绕一个具体的PHP示例展开，详细演示了启动GDB、设置参数、执行脚本的完整流程。其中亮点是两种高级断点设置方法：可以通过“文件名:行号”精确定位，比如“basic_functions.c:4439”，直接跳到PHP内置函数`sleep`在内核C代码中的实现点；也可以仅用函数名“zif_sleep”来设置断点，这在没有源码行号时尤为方便。文章还介绍了通过`help`命令自助查询GDB的庞大指令集。 作者通过这个实例，清晰地展现了GDB强大的通用调试能力。它不仅是C程序的调试器，更是一个能深入任何用C语言编写（或内嵌C）的运行时环境的强大工具。对于需要调试PHP内核、扩展或性能问题的开发者来说，这篇文章提供了一个极具价值的实践起点。
关于创业
这篇是前腾讯员工离职创业一年半后的真实记录。作者从自己开发的PC应用因“店大欺客”被腾讯连续下线、收入断档讲起，详细复盘了寻找新方向的全过程。 他从一封封读者来信中敏锐地捕捉到“海外Android工具应用”的机会，并凭借技术优势，两个月量产了50多款应用，迅速实现盈利。然而，创业之路并非坦途。当应用重心转向国内安卓市场后，作者再次遭遇平台巨头的挤压——Google Play因其不熟悉政策封禁账号，360平台则在审核通过后，以“刷榜”和违规广告为由进行处罚，甚至开始强制使用自家广告联盟。 文章的核心，是作者作为开发者，与平台巨头合作时切身的无奈与观察。他揭示了小体量开发者在庞大生态中的脆弱地位：无论海外还是国内，平台规则的模糊与单方面变更，都可能让积累的成果瞬间归零。这段经历为所有考虑进入移动应用生态的创业者，提供了一份极具参考价值的避坑指南与现实注解。
如何构建优质代码
这篇讲的是如何编写出高质量、易维护的代码。作者从实际工程经验出发，总结了10条核心原则。 他开篇就强调了DRY（不要重复自己）的重要性，并举了单元测试中违反此原则会导致维护成本剧增的例子。文章还指出，写出短小的方法、采用能“望文生义”的命名规范，能让代码更易读和重用。 在设计层面，文章建议让每个类只承担“正确的”职责，并注重接口的稳定性而非实现细节。为了保障质量，作者大力推荐编写大量的单元测试，并以此为安全网，进行小步、持续的代码重构。 最后，他提到了一个颇具争议的观点：比起写糟糕的注释，不如花时间重构代码使其更清晰。同时，强调了代码审查机制对于发现错误和共享知识的价值，但要求审查者能力合格，并对代码负责。 这些原则共同指向一个目标：编写出更健康、更易于协作和演进的软件。
一个程序员的管理思考
这篇讲的是一位有两年管理经验的程序员，回顾了自己从带领小团队到推动30人团队时所经历的深刻转变与思考。作者认为，管理本质上是“管”结果与“理”过程的结合。随着团队规模扩大，管理者必须从早期身先士卒的“带领者”，转变为更多依靠机制和授权的“推动者”，甚至要达到“在与不在一个样”的境界。 文章的一个核心观点是将管理与技术架构进行类比。就像技术积累需要将解决方案抽象为框架和平台一样，管理也需要对具体问题进行抽象，形成可复制的规范、流程等“术”。更进一步，“术”的制定应由团队“道”层面的价值观来指导，例如作者团队基于“简单、直接、信任、效率”的价值观，推行了保障开发效率的会议规范。 作者也坦诚，实现让团队成员能站在自己角度思考问题的“双向同理心”是一条漫长之路。文中通过让开发轮流处理用户反馈来提升质量意识的实例，生动说明了如何将价值观落地为具体实践。对于正处于技术向管理转型期的读者而言，这些源自一线实践的观察与抽象思考，提供了非常具体的参照。
python数组使用说明
这篇文章系统梳理了Python中三种常用的序列类型：list、Tuple和Dictionary，并详细讲解了它们各自的定义方法、核心技巧与常用API。 文章首先厘清了三者的基本特性：list是动态链表，初始化后可以灵活增减元素；Tuple是固定长度的元组，一旦定义便不可更改；Dictionary则是基于键值对的哈希表，提供快速的数据检索能力。随后，作者分别深入展示了每种类型的具体用法。 对于list，文章重点演示了如何通过索引切片获取或删除多个元素，如何利用enumerate高效遍历，以及append、insert、pop等关键操作方法，还特别提示了列表复制时的引用与克隆区别。Tuple部分则简明介绍了其初始化、访问以及与列表的相互转换。Dictionary章节聚焦于其丰富的内置方法，如get提供安全的键值获取、keys/values/items用于遍历、update用于合并字典等，并说明了如何为同一个键赋值多个值。 这些内容的讲解都附带了清晰的代码示例，非常实用。文章最后帮助读者理解：当你需要动态调整集合内容时，list是首选；当需要确保数据不被意外修改时，可选Tuple；而当需要基于唯一标识快速查找数据时，Dictionary则最为高效。
树莓派（Raspberry Pi）使用小记
这篇讲的是一位硬件门外汉从零开始折腾树莓派（Model B+）的实战记录。作者从淘宝采购全套配件讲起，详细分享了在Mac和Windows双系统下烧录Raspbian镜像时遇到的卡点（比如读卡器识别问题），并给出了具体的解决方案。 文章的核心价值在于其“踩坑”后的经验提炼：作者强烈建议先组装好亚克力外壳再连接网线，以保证连接稳定；在配置无线网卡环节，他指出若执行常规的`ifup wlan0`命令无效，可以尝试用`sudo /etc/init.d/networking restart`重启网络服务，并附上了亲测有效的配置教程链接。 整个流程从SSH首次登录（默认用户名pi/raspberry）、运行`raspi-config`扩展分区与修改密码，到最终实现无线网络连接，步骤清晰，提供了路由器后台查IP、终端命令操作等具体截图。对于想低成本上手Linux硬件开发的爱好者，这些从自身实践中总结的细节和排障思路，能有效缩短点亮树莓派的摸索过程。
一个程序员眼中的价值
这篇文章记录了一位资深程序员从2007年到2014年的职业反思。作者从自己雅虎实习、百度工作、参与PHP开发等经历出发，探讨了他所理解的“价值”。 他分享了几个关键阶段：刚毕业时，从优先考虑学习到认识到基本生活保障的重要性；工作几年后，因赞誉而自满，后来才看清自己的技术短板；在开源社区中，接受受助者的感谢礼物让他体会到创造的价值。最突出的是在微博和PHP社区的贡献，例如将无线LAMP性能提升2.6倍、参与推动PHP7的性能飞跃，这些实际成果为他赢得了尊重。 作者的结论很实在：程序员的真正价值，在于你为公司和他人创造了多大的实际贡献。如果能做出有价值的贡献，相应的肯定会随之而来，或早或晚。相反，如果只盯着自己得到了什么，忽略了付出的价值，路会走得很辛苦。
我所经历的盛大创新院
这篇是作者对盛大创新院一段职业生涯的回顾与反思。他从一个对盛大了解甚少的工程师视角切入，描述了创新院初创期（2010年前后）的独特氛围：独立的办公空间、平等的技术文化、温和的项目孵化机制，以及以院长“老郭”为代表的细致管理。文中生动刻画了“梁山好汉”般的团队群像和像“锦书”电子阅读器这样刻骨铭心的项目冲刺。 作者的核心观点在于，创新院初期的成功源于其“孵化”定位和宽松环境，但后期在规模扩张和集团战略介入后，逐渐转向“主导创新”，带来了更严格的项目管理和组织架构分化。他观察到，当创新背负明确短期压力时，其独立性与活力便难以维持。通过对比“万能钥匙”等小团队自发项目与后期各分院任务型项目的不同境遇，作者提出了对“创新”本质的思考：真正的创新常源自小团队的自主驱动，而非机构的规模化生产。 这段经历让作者深刻体会到时机、市场“范式升级”以及企业创新机制设计的复杂性。对于技术从业者而言，文章提供了一个观察大公司创新组织从孕育到演变的珍贵样本，也引发了关于如何在体制内保持创新活力的普遍性讨论。
无插件Vim编程技巧
这篇讲的是如何在不安装任何插件的前提下，充分利用 Vim 7.2 原生功能来提升编程效率。作者从解决“多文件管理与导航”这个日常痛点出发，详细分享了他的一系列实战技巧。 文章首先介绍了用 `:E` 命令直接浏览文件目录，并使用 `j/k` 键导航，告别在多个终端窗口间来回切换的低效方式。接着，深入讲解了“缓冲区”这一核心概念：通过 `:ls` 查看所有已打开文件，并用 `:buffer` 命令及其缩写在不同文件间快速跳转。 对于需要并排对比代码的场景，作者推荐了使用 `:He` 和 `:Ve` 命令进行分屏浏览目录的技巧，并配合 `Ctrl+W` 组合键在分屏间灵活切换。更进阶的玩法是，用 `:set scb` 命令能实现两个分屏窗口的同步滚动，非常适合代码对比。 除了分屏，文章还介绍了用 `:Te` 命令开启类似浏览器的标签页浏览，并使用 `gt` / `gT` 等快捷键在多个标签页之间切换。最后，作者分享了如何用 `:mksession` 命令保存当前的窗口布局和文件状态，以便下次用 `vim -S` 一键恢复工作环境。 整篇文章没有泛泛而谈，而是将每个功能点都落实到具体命令和操作界面，真正展示了 Vim 强大的内建能力。掌握这些原生技巧，能让你在不依赖插件的情况下，把 Vim 的多文件工作环境打理得更顺手。
等宽字体：程序员的字体
这篇文章汇集了程序员编码和阅读代码时的“利器”——等宽字体。由于字符宽度统一，这类字体能带来工整的视觉排布，有效减轻长时间阅读代码的疲劳感，甚至对强迫症患者也相当友好。 作者从实用性出发，一口气列举了二十款常见的等宽字体，并附上了直观的字符效果预览图。这些字体风格各异，从经典稳重的 Courier New、Consolas，到设计现代的 Source Code Pro、Inconsolata，再到颇具个性的像素字体 Telegrama，几乎涵盖了主流选择。文章最后还给出了作者的个人偏好，认为视觉效果出众的有 Courier New、DialogInput 等几款。 对于正在寻找或更换编程字体的开发者来说，这篇文章提供了一个清晰的起点和直接的视觉参考，末尾附上的字体资源包也相当实用。
memory prefetch浅析
作者在用VTune分析程序性能时，发现大数组的非连续访问成为了CPU热点。经过排查，主要原因是这类访问模式对CPU缓存（Cache）很不友好，导致了大量的缓存未命中，从而拖累了性能。 为了优化这个问题，作者引入了x86架构提供的`prefetch`系列指令。其核心思想是，在程序真正用到数据之前，提前将指定地址的内存数据预取到各级缓存中，从而“掩盖”掉后续访问时的内存延迟。 文中提供了一段详细的测试代码，通过控制内存访问模式（顺序或跳跃）和计算复杂度，量化对比了预取指令的效果。测试数据显示，在跳跃访问内存导致性能严重下降的情况下（例如从22秒涨到66秒），加入恰当的预取操作后，执行时间基本恢复到了顺序访问时的水平（约28秒）。这直观地证明了预取指令在特定场景下能有效隐藏内存访问开销。 文章最终总结出prefetch的适用边界：当程序同时存在可观的内存访问延迟和一定的计算开销时，预取能有效提升性能。但如果计算本身很轻量，或者数据本身已在缓存中（如顺序访问），单纯依靠预取来加速读内存的意义则不大。
mac安装svn
这篇文章分享了在 Mac 上安装和配置 Subversion 时典型的“踩坑”经历与最终的最优解。作者最初发现系统自带的 SVN 1.6 版本过低，于是手动升级到 1.8.8，却接连遇到了不支持 http 协议（需从 neon 切换到 serf 依赖）以及在 Zend Studio 中找不到 javahl 插件等问题。一番折腾后才发现，之前的手动升级操作其实多此一举。 文章最终推荐的“直路”方案，是利用 Homebrew 包管理器。通过几条关键命令——安装 Homebrew、更新、然后使用 `brew install --universal --java subversion`——就能一次性完成最新版 SVN 和 JavaHL 绑定的安装。随后，只需创建一个库文件的软链接，即可无缝集成到开发环境（如 Zend Studio）中。文中也附带了手动编译安装的完整步骤和常见报错的解决方法。 对于被 Mac 上 SVN 安装问题困扰的开发者来说，这篇文章提供了从错误路径到正确路径的完整对照。它清晰地指出，利用包管理工具自动化处理依赖和环境配置，是避免繁琐依赖调试（如 neon/serf、autoconf、xctoolchain）和版本冲突的高效途径。
建立学习型组织
这篇文章从技术管理者的一个常见困境出发：升任领导后，如何在忙于管理的同时不丢失技术根基？作者余晟通过自身CTO经验，指出核心在于将“个人学习”升级为“组织学习”。 文章提出，技术管理者需要通过宏观视野和关键决策保持技术水准，但这与日常团队管理存在天然矛盾。解法是打造一个“学习型组织”：通过招聘高潜质员工、将技术分享纳入KPI、组织跨团队难题攻关、鼓励前沿探索等一系列机制，在团队内营造开放、互助的学习文化。 如此一来，整个团队便成了管理者的“延伸大脑”。管理者无需单打独斗，只需引导方向并深度追问，就能持续获取技术洞察；团队成员则在此过程中拓宽视野、激发钻研精神。文章最终揭示了一个更深层的视角：卓越的团队本身就是管理者技术能力的最佳放大器，团队的学习力与管理者的技术领导力实为一体两面。
程序人生的四个象限和两条主线
作者从自己的创业经历和与程序员们的交流出发，发现大多数技术人员的职业路径其实存在共通的模式。文章借用《穷爸爸富爸爸》的四个象限框架，解读了程序员可能处的不同阶段：从风险最小的E象限（雇员），到追求自由与收益的S象限（自由职业/小企业主），再到以规模化为目标的B象限（创业或成为上市CTO），以及最终追求财务自由的I象限（投资者）。 但真正驱动前进的，是个人成长。作者重点剖析了两条核心成长主线：技术线和管理线。选择技术线，关键在于看准并长期投入一个有潜力的技术方向。作者以自身从PHP开发受益的经历为例，强调了观察技术潮流（如多屏时代对API和云存储的需求）以及投资新兴或细分市场（如早期学习iOS、或结合安全深耕PHP）的重要性。 而管理线则更像一场持续的升级游戏，title和阶段性成果至关重要。作者直言，在利用关系普遍的职场，必须主动为自己规划。通过有策略的跳槽（间隔2-3年）来争取更好的空间、资源和职级，是实现从工程师到CTO跃迁的常见路径。文章最后以身边同事的案例，点出了自我规划的现实必要性。
那些和钱有关的事
这篇讲的是作者从腾讯离职创业后，对“钱”与“时间、服务、投资和决策”关系的深刻复盘。他通过自己装机、砍价外包、选择投资人、激励团队等亲身经历，提炼出几个反常识却至关重要的观点。 文章首先点破了“时间就是金钱”的真切感——为自己工作后，才发现半天时间创造的价值远超100块装机费。接着通过美术外包质量翻车的例子，揭示出购买服务时一味压价的陷阱：好服务的价格直接决定投入度与质量。在寻找投资时，他强调“拿谁的钱”比“有没有钱”更重要，价值观契合与避免“站队”是关键考量。最终，他总结出创业最大的挑战是如何“正确地花钱”，并用两个案例佐证：一笔额外的派驻费用解决了协作瓶颈，而一个镌刻名字的iPad比现金奖金带来了更好的团队激励效果。 对于正在创业或面临资源决策的读者，这些用真金白银换来的教训，提供了关于成本、价值和团队动力的务实视角。
emacs改变人生
这是一篇典型的个人观点与经验分享类文章。作者从自己从vim转向Emacs的经历出发，坦承标题“改变人生”带有夸张成分，但通过深入学习的过程，他重新诠释了“装逼”的正面内涵：即一种持续钻研、不安于现状的“折腾”精神。 作者详细描述了Emacs入门时面临的配置复杂、快捷键繁多等挑战，并以此引申出核心观点：在知识高度细分的现代社会，精深比泛学更重要。他认为，Emacs所代表的“折腾”过程——不断挖掘疑问、动手解决问题、打造个性化工作流——正是培养这种专精能力的体现。这种精神能带来持续的新鲜感，避免固步自封。 文章进一步将这种个人技能的学习，与理解世界运行的法则联系起来。作者以科技企业家多为程序员出身为例，指出通过编程（如同配置Emacs）制定规则的过程，也是构建个人认知系统、理解万物法则的方式。最终，文章以呼吁“不要放弃挣扎”收尾，将技术学习提升到了人生态度的层面。