Mobabel

Just One Pure ITer

Category: Collection

[汇总]汽车软件构架 0

Collection

[汇总]汽车软件构架

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

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

Collection

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

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

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

Collection

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

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

[汇总]Git经验 0

Collection

[汇总]Git经验

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

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

Collection

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

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

0

Collection

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

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

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

Collection

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

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

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

Collection

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

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