分析和设计,是软件开发中的两个重要活动。前段时间突然发现自己没有很好的区分这两个活动,试图在没有分析之前,直接进行设计,实际上增大了软件实现的难度。
两者有什么区别呢?它们在软件开发中的作用是什么?
"分析"是指通过梳理问题,得到问题执行的详细过程,包括:执行步骤,步骤涉及的数据、每个步骤负责的功能等等。而设计则用合适的方式,将分析结果在编程语言中表达出来。
两者的区别在于,分析是梳理,设计是表达。
架构师在团队中承担什么责任?这个问题不搞清楚,不利于架构师开展工作,不利于团队对架构师作出合理期望,还导致无法正确评估架构师的工作绩效。
从各个公司对架构师的JD来看,一般会要求架构师是个技术大牛,负责搭建系统架构,解决技术问题,提高团队技术实现能力。在这个基础上,有些团队还会要求架构师承担一些团队管理和组织学习方面的工作。没错,架构师确实应当承担这些职责。但在我看来,所有这些,其实都围绕着一个中心:软件质量。架构师职责的核心就是要实现和保障软件质量,所有的具体架构工作都是服务于软件质量这个目标。
架构师对交付软件的质量负责,所有质量上的问题,即使不是架构师自己设计和编码的,架构师都要担当最终责任。注意:QA不保证质量,他们只负责发现问题。
##Introducing JMH JMHs是由OpenJDK项目组提供的benchmark框架,它为我们编写和运行基于JVM的benchrmark提供了坚实可信的基础,使我们避免在benchmark时掉入之前说所的JVM优化陷阱中。 当然,JMH并没有提供免费的午餐,仍然需要我们在编写benchmark代码是尊守一定的规范和规则,但是JMH可以帮助我们更容易地解决问题 。
我们先来看看如何在项目中引入JMH,并尝试基于JMH实现第一个benchmark。
假定我们的项目使用gradle构建(maven、ant也有类似的方法引入JMH,这里不再介绍),首先我们需要使用JMH插件,在build.gradle
中添加:
plugins {
我们在开发中,可能会经常面临上面类似的问题,要准确回答这种性质的问题,得到让人信服的结论,不能只靠分析和猜测,正确的方法是针对不同实现策略和算法,在相同的负载或者环境下执行性能测试,比较它们的测试结果,根据性能评分得出结论。 我们把这种性能测试和评估的过程称为Micro benchmark
。
和测试阶段执行的load test和stress test不同,Micro benchmark
针对的是单个应用中的某一部分代码,不用准备复杂的环境和构造数据,是轻量级的测试活动,它应当和Unit test一样,成为开发的日常环节。这样,我们可以在代码重构,性能优化甚至daily build时,快速执行,发现性能缺陷,避免到集成测试或者更晚的压力阶段发现性能问题。当然,这就意味着我们需要一个自动化的Micro benchmark
执行框架。
JAVA应用允许创建的最大线程个数缺省是400+线程,以保证整个系统的稳定。目前应用服务的线程主要包括以下几类:
我们需要控制java线程个数,否则应用会占用过多系统资源。
通过修改配置,可以控制应用的线程个数。具体方法如下:
目的
TODO/疑问