Category: Collection

[转]一个复杂系统的拆分改造实践 0

[转]一个复杂系统的拆分改造实践

1 为什么要拆分? 先看一段对话。 从上面对话可以看出拆分的理由: 1)  应用间耦合严重。系统内各个应用之间不通,同样一个功能在各个应用中都有实现,后果就是改一处功能,需要同时改系统中的所有应用。这种情况多存在于历史较长的系统,因各种原因,系统内的各个应用都形成了自己的业务小闭环; 2)  业务扩展性差。数据模型从设计之初就只支持某一类的业务,来了新类型的业务后又得重新写代码实现,结果就是项目延期,大大影响业务的接入速度; 3)  代码老旧,难以维护。各种随意的if else、写死逻辑散落在应用的各个角落,处处是坑,开发维护起来战战兢兢; 4)  系统扩展性差。系统支撑现有业务已是颤颤巍巍,不论是应用还是DB都已经无法承受业务快速发展带来的压力; 5)  新坑越挖越多,恶性循环。不改变的话,最终的结果就是把系统做死了。

[转]聊聊遗留系统改造的“道”与“术” 0

[转]聊聊遗留系统改造的“道”与“术”

让我们面对现实吧,我们今天所做的一切就是在编写明天的遗留系统。—— Martin Fowler 什么是遗留系统(Legacy System)?根据维基百科的定义,遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序,“属于或与以前的、过时的计算机系统有关” ,但仍在使用中。通常,将系统称为“遗留系统”意味着它可能已经过时或需要更换。 遗留系统改造是程序员的宿命,因为软件永远没有完成的时候。公司的业务始终在变化,软件架构和代码也只能随之不断变化,在数字化时代,这种变化更快了。

[汇总]Git经验 0

[汇总]Git经验

别再推荐Git Flow了 10个节省时间和改善工作流的Git技巧 小姐姐用动图展示 10 个 Git 命令

[汇总]其他程序员的思考 0

[汇总]其他程序员的思考

职场 左耳朵耗子:软件开发这些年,我学会的道理和教训 平台型知识付费渠道 程序员副业之路 | 程序员有话说   作为程序员的思考与反省 一、作为程序员有比写代码更重要的事情 二、不要仅仅只关注自己的领域 三、要有忧患意识

0

[转]到底什么才是业务架构?

业务架构这个词大家时常听到,但是能解释得清楚的却不多,撩撩度娘,你就会发现,不少人问及业务架构和应用架构的关系,聊天时,也常有人问起业务架构师和产品经理什么区别?业务架构分析和需求分析什么区别?其实为了写这篇文章,我把《软件工程》、《软件系统架构》、《系统分析与设计》都翻了,这些经典教材确实没讲过业务架构这件事;我把《聊聊架构》也翻了,发现其中的讨论有解释到业务、架构和技术的关系,但是也没有特别强调业务架构。

[转]Redis是如何写代码注释的?

[转]Redis是如何写代码注释的?

许多人认为,如果代码写得足够扎实,注释就没什么用了。在他们看来,当一切都设计妥当时,代码本身会记录其作用,因此代码注释是多余的。我对此持不同意见,主要出于两个原因: 1. 许多注释并未起到解释代码的作用。 2. 注释使读者不必凭空想象太多细枝末节,帮助读者降低认知负担。 注释的分类 我的工作始于随机地阅读Redis源代码,以检查注释是否以及为什么在不同的上下文中起作用。我很快发现,注释的作用来源于多方面:它们在功能,编程风格,长度和更新频率方面往往非常不同。我最终转向了注释分类。

[转]DAG、Workflow 系统设计、Airflow 与开源的那些事儿 0

[转]DAG、Workflow 系统设计、Airflow 与开源的那些事儿

DAG (Directed Acyclic Graph) 是一个非常有用、也有很有意思的数据结构。如果说数组、链表、二叉树这类数据结构是学习中的基础,那么 DAG 绝对算得上工作中常常会听到、用到的实践知识。工作中两个 SDE 讨论技术问题,DAG 和 Array/Linkedlist/Tree 算的上是同一级的词汇、知识,默认彼此都懂。 下面我们详细讲讲原因:有向无环图 (DAG),结合拓扑排序(topolocial sort)的确是解决存在依赖关系的一类问题的利器。

[转]MVC, MVP, MVVM 0

[转]MVC, MVP, MVVM

前言: 准备写这篇文章的时候 , 我自认为对MVC已经有深刻理解了,可是画图的时候发现,理解还是有漏洞,于是又阅读,思考,整理,加深了理解, 写了这篇文章, 估计还有漏洞,欢迎讨论。 这再一次说明了写作的好处: 很多时候自以为理解了,实际上脑海中有很多想当然的假设,写作会把这些假设给暴露出来。

0

[转]如何运用 DDD 解决团队协作与沟通问题?

领域驱动设计的核心是“领域”,因此要运用领域驱动设计,从一开始就要让团队走到正确的点上。当我们组建好了团队之后,应该从哪里开始?不是UI原型设计,不是架构设计,不是设计数据库,这些事情重要却非最高优先级。 试想,项目已经启动,团队却并不了解整个系统的目标和范围,未对系统的领域需求达成共识,那么项目开发的航向会否随着时间推移而逐渐偏离?