MacTalk跨越边界

作者简介

池建强，70后程序员，先后在洪恩软件、用友软件工程公司(现瑞友科技)和锤子科技等公司任职，现任锤子科技云平台研发总监，喜爱编程和写作。 长期从事应用软件平台和互联网服务的研究和研发，致力于创造美好的产品，在瑞友科技工作期间组织研发了GAF’平台，全称为瑞友科技国际化应用软件开发平台，服务于上干家企业客户。 2012年开通微信公众平台“MacTalk”，讲述Mac、技术与人文的故事，受到广大程序员喜爱。2014年在出版技术人文类图书《M8cTalk·人生元编程》，在程序员里得到广泛传播。 在组织的OCotl、ArchSummit、OClub等技术大会上多次担任演讲嘉宾和专题出品人，是中国的特约顾问。 2015年初，加入老罗的“锤子科技”，负责云服务、电子商务、官网、OS×和iOS等软件与服务的研发和运维。 在未来十年，我希望能够做出一些改变人们生活的产品，这是我的理想，我想要实现它。

内容简介

我拿到问题一看，不难。Linu×和OS X虽然师出 同门，都是从老前辈LJNIX那儿毕业的，但是后来毕 竟各练各的，在Linux编译好的程序不可能在OS X上 用，但是在OS X上重新编译一下可能就没事了。我把 这个想法告诉了这位程序员，得到的反馈是：对不起 ，哥，没有源代码!我被这个冷酷的回复震惊了，立 刻意识到刚才的想法并不是最优解决方案，因为在重 新编译的过程中，各种包的依赖关系和编译错误足以 让你焦头烂额，我随即提供了B计划：在OS X上安装 Docker，轻量级的容器Docker‘可以运行各种版本的 Linux，把文件扔到Docker里，然后通过主机和 Docker’之间的端口映射即可轻松解决这一问题。 虽然这里面会涉及很多技术细节，但是方向是没 有问题的，所以这位程序员立刻表示“茅塞顿开”， 然后“地一声就在屏幕对面消失了，没有留给我说“ 不客气”的机会。 这个问题装个Linux虚拟机也可以解决，但是虚 拟机过于耗费资源，而且不如Docker。灵活，所以不 是最佳解决方案。Docke r’是。作为一个程序员， 我们除了要掌握多门程序语言和多种数据库，了解前 端技术、后端技术，通晓网络七层架构，知道TCP／ IP三次握手和四次挥手，编写漂亮的代码，设计优美 的架构……之外，我们还要解决研发、程序运行和产 品上线过程中遇到的各种问题，而且被要求以最小的 代价来解决问题……我们容易吗? 除了编程技巧和程序设计能力，解决问题的稳准 狠是衡量一个程序员是否优秀的重要因素之一，也是 资深技术人员真正的价值所在。在科技浪潮澎湃、技 术信息扑面而来的今天，一位刚毕业的大学生如果足 够勤奋，他可以在两三个月之内掌握一门编程语言， 并编写出像模像样的软件，他们的学习速度甚至超过 了我们这些老程序员，但是解决问题的能力是无法速 成的，只能依靠时间、经验和惨痛的教训历练而成。 有时候还需要灵感和运气。很多军事迷读了大量的军 事著作和历史小说，常常羡慕那些名将的风采，并浩 叹自己“生不逢时”。但是名将不是那么容易炼成的 。历史上叱咤风云的名将凤毛麟角，他们亲自持刀上 阵追击敌人，见识战场的惨烈，目睹敌人的尸体，看 到战友被杀，知道被刀砍中会流血死去，他们冷酷无 情，坚如磐石，在全军即将崩溃的时候发现敌人的弱 点并进行攻击，在瞬息万变的战场中进行决断，在多 次失败后从无数士兵的尸体里站起来重新出发去挑战 那个战胜你的对手，在所有人对你说“指导员，我们 上吧”的时候，坚定地说出那三个字：再等等! 如果你做不到这些，那还是做个最终会被张飞枪 挑的小兵吧。 优秀的程序员同样如此，莱乌常常羡慕高手在谈 笑之间让难题灰飞烟灭，而自己却苦苦思索而不得入 门之法，殊不知这些高手同样经历了名将的那些腥风 血雨。他们在清晨的微光里编写代码，在轰鸣的机房 中调试程序，他们彻夜不眠就是为了解决一个bug， 他们要承受数据丢失或上线失败的痛苦，默默吞下眼 泪，准备下一次的战斗。不停地学习、实践和思索， 成千上万个小时之后，高手始成。 同样的问题，高手的解决思路和小球是截然不同 的。一般来说，只要不是世界难题，给足时间、空间 和人力，都能解决。如果你遇到问题告诉上级，这个 问题交给我了，两年之内搞得妥妥的，那就不要怪项 目组成员组团把你打出屎来，因为大家要的是分分钟 解决，不是两年。在这个唯快不破的年代，我们没有 那么多的时间，所以要通过逆向思维、经验教训、辗 转腾挪、借力打力等方式以最小的代价快速解决问题 。这才是老程序员的价值。再举个例子，一个运行良 好的线上应用，在你修改bug增加功能之后，重新上 线，出现了一些莫名其妙的问题，如占用资源增加或 运行一段时间宕机等，怎么解决? 常规的做法就是通过阅读日志、模拟线上环境和 调试程序未定位错误。容易的bug用这些方式基本就 能搞定了，但是更隐蔽的bug会耗费大量的时间和人 力。更好的方式是什么? 首先，排查是程序问题还是环境问题，把线上程 序恢复到运行正常时的老版本，如果出现了同样的问 题，那就是生产环境发生了改变。如果运行正常，要 么是你修改老bug时引入了新bug，要么是新增加的代 码出现了问题。 其次，阅读产品的修改日志，根据代码提交的时 间线构建系统，通过二分法排查，定位是哪部分代码 引起的问题。P4-5