Category: Collection

[汇总]汽车软件构架 0

[汇总]汽车软件构架

从技术的角度谈谈OTA召回 蔚来汽车深度学习算法实践 Android 车载应用与传统开发之间的尔虞我诈~

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

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

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

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

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

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

[汇总]Git经验 0

[汇总]Git经验

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

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

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

1. 技术 入行 14 年,我还是觉得编程很难:给大项目写代码没意思还危险 写代码很简单,但写好代码很难 编程的精髓是“创造” 打造高效试错的环境至关重要: 理想的编程体验≈“刷题” 避开代码完美主义陷阱 技术很重要,但“人”也许更重要:在软件开发领域,“单一职责原则”(全称为 Single responsibility principle,后简称为 SRP)是一条非常著名的设计原则。它的定义很简单,一句话就可以概括:“每个软件模块应该只有一个被修改的理由。理解 SRP 原则的关键,在于先理解人以及人在软件开发中所扮演的角色。如果缺少了特定的组织规模(也就是“人”)作为前提,空谈微服务的各种技术优势和那些花活,纯属本末倒置。 求知若渴是好事,但也要注意方法。 越早开始写单元测试越好。 程序员最大的敌人是什么?软件生来就是准备被修改的(不然你猜,软件为什么叫“软”件?)。产品经理以及不稳定的需求不是程序员的敌人。复杂度是最大的敌人 。 来看看那些导致项目复杂度不断增长的要素: 不断增加的新功能:更多的功能等于更多的代码,更多的代码通常意味着更高的复杂度 对高可用的需求:为了实现高可用,消息队列等额外的技术组件和代码被引入 对高性能的需求:为了提升性能,缓存和相关模块代码被引入,部分模块被拆分后,换成高性能语言重写 一再被推迟的重构:因项目排期过于紧张,迫在眉睫的重构被一再推迟,技术债越积越多 忽视自动化测试:没人写单元测试,也没人关心测试 减缓复杂度增长的过程   虽然复杂度总是会不可避免地持续增长,但有许多实践可以减缓该过程。如果每个人都能做到以下这些事,复杂度就有可能被长期控制在合理范围内: 精通当前编程语言与工具,写整洁的代码 使用合适的设计模式和编程模式 对重复代码零容忍,抽象库和框架 适当运用整洁架构、领域驱动设计思想 编写详尽的文档和注释编写规范有效的单元测试...

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)的确是解决存在依赖关系的一类问题的利器。