我是梅雪松，是一名开发者，喜欢用代码来改变世界。我也是一名架构师，追求简单设计并致力架构的守护和演进，主持过多个大型遗留系统的现代化改造工作。我还是一名咨询师，帮助客户打造高绩效团队，提升团队在敏捷技术实践、DevOps等方面的技能，构建持续交付能力，并帮助团队应用领域驱动设计（DDD）、微服务等设计方法，提升软件质量。

码意浓是一位软件开发人员，他最近心情不错，因为他将要负责一个关键的嵌入式系统软件开发。他决定拜访自己多年的老师，听听大师的意见。

大师：码意浓，好久不见，看你气色不错，有什么新鲜事想聊聊吗？

码意浓：嘿，大师，我正好有个新项目想请教您。我们打算开发一个新的嵌入式系统来替换那个已经服役快20年的老古董了。

大师：哦，终于要更新换代了，这可是个大好事。那个老系统确实已经跟不上时代了，维护起来也是头疼得很。

码意浓：是啊，说起来都是泪。不过我也有点担心，新系统的设计可不是件容易的事。

大师：别担心，我们一步一步来。你给我讲讲这个新系统。

不知道你有没有注意到，走进各个企业，总能看到那么几句振奋人心的标语，其中“一次把事情做对”绝对是个高频词汇。以前每次看到，我都会想：这家企业也太教条了，都什么时代了。对失败这么零容忍，还怎么创新呢。这个时代的主旋律不是从错误中学习，快速响应、快速迭代吗。

然而最近一年的嵌入式领域经历，让我重新反思，“一次把事情做对”不仅是对工作效率的追求，更是对质量控制的严格要求。在嵌入式产品开发领域，这一理念的重要性尤为突出。

小时候看古代小说，总觉得他们打仗用的阵法特别炫酷，比如一字长蛇阵，攻击到蛇头、蛇身或蛇尾时，瞬间就能卷、绞、咬。这些情节总是让我觉得又威风又神秘，兴奋不已。长大后明白了作为个体的士兵在组成部队后，通过阵法的运用，能产生出远超个体之和的力量。

在现代商业社会，面对激烈的商业竞争，你的团队如何排兵布阵呢？本文尝试探讨一下团队拓扑在嵌入式领域的应用。

组织中所有的问题都可以最后归结为人的问题。很多时候我们期望流程和工具能够解决这些问题，然而如果忽视了团队中个体的需求、动机和互动方式，那么再正确的流程和再好的工具也无济于事。因为流程和工具无法发现人、培养人、激发人。

真正的团队效能来源于团队之间以及成员之间的协同合作、有效沟通和共同目标。因此，在构建和优化团队时，我们需要将关注点放在团队本身，坚持“团队优先”的原则。

在以往，嵌入式系统开发往往是单兵作战，依赖于个体能力，详细的需求文档并不被视为必要条件。然而，随着嵌入式系统的复杂度不断提高，团队协作变得至关重要。这就离不开知识的传递和消费，因此需求管理在嵌入式系统中的重要性日益凸显，它不仅关乎业务实现，更影响到团队的沟通和项目顺利进行。

最近，我们在一项嵌入式项目中探索了不同的需求描述方法，从传统的需求规格说明书到敏捷的用户故事，再到我们最终采用的系统用例。这一方法极大地提升了团队的开发效率，本文将分享我们的经验和思考。

2020年突如其来的新冠疫情加速了全球的数字化时代步伐。我们看到各行各业，包括政府部门都在加速数字化转型。保险行业面临数字化转型的新机遇，如何打造数字化业务，已经是一个不容回避的课题。

本文首先探讨数字化时代保险行业的变革，分析传统保险公司面临的挑战，并提出打造数字化业务的方法，最后以一家虚拟的X保险公司作为示例，展示如何帮助它打造自己的数字化业务，从而实现其战略目标。

这几天大连车务段火了，因为Flash停用，导致车系统不能用，奋战24小时用Ghost和Flash降版本恢复使用。本来恢复就恢复了，可是把这个宣传成敢于攻关、敢于创新、敢于领先，就被全网程序员笑话了。

可是程序员朋友们，先别笑话那些业余选手，想想你手上的遗留系统改造了吗？

今天看了本好书《卓越工作》，迫不及待地要分享给大家。

作者的第一份工作是在波士顿咨询公司（BCG），加入公司后想着要996大干一番，却发现一女同事早8点晚6点准时下班走，也不加班。关键是工作还做得比自己好。之后的多年时间里，直到他做了哈佛商学院的教授，他都还在思索为什么当年那位女同事能够用更少的时间却能做得更好？

作者发现，没有人愿意愚笨地工作，但大多数人实际上却就在愚笨地工作，因为真的不知道怎么聪明地工作。于是他深度访谈了120位专业人士，调研了5000人后，形成了这本书的内容。

我节选几个观点与大家分享。

今天看了最近大火的动画片《心灵奇旅》，可能因为评分高，所以我的期望值过高吧，看完后觉得有点小小的失落，但是电影的最后一句话打动了我：

最近我给一家传统的大型电子制造业公司做嵌入式系统平台架构咨询。他们的产品硬件部分已经组件化，但是每年都有一部分元器件单元要替换，相应的软件就要修改。最大的痛点就是由于系统耦合严重，一改就容易出问题，工作量还大，团队苦不堪言。

这样的问题不仅出现在嵌入式领域，也出现在传统的软件领域。例如你是否依赖于某个外部系统，想要替换掉它却发现代码已经耦合在一起动不了？又或者某个类库/中间件已经无法满足要求，却又不敢更换？

究竟应该如何处理好外部依赖呢？

说到DDD难，我觉得主要是两点：建模难、代码落地难。前者需要业务熟、功力深，难以快速提升；后者难在缺乏简单易行的可参考的代码结构，一旦有了这样的参考结构，就可以快速大幅降低DDD的实践难度。本文从后者的诸多难点中选择一个最常见的问题进行探讨：如何优雅地实现聚合的持久化？

天下武功，唯快不破！在这样一个快速变化的时代，企业也在追求高响应力（快）的路上一路狂奔！这才有了敏捷、DevOps大行其道。然而，很多企业发现，虽然团队号称敏捷了，但是响应力变化并不明显，质量可能还下降了，程序员996加班更严重了。这是敏捷/DevOps转型的锅吗？企业该怎么办？

尽管大家都认为SOLID是非常重要的设计原则，并且对每一条原则都耳熟能详，但我发现大部分开发者并没有真正理解。要获得最大收益，就必须理解它们之间的关系，并综合应用所有这些原则。只有把SOLID作为一个整体，才可能构建出坚实(Solid)的软件。遗憾的是，我们看到的书籍和文章都在罗列每个原则，没有把它们作为一个整体来看，甚至提出SOLID原则的Bob大叔也没能讲透彻。因此我尝试介绍一下我的理解。