直播源码开发前期应该注意事项 Java

直播源码开发前期应该注意事项

一、自主开发 组建一支技术团队,只为自己的团队工作,它的优点是一切以自己的平台优先,不会出现平台想开发什么功能,但软件公司生意太好没有档期导致开发延迟的情况,自己的团队想加班就加班,空了闲了还能搞搞外包,也算一项进账,但它的缺点也很明显,组建团队、开发源码软件,这些都需要时间和钱,新源码毛病多,修修改改更浪费时间,前期投入太大了。 二、购买成熟直播源码 购买成熟直播源码再进行私人定制开发是一...
阅读全文
从一线经理到全球副总裁,我的敏捷组织架构设计原则 软件架构

从一线经理到全球副总裁,我的敏捷组织架构设计原则

作者介绍 常红平, IT职场老兵,在做过除用户体验设计师外的所有软件研发团队中的角色后,于10年前开始专注于管理。爱技术、爱敏捷、爱读书、爱分享。现在IBM CIO中国实验室作为IBM全球软件和云服务销售系统负责人,领导IBM年交易量数百亿美金的核心系统的研发和运维工作。近年来,他还带领跨国团队成功实施了一系列敏捷转型、技术革新、和组织文化转型。 随着数字化时代全面到来,...
阅读全文
从 VSCode 看大型 IDE 技术架构 软件架构

从 VSCode 看大型 IDE 技术架构

零、前言 为什么要去看 VSCode? 因为我们团队在做中后台 Web 编辑器 是一款类似 Web IDE 形态的产品: 而谈起 Web IDE,没人能绕开 VSCode,它非常流行,同时又完全开源,总共 350000 行 TypeScript 代码的巨大工程,使用了 142 个开源库。市面上选择基于 VSCode 去修改定制的 IDE 比比皆是:Weex Studio、白鹭...
阅读全文
三大亮点 ThoughtWorks DDD峰会的变与不变 编程技术

三大亮点 ThoughtWorks DDD峰会的变与不变

至顶网软件与服务频道消息: 数字经济时代,日益复杂的企业数字化业务不断扩展,对软件系统也不断提出新的挑战,DDD正成为软件架构设计新的潮流,以领域模型为核心,为复杂领域软件工程的设计决策提供实践框架,可在更大范围帮助业务实现快速响应,优化组织合作。 近日,全球领先的软件及咨询公司ThoughtWorks主办的第三届“领域驱动设计中国峰会”在北京成功举行。作为领域驱动设计(Domai...
阅读全文
ITOps为什么要转向云端? 编程技术

ITOps为什么要转向云端?

要想正确理解ITOps,我们先来看看IT 运维管理(ITOM)发生了哪些变化? 如今,企业IT的正在发生翻天覆地的变化,无论是Splunk收购SignalFx,还是软件制造商PagerDuty的IPO事件,所有迹象都在表明——基于SaaS模式的ITOM时代正在崛起。 过去,大多数企业的IT项目都遵守了同一个流程,即先咨询,然后进行设计,最后再进行架构部署。一个项目完成的时间,少说也得一年半...
阅读全文
微前端入门 编程技术

微前端入门

最近打算改进一下现有网站的架构,微前端这个词多次进入了我的视野。 但是网上关于微前端文章总是说得似是而非,于是我找到这篇文章进行翻译。并大概理解微前端的理念。目前还没有确定是否使用微前端架构,因为看起来业界对最佳实践并没有达成一致。 译文开始,有删节。原文链接 引言 把前端做好很难,让多个团队同时开发大型前端应用,就更难了。目前有一种趋势是将前端应用拆分成更小、更易于管理的小应用。这种...
阅读全文
领域驱动设计对软件复杂度应对 软件架构

领域驱动设计对软件复杂度应对

编辑推荐: 本文来自于个人图书馆,本文主要介绍了需求中业务需求与质量属性需求,因而需求引起的复杂度可以分为两个方面:技术复杂度与业务复杂度。 需求引起的软件复杂度 需求分为业务需求与质量属性需求,因而需求引起的复杂度可以分为两个方面:技术复杂度与业务复杂度。 技术复杂度来自需求的质量属性,诸如安全、高性能、高并发、高可用性等需求,为软件设计...
阅读全文
前端架构师亲述:前端工程师成长之路的 N 问 及 回答 编程技术

前端架构师亲述:前端工程师成长之路的 N 问 及 回答

问题回答者:黄轶,目前就职于 Zoom 公司担任前端架构师,曾就职于滴滴和百度,毕业于北京科技大学。 1. 前端开发 问题 大佬,能分享下学习路径么,感觉天天忙着开发业务,但是能力好像没有太大提升,不知道该怎么充实自己 ? 解答 业务开发有没有痛点,能不能通过技术的手段解决 ? 平时开发业务用到了哪些技术栈和周边的生态链,我是否对他们熟练掌握了,对他们的实现原理呢...
阅读全文
许式伟:毕业 2 年成为首席架构师,我的技术学习方法论 | 极客时间 软件架构

许式伟:毕业 2 年成为首席架构师,我的技术学习方法论 | 极客时间

你好,我是许式伟。 今天想和大家 聊聊架构 ,和架构以外的二三事。 在过去的工作经历里,我看到不少架构师都倾向于把架构看作一项纯技术性的行为。他们的工作流程是这样的:产品经理根据用户的需求做出产品设计,架构师再依据产品设计给出实现,也就是软件的架构设计方案。 在我看来,这恐怕是个误解。 我们做架构,空有一身技术是远远不够的,知识的深度和广度,往往会对架构能力起着决定性的作用。 而...
阅读全文
领域驱动设计对软件复杂度的应对 软件架构

领域驱动设计对软件复杂度的应对

不管是因为规模与结构制造的理解力障碍,还是因为变化带来的预测能力问题,最终的决定因素还是因为 需求 。Eric Evans认为“很多应用程序最主要的复杂性并不在技术上,而是来自领域本身、用户的活动或业务”。因而,领域驱动设计关注的焦点在于 领域和领域逻辑 ,因为软件系统的本质其实是给客户(用户)提供具有业务价值的领域功能。 需求引起的软件复杂度 需求分为业务需求与质量属性需求,因而需...
阅读全文
Loading...