Fork me on GitHub

Tech For Fun

kaelzhang's blog

如何在不破坏团队的情况下拆分单体系统

动态组织团队拓扑（1）

本文源自《ORGANIZATION DYNAMICS WITH TEAM TOPOLOGIES》 如何在不破坏团队的情况下拆分单体系统 许多组织认为可以将现有的软件系统分成较小的组件来尝试提高业务敏捷性，认为这将能够支撑更安全，更快速的变更。 但是，当从单体系统转换至松散耦合服务时，必须考虑新的架构将如何影响构建软件的关联团队。 在不考虑团队视角场景下，可能会承担将单体拆分到错误位置...

Posted by Kaelzhang on August 4, 2020

使用DDD和团队拓扑可视化社会技术架构

Visualising Sociotechnical Architecture with DDD and Team Topologies

使用DDD和团队拓扑可视化社会技术架构 近年来，随着逆康威定律的传播和普及，关于团队结构与系统边界的划分一致性越来越受到人们的重视和关注。结合团队拓扑，Wardley映射，动态重新分配和领域驱动设计等不断涌现和演进的设计工具，来有目的地，高效地设计规划现代技术组织结构。 可视化社会技术架构为策略与投资 在核心域图上布置相关技术能力以表达技术策略的各个方面。 它显示了你认为哪些能力对实现...

Posted by Kaelzhang on July 31, 2020

代码评审Checklist

Code Review Checklist

代码评审Checklist 代码评审是我个人一直比较推崇的开发阶段实现质量保障的核心实践。但在现实项目中，不同的团队在实施代码评审活动时的差异非常大，差异点主要在开展频度和评审内容上。 对于开展频度： 有的团队采取每日评审的方式（即每天固定时间进行集体代码评审） 有的团队在移测前就将要移交的用户故事进行代码评审 有的团队在迭代中对所有将要上线的用户故事进行代码评审 ...

Posted by Kaelzhang on July 29, 2020

评审可理解的代码

Google代码健康

Google代码健康：评审可理解的代码 本文源于Google公司的马桶上的健康代码，作者：Max Kanat-Alexander 很容易假设向你发送一些代码评审的开发人员比你以往任何时候都聪明，这就是为什么你不理解他们代码的原因。 但实际上，如果很难理解代码，则可能太复杂了。 如果你熟悉所使用的编程语言，那么阅读健康的代码应该几乎和阅读母语一样简单。 假设开发人员向你发送了以下Pyt...

Posted by Kaelzhang on July 15, 2020

尊重的评审==有用的评审

Google代码健康

Google代码健康：尊重的评审==有用的评审 本文源于Google公司的马桶上的健康代码，作者：Liz Kammer (Google)、Maggie Hodges (UX research consultant)&Ambar Murillo (Google) 尽管代码审查被认为是提高软件项目质量的有价值的工具，但是不明确或苛刻的代码评审评论可能会带来不利的后果：缓慢的评审，受阻...

Posted by Kaelzhang on July 15, 2020

让接口难被误用

Google代码健康

Google代码健康：让接口难被误用 本文源于Google公司的马桶上的健康代码，作者：Marek Kiszkis 我们都试图避免代码中的错误。 但是，由代码调用方产生的错误呢？ 好的接口设计可使调用方易于执行正确的操作，而使调用方难以执行错误的操作。 不要将维护类的不变需求的责任推给其调用方。 你看下列代码可能引起的问题吗？ class Vector { explicit Ve...

Posted by Kaelzhang on July 14, 2020

基本类型偏执?

Google代码健康

Google代码健康：基本类型偏执? 本文源于Google公司的马桶上的健康代码，作者：Marc Eaddy 编程语言会提供在很多上下文下有用的一些基本类型，如：integers, strings, 及maps. 比如：一个string可用于保存从个人名字到网页URL的所有内容。 但是，如果过于依赖基本类型而不是自定义抽象的代码可能很难理解和维护。 基本类型偏执是指过度使用基本类型来代...

Posted by Kaelzhang on July 13, 2020

注释还是不注释

Google代码健康

Google代码健康：注释还是不注释 本文源于Google公司的马桶上的健康代码，作者：Chris Lewis & Bob Nystrom 在阅读代码时，通常没有什么比有适当的注释更有用的了。 但是，有注释也并不总是好事。 有时需要注释的原因可能表明应该开展代码重构活动。 如果无法使编写的代码不言自明，请使用注释。 如果需要用注释来解释一段代码的作用，请首先尝试下面的方法： ...

Posted by Kaelzhang on July 12, 2020

代码评审有过多评论改进项

Google代码健康

Google代码健康：代码评审有过多评论改进项 本文源于Google公司的马桶上的健康代码，作者：Tom O’Neill 代码评审可能会减慢单次代码的变更速度，但同时也有机会改善你的代码并向另一位聪明且经验丰富的工程师进行学习。如何充分利用它们？ 力求使你的大部分变更在少量评论项的情况下，于第一轮评审就获得批准。如果您的代码评审经常需要多轮评论，那么下面的技巧可以帮助你节省时间。 聪...

Posted by Kaelzhang on July 10, 2020

IdentifierNamingPostForWorldWideWebBlog

Google代码健康

Google代码健康：IdentifierNamingPostForWorldWideWebBlog 本文源于Google公司的马桶上的健康代码，作者：Chris Lewis & Bob Nystrom 创建长标识符很容易被采纳。 较长的名称通常会使内容更具可读性。 但是名称太长会降低可读性。 在GitHub和其他地方，有很多变量名超过60个字符的示例。 我们以58个字符组成了此...

Posted by Kaelzhang on July 9, 2020

WeChat Official Account

欢迎关注Tech For Fun的微信公众号

FEATURED TAGS
records development efficiency design pattern ubuntu docker machine learning mongodb high availability code review c++ micro services Architecture istio service mesh envoy tla+ ARTS DevOps 代码质量 DDD Team Topologies
ABOUT ME

如果说优雅也有缺点的话，那就是你需要艰巨的工作才能得到它，需要良好的训练才能欣赏它。

FRIENDS