Browsed by
标签:敏捷

敏捷过程中如何保证代码质量

敏捷过程中如何保证代码质量

閱讀本文約花費: 10 (分鐘)本文目录: 一、为什么要做代码质量分析 二、常见的代码质量分析工具 三、DevOps平台中的代码质量分析 四、DevOps平台中如何为代码质量提供保障 一、为什么要做代码质量分析 在软件开发过程中,当一个功能开发完成后,如何去保证代码是可用的、没问题的?一般情况下,基本都会有单元测试、每日构建、功能测试等环节来保证。但是,保证代码可用就够了吗?显然不是。 一个软件项目开发完一个版本会有下一个版本,会有新的需求,原来的功能也可能会变更。你写的代码可能会被别人使用,你也可能需要修改别人写的代码。如果只考虑代码的可用性,不考虑代码质量,那么后期遇到的问题其维护成本将会很高,不利于版本迭代。为了避免或减少维护和迭代成本,重视代码质量,做好代码质量分析和管控是最好的方式。 二、常见的代码质量分析工具 既然要做代码质量分析,那我们先看看常用的代码分析工具。 PMD: 注重检查源文件中的潜在问题,可以检查Java代码中是否有未使用的变量、私有方法,是否有空的try/catch、是否过于复杂的表达式等等。 CheckStyle:注重代码格式、代码规范,通过检查编码格式、命名约定、Javadoc、类设计等方面进行代码规范和风格的检查,从而有效约束开发人员更好地遵循代码编写规范,提供常见IDE的插件,如eclipse,IDEA等。 FindBugs:注重检测潜在的Bug…

Read More Read More

部署策略对比:蓝绿部署、金丝雀发布及其他

部署策略对比:蓝绿部署、金丝雀发布及其他

閱讀本文約花費: 13 (分鐘)目前,软件开发最大的变化是部署频率。产品团队更早(更频繁)的将产品发布到生产环境。数月或者数年的发布周期变得越来越短 – 对那些构建纯软件产品的人来说更是如此。 现在,使用面向服务的架构和微服务方式,开发者可以设计模块化的代码库。这允许他们同时在代码库中不同的地方编写和部署代变更。 缩短部署周期的业务优势狠明显: 缩短上市时间 客户可以在更短的时间内获得产品价值 客户的反馈也会更快的到达产品团队,这意味着团队可以更快的迭代特性和修复问题 开发人员的整体士气会上升 但是,这种转变也给运维或者 DevOps 团队带来了新挑战。更频繁的部署,意味着已经部署的代码会对站点可用性和客户体验带来负面影响。这就是制定代码部署策略如此重要的原因,因为它可以最大限度的降低产品和客户的风险。 在本文中,我们将讨论不同的部署策略、最佳实践和工具,让你的团队可以更快更可靠的工作。 现代应用的挑战 现代应用通常是分布式的,基于云的。它们可以弹性扩展来满足需求,基于高可用架构更好地容错。这些应用可以使用全托管服务,例如 AWS Lambda 和 Elastic Container Service(ECS) 等平台处理一些运维责任。 这些应用经常频繁部署。例如,移动 app 和 web 应用可能一个月内经历多次更改。有些甚至一天…

Read More Read More

微服务与网关技术(SIA-GateWay)

微服务与网关技术(SIA-GateWay)

閱讀本文約花費: 18 (分鐘) 编辑推荐:文章主要介绍了微服务架构特性,微服务网关的分类以及作用,SIA-GateWay等,希望能对您有所帮助。 一. 背景 软件架构,总是在不断的演进中… 把时间退回到二十年之前,当时企业级领域研发主要推崇的还是 C/S 模式,PB、Delphi 这样的开发软件是企业应用开发的主流。随着时间不断的推移,基于浏览器的的 B/S 架构开始渐渐流行了起来。初期,Web 开发 ASP 还占据了不少优势,但 JSP 的预编译模式让性能有了很大的提升,随后基于 JAVA 语言的 J2EE 架构变的越来越流行。 早期软件架构基本都是单体架构,系统之间往往不需要进行交互,这也导致数据孤岛和 ETL 工具的发展。随着企业应用越来多,相互的关系也越来密切。应用之间也迫切需要进行实时交互访问,随后基于 XML 的异构系统集成和数据交互技术开始被很多公司采用,SOA 的概念被提了出来,web service 逐渐流行起来。 互联网时代,很多公司为了适应更加灵活的业务需求,基于 HTTP 协议和 Restful 的架构风格及简洁和结构清晰的 JSON 语言成为企业开发的最佳实践,在 SOA 架构中,企业服务总线技术 ESB 所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此,微服务架构逐渐流行起来。 在《微服务设计》中如…

Read More Read More

开好回顾会议需要解决这四个问题

开好回顾会议需要解决这四个问题

