Category: Collection
[转]作为技术负责人,如何从0搭建公司后端技术栈
如何您是一名创业公司的负责人,如何从0搭建公司的后端技术栈。今天要说的后台是大后台的概念,放在服务器上的东西都属于后台的东西,比如使用的框架,语言,数据库,服务,操作系统等等。 整个后台技术栈我的理解包括 4 个层面的内容: 语言:用了哪些开发语言,如:C++/Java/Go/PHP/Python/Ruby 等等; 组件:用了哪些组件,如:MQ 组件,数据库组件等等; 流程:怎样的流程和规范,如:开发流程,项目流程,发布流程,监控告警流程,代码规范等等; 系统:系统化建设,上面的流程需要有系统来保证,如:规范发布流程的发布系统,代码管理系统等等;
[转]一个复杂系统的拆分改造实践
1. 1 为什么要拆分? 先看一段对话。 从上面对话可以看出拆分的理由: 1) 应用间耦合严重。系统内各个应用之间不通,同样一个功能在各个应用中都有实现,后果就是改一处功能,需要同时改系统中的所有应用。这种情况多存在于历史较长的系统,因各种原因,系统内的各个应用都形成了自己的业务小闭环; 2) 业务扩展性差。数据模型从设计之初就只支持某一类的业务,来了新类型的业务后又得重新写代码实现,结果就是项目延期,大大影响业务的接入速度; 3) 代码老旧,难以维护。各种随意的if else、写死逻辑散落在应用的各个角落,处处是坑,开发维护起来战战兢兢; 4) 系统扩展性差。系统支撑现有业务已是颤颤巍巍,不论是应用还是DB都已经无法承受业务快速发展带来的压力; 5) 新坑越挖越多,恶性循环。不改变的话,最终的结果就是把系统做死了。
[转]聊聊遗留系统改造的“道”与“术”
让我们面对现实吧,我们今天所做的一切就是在编写明天的遗留系统。—— Martin Fowler 什么是遗留系统(Legacy System)?根据维基百科的定义,遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序,“属于或与以前的、过时的计算机系统有关” ,但仍在使用中。通常,将系统称为“遗留系统”意味着它可能已经过时或需要更换。 遗留系统改造是程序员的宿命,因为软件永远没有完成的时候。公司的业务始终在变化,软件架构和代码也只能随之不断变化,在数字化时代,这种变化更快了。
[汇总]构架经验
1. 架构师思维 IT 生涯 | 像架构师一样去思考 架构师角色的演变:从发号施令到与团队合作[好文] 康威定律的影响是一个关键主题:系统的架构反映了组织的结构。 “为什么”这样的提问方式带有评判的味道,例如,“你为什么要采取这种方法”。如果将问题改为“是什么让你决定采用这种方法”,会促使被问者解释他们的想法,而不是为他们的决定辩护,因为当被问及“为什么”时,他们可能会认为自己的决定是不是不正确的。 给架构师: 成为帮助团队架构理解的导师,而不是障碍。公开主动地分享你的知识。 为那些只有你自己感觉到但团队可能没有意识到的挑战寻求指导,来帮助你克服内心的挑战。不要独自承受,支持性的指导有助于你的角色演化。 欢迎来自客户、团队和环境的挑战。这种反馈循环可能会让人感到筋疲力尽,但可以带来巨大的回报。 用你的经验将对话引向你的专业知识告诉你会遇到的挑战。 了解团队的动态、他们的优缺点、他们对工具的掌握,以及他们日复一日地构建应用程序的实际情况。帮助你在正确的时间组织你的输入,在哪里可以带来最大的价值。 成为人际关系的建设者。培养你的软技能,建立起人际网络,从销售团队到产品负责人,从工程经理到技术中小企业。每天都要培养和维护这些关系。 给团队: 为非领域专家总结使用工具的经验,带他们踏上理解之旅。 利用架构师丰富的经验来洞察你可能有的想法、挑战或主意。他们现在是你团队的一员了。 简单明了地表达你的想法、优点和缺点,准备好接受开放性和有挑战性的反馈,构建心理安全感。 把头衔和自负留在门外,拥抱团队环境,向团队里的每一个人学习。在当今的软件设计当中,你对设计过程的影响是真实存在的。 培养你的演讲、沟通和指导技能,并每天使用它们,在快节奏的团队中进行信息交流是至关重要的。 尽你所能留住你的架构师。他们深厚的专业知识对团队的成长和壮大是无价的,不要让他们感到孤立,让他们觉得自己是团队的一部分,是未来解决方案的一部分。 十四年架构师揭秘:要做架构师先要在鸟群中做好鸟 我是如何在阿里做“架构师”的? 我们还需要架构师吗?还需要架构部门吗?我给出的答案是:不需要,因为每个人都应该是架构师。 阿里技术大牛:一份架构师成神路线图! 绝好的的技术整理! 恕我直言,一般像你这种能说会道的技术都不太行 手上有团队,有资源,我要做的是 “找到合适的人,放到合适的位置上”,让每个人发挥各自的所长,而不是我自己再去纠结一些细节。 架构师虽然听起来很高大上,但本质上仍然是工程师,不是忽悠人的江湖骗子。...
[汇总]其他程序员的思考
1. 技术 入行 14 年,我还是觉得编程很难:给大项目写代码没意思还危险 写代码很简单,但写好代码很难 编程的精髓是“创造” 打造高效试错的环境至关重要: 理想的编程体验≈“刷题” 避开代码完美主义陷阱 技术很重要,但“人”也许更重要:在软件开发领域,“单一职责原则”(全称为 Single responsibility principle,后简称为 SRP)是一条非常著名的设计原则。它的定义很简单,一句话就可以概括:“每个软件模块应该只有一个被修改的理由。理解 SRP 原则的关键,在于先理解人以及人在软件开发中所扮演的角色。如果缺少了特定的组织规模(也就是“人”)作为前提,空谈微服务的各种技术优势和那些花活,纯属本末倒置。 求知若渴是好事,但也要注意方法。 越早开始写单元测试越好。 程序员最大的敌人是什么?软件生来就是准备被修改的(不然你猜,软件为什么叫“软”件?)。产品经理以及不稳定的需求不是程序员的敌人。复杂度是最大的敌人 。 来看看那些导致项目复杂度不断增长的要素: 不断增加的新功能:更多的功能等于更多的代码,更多的代码通常意味着更高的复杂度 对高可用的需求:为了实现高可用,消息队列等额外的技术组件和代码被引入 对高性能的需求:为了提升性能,缓存和相关模块代码被引入,部分模块被拆分后,换成高性能语言重写 一再被推迟的重构:因项目排期过于紧张,迫在眉睫的重构被一再推迟,技术债越积越多 忽视自动化测试:没人写单元测试,也没人关心测试 减缓复杂度增长的过程 虽然复杂度总是会不可避免地持续增长,但有许多实践可以减缓该过程。如果每个人都能做到以下这些事,复杂度就有可能被长期控制在合理范围内: 精通当前编程语言与工具,写整洁的代码 使用合适的设计模式和编程模式 对重复代码零容忍,抽象库和框架 适当运用整洁架构、领域驱动设计思想 编写详尽的文档和注释编写规范有效的单元测试...
[转]到底什么才是业务架构?
业务架构这个词大家时常听到,但是能解释得清楚的却不多,撩撩度娘,你就会发现,不少人问及业务架构和应用架构的关系,聊天时,也常有人问起业务架构师和产品经理什么区别?业务架构分析和需求分析什么区别?其实为了写这篇文章,我把《软件工程》、《软件系统架构》、《系统分析与设计》都翻了,这些经典教材确实没讲过业务架构这件事;我把《聊聊架构》也翻了,发现其中的讨论有解释到业务、架构和技术的关系,但是也没有特别强调业务架构。