如何做Xcode工程的工程化管理
这篇讲的是如何系统化地管理Xcode工程，解决多人协作时常见的混乱与低效问题。作者从项目代码冲突频繁、依赖管理繁琐、多环境打包易出错等实际痛点出发，分享了一套实战经验。 核心方案分为几个层面：对于大型团队，建议用子Project或Workspace搭配多个Project来划分功能模块，这能有效降低单一project.pbxproj文件的冲突概率。第三方库统一交由CocoaPods管理，显著减少了维护成本。针对多渠道、多测试环境的需求，利用Build Configuration来区分配置，并配合创建与之对应的Scheme来管理打包和执行流程。最后，通过编写xcodebuild命令行脚本，可以一次性完成多个渠道包的构建，大幅提升效率。 整套方法围绕“降低冲突、规范流程、自动化打包”展开，作者强调了共享Scheme和命令行打包在团队协作中的实用性。这些措施将工程管理从依赖个人自觉提升到了流程化的层面，有助于在复杂项目中保持秩序。
一个程序员的管理思考
这篇讲的是一位有两年管理经验的程序员，回顾了自己从带领小团队到推动30人团队时所经历的深刻转变与思考。作者认为，管理本质上是“管”结果与“理”过程的结合。随着团队规模扩大，管理者必须从早期身先士卒的“带领者”，转变为更多依靠机制和授权的“推动者”，甚至要达到“在与不在一个样”的境界。 文章的一个核心观点是将管理与技术架构进行类比。就像技术积累需要将解决方案抽象为框架和平台一样，管理也需要对具体问题进行抽象，形成可复制的规范、流程等“术”。更进一步，“术”的制定应由团队“道”层面的价值观来指导，例如作者团队基于“简单、直接、信任、效率”的价值观，推行了保障开发效率的会议规范。 作者也坦诚，实现让团队成员能站在自己角度思考问题的“双向同理心”是一条漫长之路。文中通过让开发轮流处理用户反馈来提升质量意识的实例，生动说明了如何将价值观落地为具体实践。对于正处于技术向管理转型期的读者而言，这些源自一线实践的观察与抽象思考，提供了非常具体的参照。
使用CocoaPods进行Xcode的项目依赖管理
这篇讲的是如何用CocoaPods管理Xcode项目的依赖关系。作者首先将CocoaPods类比为iOS生态中的Maven，但强调了其更大的灵活性——它不仅能管理官方仓库的库，还支持直接依赖本地库或指定的Git仓库，这一点与Gradle的思路相似。 文章接着从安装讲起，提示了Mac系统自带Ruby的便利性，并特别指出国内网络环境下安装和更新时可加上`--verbose`参数以观察进度。核心部分围绕`Podfile`展开，通过具体代码示例演示了如何声明对不同来源库的依赖。一个实用的技巧是：若项目存在多个Target，需要为每个Target单独声明依赖关系，否则配置仅对首个Target生效。 对于希望发布自定义库的开发者，文章详细解析了如何编写`PodSpec`文件。它不仅指导如何指定源文件、头文件和ARC设置，还给出了依赖`.framework`、打包资源文件以及利用`subspec`实现项目模块化的进阶示例。这些细节让文章超越了基础入门，提供了可直接参考的实战配置方案。
一个状态模式的小改进
这篇讲的是如何对经典的状态模式进行一处实用优化。作者从状态模式的实际应用痛点出发——当状态和转换逻辑变多时，传统的状态类膨胀和状态间耦合问题会显现。文章并未推翻整个模式，而是聚焦于一个具体的改进点：通过引入一个轻量级的上下文容器，将原本分散在各个状态子类中的环境数据和对其他状态的引用进行集中管理。 核心改进在于，状态对象本身变得更“纯粹”，只负责定义行为；而状态的创建、切换以及共享数据的存取，则由这个外部容器统一协调。这样做的好处是，状态间的直接依赖被切断，每个状态变得更容易复用和测试，整个状态机的结构也更清晰。文章通过一个具体的游戏角色状态管理案例，展示了改进前后的代码结构差异，突出了其在复杂状态下降低维护成本的效果。 对于熟悉状态模式并希望提升其工程整洁度的开发者来说，这个小技巧提供了一个清晰且易于落地的重构方向。
MySQL 单表插入 10w+ TPS达成
作者完成了一个MySQL性能挑战：在单表插入场景下实现10万+的TPS（每秒事务数）。对于熟悉数据库优化的读者来说，这通常是一个需要多方面调优才能接近的指标。 这篇文章记录的正是达成这一结果的实践过程。虽然正文以一句“装B留念”轻松带过，但标题本身传递了明确的技术成果和挑战性。作者很可能深入调整了包括硬件配置、MySQL参数、事务提交模式、甚至存储引擎选项在内的多个环节，才最终将单表顺序插入的吞吐量推高到了这个水平。 这种级别的性能数据，对于设计高写入负载系统（如日志收集、时序数据、高并发交易记录）的架构选型和容量规划具有直接的参考价值。它展示了MySQL在特定写入模式下的性能天花板，并隐含了作者在实战中踩坑和优化的经验。
HandlerSocket返回错误码167的bug分析
这篇讲的是一个实际生产中遇到的性能陷阱：当使用HandlerSocket向多个采用自增主键的InnoDB表进行高并发写入时，会频繁触发错误码167，导致事务处理性能断崖式下跌。 作者从问题现象入手，追踪了167错误码背后的内核机制。分析指出，问题的核心在于HandlerSocket的写入操作与InnoDB自增锁（AUTO-INC Lock）的交互方式。在高并发下，多个写入线程为了获取下一个自增值而产生严重锁竞争，进而引发队列堆积和错误返回，最终拖垮整体TPS。 文章进一步探讨了优化思路，可能涉及调整InnoDB的自增锁模式、或重新评估在高并发写入场景下使用HandlerSocket的适用性，为遇到类似问题的开发者提供了直接的排查方向和优化参考。