閱讀本文約花費: 20 (分鐘)持续改进是敏捷的重要组成部分。无论一个敏捷团队今天多么出色,都要推动其团队成员去寻求未来变得更好的方法。而探索持续改进,正是迭代回顾会议的目的。 不幸的是,并非所有回顾会议都能实施得很好。许多团队往往很难开好回顾会议。在本文中,我将描述自己在回顾会议中看到的四个最常见问题,并提供解决问题的建议。   问题1:人们不诚实或不值得信任  对回顾会议最常见的抱怨之一是:人们没有提出真正的问题或人们不愿意承认他们的问题。如果人们不能在回顾会议上直言不讳,那么得到的评论也只能是“浪费时间”。 这或许是个真实存在的问题,但解决方案不是抛弃回顾会议,而是我们要关注如何让人们在回顾会议中变得更加诚实和开放。 您一定能采取一些措施来增强团队成员之间的诚实和互信。具体可以执行以下措施: 1)营造安全氛围 要营造安全氛围,因为只要缺乏安全感,人们就不会在回顾会议上畅所欲言。这就意味着——人们在回顾会议上说的话和发生的事都不会蔓延到会后,并且这一点已深入人心。 只要参加足够多的回顾会议,您就会偶尔看到情绪失控的情况,您还会听到不该重复出现的话语。在最近一次回顾会议上,就有一位程序员咆哮:“到底还要等多久,‘该死的DevOps组’才能执行部署工作?”。 他确实不应该那样说话。但换句话说,他能发泄出情绪,并且在发泄完后明白不能再这样与DevOps组…

Read More Read More

团队间差异大,如何统一估算基准?

团队间差异大,如何统一估算基准?

閱讀本文約花費: 9 (分鐘)实施规模化敏捷时,组织管理多个Scrum团队时将面临更多的挑战。如果您已让多个团队工作于同一个项目,那么协作会变得更复杂,特别是估算的时候。 这些团队需要进行估算和制定计划,并基于计划来跟踪进度,以便PO能安排其工作优先顺序,在有成果物交付时与干系人进行交流。 但多个Scrum团队共同工作会带来更多的挑战,包括: 团队技能和经验水平都不同时,该如何处理? 怎样才能在无需每位团队成员都参与的情况下准确估算工作? 在不知道该由哪个团队来承接工作的情况下,怎样完成估算? 我将与大家分享一个解决方案。但在此之前,让我们先来看看大多数组织在为多个Scrum团队做估算时都会犯的两个关键错误。   错误1:估算不能反映所有团队的能力 第一个错误往往发生在公司挑选一组人员来估算整个待办项时。这本身并不是一个坏主意(事实上稍后我会建议您这么做)。与让大团队每个人都参与每个待办项的估算相比,这样么做当然会更快、更高效。并且或许您还会认为,只要选择的人员合适,估算结果就会是富有见地的。 但这正是事情容易出错的地方,因为一旦缺乏熟悉即将开展的工作且能真正代表所有Scrum团队的人员,您就会得到基于非常片面和不准确的视角而生成的估算值。 不幸的是,目前许多公司正在发生这样的事情:估算数据由那些脱节于即将开展的工作及其实施团队的人员创建。 这样做的结果之一是:…

Read More Read More

SpringCloud Alibaba——服务注册与发现(Nacos)

SpringCloud Alibaba——服务注册与发现(Nacos)

閱讀本文約花費: 5 (分鐘)一、Nacos简介 Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 安装Nacos 下载地址(版本:0.7.0) Linux:sh startup.sh? Windows:startup.cmd? 访问:http://127.0.0.1:8848/nacos,可以进入Nacos的服务管理页面: 二、SpringCloud整合Nacos 完成了Nacos服务的安装和启动之后,下面就可以编写两个应用(服务提供者与服务消费者)来验证服务的注册与发现了。 spring cloud的版本以及spring cloud alibaba的版本,由于spring cloud alibaba还未纳入spring cloud的主版本管理中,所以需要自己加入,添加依赖文件(父工程): <properties><java.version>1.8</java.version><spring-cloud.version>Finchley.RELEASE</spring-cloud….

Read More Read More

如何写出无法维护的代码

如何写出无法维护的代码

