随笔分类 - 软件工程
摘要：当人们试图将“代码整洁之道（Clean Code）”的原则应用于现有的代码库时，我经常会问这个问题。
我认为这是合情合理的。
当我们开始重构遗留代码时，通常会将内容提取到较小的方法中。然后再将方法提取到类中。很快，我们可能就能感觉到原来 30 行的方法现在已经分散在不同的类中。
我们想知道的是：这在实际上是否是更容易维护了呢。
也许我们是一个小团队。也许我们必须支持我们继承的一个相对较大（并且没有文档记录的）的代码库。
寻求代码可维护性是一件好事。
错误在于，认为代码可维护性与代码行数（lines of code，LOC）相关。LOC 可能是一个有趣的度量指标，但它并不是关键所在！
不要使用 LOC 作为代码可维护性的度量指标。
阅读全文
摘要：我们曾经接触到一家企业，它一开始只有8个人，那个时候每个月都可以发一两个版本出去，客户都可以用到，因为他们是做医院的信息管理HIS系统。他们觉得做得还不错。后来团队发展比较快，规模到了80人左右，却半年没发一个版本。这导致实施团队没脸见客户，因为客户说半年前提的需求怎么还发不出来。
这个时候悖论就来了：我们以为团队规模越大，研发效率就会越高，可以做越多的东西，但是我们发现团队规模大到一定程度，整个研发效率是会下降的，甚至降得非常快。
阅读全文
摘要：服务一个人的系统，和服务一亿人的系统，复杂度有着天壤之别。本文从工程师文化、组织战略、公司内部协作等角度来分析软件复杂度形成的原因，并提出了一些切实可落地的解法。
阅读全文
摘要：在面向对象出现之前，已有面向过程的分析方法，为什么面向对象被提出了呢？究其本质原因，人们发现面向过程并不是按照人正常认识事物的方式去分析软件，那么人究竟是怎么认识事物的呢，Yourdon 在《面向对象的分析》一书中提到，人类认识事物是遵循分类学的原理，分类学主要包含三点：区分对象及其属性；区分整体对象及其组成部分；不同对象类的形成及区分。
我们现在可以回想下我们认识事物的过程，是不是和分类学所提到的 3 个要点很相似，看到一个事物，大概会感知到它的组成结构是怎样的，形状是怎样的，属于什么分类。所以，人认识事物是以对象的视角切入的，然后赋于对象具体的概念，比如苹果、梨子、汽车等等概念名称。
阅读全文
摘要：同步、异步，并发、并行、串行，这些名词在我们的开发中会经常遇到，这里对异步编程做一个详细的归纳总结，希望可以对这方面的开发有一些帮助。
阅读全文
摘要：我们从应用的视角出发整理抽象了我们在访问、使用数据库时场景的一些稳定性治理、性能优化、提效等方面的实战经验，对于每一个后端应用来说，数据库无疑是重中之重，我们希望通过我们的数据库治理能力，可以帮助到大家更好地使用数据库服务。
本文将详细介绍 MSE 数据库治理的热点功能，动态读写分离的设计与实现。
阅读全文
摘要：本文既能助你清晰表达，也能帮你建立“长期主义的核心认知”促进自己进步。只字不差读它，会有收获。
当面沟通，表达上可以有重复、反复、甚至逻辑不清，因为可以通过多次互动来弥补，直至双方清楚。但如果以文字/文章/文档进行非当面沟通或大会分享，结构合理、观点明确、逻辑清晰就非常重要。
如何清晰表达？我有2个视角：
1.“金字塔”结构及《金字塔原理》书中介绍的方法。
2.日常写文章总结出来的经验
阅读全文
摘要：消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，削峰填谷等问题。实现高性能、高可用、可伸缩和最终一致性架构。
阅读全文
摘要：发布和订阅模式（Pub/Sub）是构建企业级 .NET 应用程序不可或缺的工具。Pub/Sub 是一种消息传递范式，消息的发送方（发布者）不知道目标接收方（订阅者）的任何信息。此外，发布者和订阅者之间不直接发生交互，而是依赖一种叫作主题的公共媒介。因此，这是一个松散耦合的消息模型。
现在，我们假设在同一个架构中部署了多个不同的应用程序，它们需要一种机制来向彼此发送事件通知。这些事件可能是短暂的（因运行时发生变更引起的），也可能是数据库事件（因数据库发生变更引起的）。发布和订阅模式可以帮你实现这种分布式事件通知。
阅读全文
摘要：本文结合自身后台开发经验，从高可用、高性能、易维护和低风险（安全）角度出发，尝试总结业界常见微服务接口设计原则，帮助大家设计出优秀的微服务。
阅读全文
摘要：如何讲清楚一件事我相信很多人都很困惑也很无助，尤其是在晋升场合，在向上汇报或者是做大范围分享的时候，恨不得找个地缝钻进去。很多时候我们常常是这样安慰自己，我是实干派技术人，不需要那些花里胡哨的东西，我技术过硬比什么都重要。曾经一度我也是这样认为，最后改变我这个想法的是一句话：如果你讲不清楚多半是想不清楚，如果你都想不清楚如何能够带领更多人拿到结果？
所以我总结了一些关于如何讲清楚的一些技巧，以供大家参考。
阅读全文
摘要：技术 Leader 是一个对综合素质要求非常高的岗位，不仅要有解具体技术问题的架构能力，还要具备团队管理的能力，更需要引领方向带领团队/平台穿越迷茫进阶到下一个境界的能力。所以通常来说技术 Leader 的技能是虚实结合的居多，繁杂的工作偏多。为此我把自己在工作中经常用到的思考技巧也做了一个整理。
阅读全文
摘要：导语：设计文档是软件工程设计中的重要组成部分。本文根据 Google 及其它公司编写设计文档的经验，并结合实际应用加以完善，系统地介绍设计文档的目的、结构及参考模板，希望推动设计文档在团队中落地，传承并沉淀经验，构建良好的文化氛围。
阅读全文
摘要：在谈效能之前，我想先谈谈作为一个技术人或者技术TL，研发的核心价值是什么？
之前看了一篇文章，比较有意思，分享一下观念：
T外包公司：最核心的竞争力不是技术，而是快速响应、资源调配整合、项目成本控制等方面。
企业信息化公司：研发的核心价值有三个层次：第一层是运用技术更好的去支撑业务；第二层是用技术推动业务，用自身业务经验（服务很多客户）帮助客户；第三层是去用经验积累去影响行业。
解决特定场景和问题的产品公司：核心价值就在于技术，专注与做技术深度。
阅读全文
摘要：在软件开发领域经常会接触到架构这个词汇，在我最初的印象中，架构是一个很高级的词汇。它似乎代表了复杂的工程结构、高层次的抽象设计、最新的开发语言特性等等。对于当时只专注于写业务逻辑的我来说，不免心生对架构的敬畏。工作中对架构的讨论很少，出现则是一些高级晦涩的描述，但是从来没有人清楚地解释过架构做了哪些事。所以，架构到底是什么？架构和业务之间是什么关系？
当我们看一些关于架构的书籍或者资料，不免会接触到一些对架构的定义或者描述。比如：约束、规则、边界、实体关系、模型定义等等。但是懂得这些概念并不能帮助我们设计出来更好的架构，当我们套用设计原则进行架构设计时，不免会觉得空洞乏味，总觉得少了点什么。虽然我们为架构设计做了很多事，但是似乎什么也没做。因为只针对架构设计本身来说，很难说清楚它所产生的价值。所以，好的架构设计的出发点是什么？好的架构应该是什么样的呢？
阅读全文
摘要：DDD正确的打开方式，就是拥抱它的战略阶段，完全扔掉它的战术阶段。这样做，你会活的很舒坦。原谅我使用“限界上下文”这样的名词来解释一下：你只要把我的服务边界划分清楚了，你管我后面是怎么实现呢，设计模式和架构模式，我的工具箱多的很，并不缺CQRS、事件溯源这样的名词。
阅读全文
摘要：在程序员界有一个悖论持续在困惑着很多技术人：在写代码的人的困惑是一直写代码是不是会丧失竞争力，会不会被后面年轻的更能加班写代码的人汰换。典型代表就是工作 5 年左右的核心技术骨干，此时正处于编码正嗨但也开始着手规划下一个职业发展阶段的时候；没在写代码的人困惑是我长时间不写代码（或者代码量较少）我的技术功底是不是在退化，我在市场上还会有竞争力吗，我的发展空间是不是被限制住了。典型代表就是带业务项目的架构师或者团队 Team Leader，他们更多的精力是在业务需求理解和拆分，团队事务的管理上。
阅读全文
摘要：笔者在带团队的六年中发现，程序员们在职场都有一个共同的困扰：“好像写代码都没什么问题了，日常工作基本上都是应付业务需求的开发，好像找不到其他的更大的附加价值了，我应该找一些什么样的发力点才能让我的价值更突出呢？” 。笔者以为，这就是典型的硬技能当下「看似」没有什么问题了，瓶颈卡在了软技能上。所以开篇做个小分享，聊聊程序员的软技能。
注意：今天讲的软技能 ≠ 心灵鸡汤，都是实实在在要学的技能。也不代表笔者精通了这些软技能，也是自己的个人心得与学习梳理，与大家做个分享，一起学习。
阅读全文
摘要：Srinath，科学家，软件架构师。Apache Axis2项目的联合创始人，Apache Software基金会的成员，WSO2流处理器（wso2.com/analytics）的联席架构师。
Srinath通过不懈的努力最终总结出了30条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门。Srinath认为架构师应该扮演的角色是一个引导者，讨论发起者，花草修建者，而不是定义者和构建者。Srinath为了解决团队内部的架构纷争和抉择，制定了以下30条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。
阅读全文
摘要：新的时代，开源的发展越来越蓬勃，开源和云的关系越来越复杂，耦合度越来越高，云是开源软件允许的最佳环境之一，也为开源软件插上安全高效的腾飞引擎。
1997年5月埃里克·雷蒙德(Eric S. Raymond)发表了被誉为“开源圣经”的《大教堂与集市》，开源运动从此有了自己的独立宣言。开源发展至今，从Linus Torvalds、Kenneth Lane Thompson、Richard Matthew Stallman、Eric Steven Raymond等个人英雄的出现，到越来越多的企业组织意识到开源的价值，并加入到开源中，开放、平等、协作、共享的开源模式逐渐成为新一代软件开发模式。开源已成为全球软件技术和产业创新的主导力量之一，尤其到了云时代，开源覆盖了软件开发的全域场景。
本文试图从企业软件的历史，结合开源软件发展规律，介绍软件开发和交付方式的演进过程，分析常见的开源软件开发和使用误区，讨论开源软件的业务模式和生态，以及在云时代下，开源软件和云的结合与相互促进。
阅读全文
