Category: Architect&CTO

在多年的技术管理工作中，我曾不断地遇到很多已经转型或即将转型为技术管理者的同事，他们都表达了一些类似的困惑：如何成功转型？不想丢掉技术，但如何在不丢掉技术的同时还能提升管理能力？以下是我个人在经历困惑和挣扎这个过程后的一些个人想法，在这里分享给大家。

【编者按】抛开这个夸张的骗点击量的标题，我希望告诉你：称职的技术主管确实是拥有普通工程师10倍功力的麒麟之才。不过，这位技术主管在技术之外还需要将强有力的开发能力传授给队伍中的每个成员。在技术主管的指导下，幸运的工程师会感觉自己拥有了10倍的能力，并可以享受前所未有的强大支持。 而且，我希望告诉你，技术主管用头上的白发换来的这种神奇的10倍魔力的光环，并不一定会牺牲任何人的幸福。技术主管扛下了所有工作中的“杂项”，大大加快了重要工作的生产力，从而确保团队成员可以尽情享受工作和生活的乐趣。对于那些拥有一个称职的技术主管的团队成员来说，这是莫大的幸福。 在称职的技术主管的指导下，幸运的工程师会感觉自己拥有了10倍的能力。

本文的主题是技术选型，作者总结了他见过的各种不靠谱的技术选型方式，比如有的团队会根据社交媒体上的讨论来决定选择哪种架构，也有的团队会跟风走，哪个热门就选哪个。但总体来看，这样简单粗暴的方式一定会为未来埋下隐患。那为什么这样说？我们应该如何做正确的选择？且听作者细细道来。另本文译者余晟，曾经是主力程序员、技术文章的写作和翻译爱好者，现在在沪江负责研发和软件架构。欢迎关注他的个人公众号“余晟以为”，了解一位非典型 IT 人员对世界的看法。 软件开发团队所做的软件架构或技术栈的决策，很多并没有经过踏实的研究和对目标成果的认真思考，而是不准确的意见、社交媒体的信息，或者就些是“热闹”的玩意。我称这种作派为“热闹驱动开发（Hype Driven Development，HDD）”，眼见它的危害，我赞成更专业的做法，就是“脚踏实地的软件工程”。下面我们一起看看HDD的来龙去脉，想想能如何改进。

  从什么时候起，技术角色的提升就意味着脱离技术与交付？CTO 不写代码已经引起诸多争议了，架构师也不写代码，能行吗？ 当我面试架构师职位的候选人时，我通常会问一个这样的问题：“你认为架构师是否应该做一些编码工作？”而通常会得到下面两个反馈之一： “不，我正在寻找一个不再需要编码的职位。” “我喜欢继续编码，至少是少量的编码，但可能不会有时间这样做。” 与此类似，当问及其他一些架构师最近做过多少编码的工作，通常得到的答案是： “有一段时间没有编码了。”