閱讀本文約花費: 17 (分鐘)酷壳里有很多我觉得很不错的文章,但是访问量最大的却是那篇《6个变态的Hello World》,和它能在本站右边栏“全站热门”中出现的还有“如何加密源代码”,以及编程真难啊等这样的文章。可见本站的读者们的偏好,我也相信你们都是“身怀绝技”的程序员。所以,今天给大家推荐这篇文章,相信一定能触动大家的兴奋点。 这篇文章的原文在这里(http://mindprod.com/jgloss/unmain.html),我看完后我想说—— 什么叫“创造力”,创造力就是——就算是要干一件烂事都能干得那么漂亮那么有创意的能力。 什么叫“抓狂”,抓狂就是——以一种沉着老练的不屈不挠的一本正经的精神一点一点把你推向崩溃的边缘。 我把文章节选了一些,也并没有完全翻译,简译一下,也加入了一些自己的调侃。对于有下面这些编程习惯的朋友,请大家对号入座。另外,维护程序的朋友们,你们死定了!! If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. (如果建筑师盖房子就像程序员写程序一样,那么,第一只到来的啄木鸟就能毁掉我们的文明) ~ Gerald Weinberg…

Read More Read More

《microservice & serverless》的一点感想

《microservice & serverless》的一点感想

閱讀本文約花費: 6 (分鐘)超哥是来自Amazon的顶级的架构师,经历了Amazon整个向微服务架构迁移的过程,以及向serverless的演化过程,有着极其丰富的经验,年过40,一直站在技术的最前沿,始终保持对技术的执着追求和热情,是名副其实的技术大牛,能与之一起工作,荣幸之至!今天超哥给我们分享的主题《microservice & serverless》,是超哥实际工作经验的一些分享,也为公司架构的演化提供了新的思路和指导。 microservice(微服务)这个可能是这些年最火的一种架构设计了,频繁地出现在各种技术大会上,各大互联网巨头纷纷向这种架构演化,很多小的互联网公司也往这些概念上去靠,大有一种不做微服务就要落伍的趋势。事实上,很多对于微服务的理解比较粗浅,盲目的微服务化甚至会带来更多的负面影响。 目前Amazon内部运行着超过2w过微服务,但是这些微服务并不是凭空产生的,在这之前,运行的服务都是超大的单体服务,但是随着业务的发展,这种服务在整个研发的pipeline(设计→研发→编译→测试→发布→部署→运维)中都出现了一些问题。设计阶段,老的单体服务会给我们带来一些技术限制,比如有些技术只有python语言的实现,但是我们的服务使用java开发,这样我们不得不拿出一个更复杂的设计去解决类似的问题;研发阶段,随着开发人数越来越多,代码冲突的问题越来越多,我们不…

Read More Read More

阿里玄难:面向不确定性的软件设计几点思考

阿里玄难:面向不确定性的软件设计几点思考

閱讀本文約花費: 19 (分鐘) 在纷繁复杂的业务发展中,变化已成为了唯一的不变。如何保障基础设施的安全、高可用性,同时提供高效的创新支持?今天,阿里副总裁、业务平台事业部掌门人玄难,结合阿里巴巴业务平台建设和个人多年大型软件设计经验,提炼成几点思考,希望对大家的软件架构设计有所启发。 玄难 阿里副总裁 业务平台事业部掌门人 特别说明:本文中所说的软件都指代面向最终用户的偏业务的软件,不包含操作系统、中间件等系统软件。 1、软件发展的几个阶段 软件工具和信息化阶段:软件最早是为了数值计算,以工具的形态出现的。包括PC时代我们非常熟悉的Excel,Word这些好东西。以及典型的企业内部管理的信息系统,例如:企业流程审批、进销存管理系统等等。 互联网服务阶段:随着PC互联网兴起,淘宝、QQ、Google、新浪这些全新的互联网服务逐步进入了我们的日常生活。 社会基础设施阶段:随着移动互联网、IOT、人工智能的出现和高速发展,各种各样的软件进入社会经济生活的方方面面,软件之间相互连接,构成了一个纷繁复杂的生态系统,变成了不可或缺的社会基础设施。 随着软件形态的变化,过去非常高效的系统架构和组织形态遇到了全面的挑战。因为我们所处的环境已经从量变到质变,突破临界点,产生了本质的不同。 阿里巴巴就是这个过程中的典型代表。从过去单一的电商业务演变成了复杂的经济体,没有了确定性的业务边界,蓬勃发展的…

Read More Read More

深入浅出了解 OKR(十):OKR 在敏捷转型中的实践

深入浅出了解 OKR(十):OKR 在敏捷转型中的实践

閱讀本文約花費: 12 (分鐘)敏捷转型(数字化转型)是现在非常多的传统企业加快“上线”的有力抓手,也是传统企业在现代竞争中必须要迈出的一步,否则无法适应激烈的竞争。 我在企业敏捷转型里,经常使用的是我自己总结的一个“组织敏捷转型地图”和“团队敏捷转型地图”模型,并以此为核心内容在 2019 年北京的的 Regional Scrum Gathering 大会上做了名为《团队黑客》的主题分享。 未来组织 我对未来组织有自己的想法,未来组织一定是“业务敏捷化”、“管理游戏化”和“组织社区化”三位一体的。要达到这个理想状态,必然经历组织敏捷转型和团队敏捷转型。 组织敏捷转型地图 在“组织敏捷转型地图”中,我定义了组织达到敏捷组织会有 5 个大的阶段: 组织转型 这个阶段组织开始启动转型工作,组织开始进行动员,做一些组织、架构等方面的调整和变化,企业文化也会被重新定调。 业务重构 组织转型的动机大部分都是战略驱动的,但是落地一定会回归到业务上,业务存在的方式、方向都会有一些变化,这个时候对业务的梳理、重构、定义就非常重要。要找到重点突破的业务,也要对业务的北极星指标、衡量体系产生明确的定义。 产品创新 业务重构后,产品方面的调整和创新也会随之而来,业务会被分解到不同的产品上去实现,各种产品规格就会确定下来。同时在产品层级也会要求进行不同的组合、融合和创新,某些项目型的团队,也会走向产品化,…

Read More Read More