Java中的条件编译
Java中的条件编译
《战争论》
“数量上的优势不论在战术上还是战略上都是最普遍的致胜因素。
战略上最重要而又最简单的准则是集中兵力。
人们必须承认,数量上的优势是决定一次战斗结果的最重要的因素,只不过这种优势必须足以抵消其他同时起作用的条件。从这里得出一个直接的结论:必须在决定性的地点把尽可能多的军队投入战斗。
在一般条件下进行的大小战斗中,不论其他方面的条件如何不利,只要有显著的数量上的优势,而且无需超过一倍,就足以取得胜利了。
如果我们不抱偏见地研究现代战史,那就必须承认,数量上的优势越来越起着决定性的作用。因此,在决定性的战斗中尽可能多地集中兵力这个原则,在现在必须提到过去更高的地位。
数量上的优势应该看作是基本原则,不论在什么地方都是应该首先和尽量争取的。
一切用于某一战略目的的现有兵力应该同时使用,而且越是把一切兵力集中用于一切行动和一个时刻就越好。”
《孙子-谋攻篇》:故用兵之法,十则围之,五则攻之,倍则分之,敌则能战之,少则能逃之,不若则能避之。
清分知识汇总
结算账务基础知识.xmind
本文来自于:
《中国央行支付清算系统概述(上)》
《清分、结算、清算、对账》
《银联清算业务基础知识介绍 VIP》
我国清结算架构
我国银行的(倒置)清结算架构图:
清结算属于底层架构,清算是发生在银行之间的。
在整个体系里,第三方支付公司扮演的角色是收单机构,银行提供资金服务能力。
两个例子从以上示意图中可知,参与支付清结算的市场主体有消费者、商户、商业银行、中国人民银行、收单机构(第三方支付公司)。上面介绍的内容相对比较抽象,我们先用现实生活中一个消费场景来分析下支付活动到底发生了什么。
比如,消费者A在沃尔玛买了300元的东西,A持招商银行借记卡在建设银行铺设的线下POS机上进行付款,则整个过程分为支付、清算、结算三步骤。
A在建行POS机上刷卡时,建行POS会判断下发卡行(为招行),并询问招行A所持卡内余额是否大于300元,如果大于,则招行会告诉建行可以消费,此时A需要输入支付pw,建行将支付信息传送至招行,招行会实时借记A300元,并告知建行POS扣款成功,此时支付完成,消费者得到商品,债权债务关系变更为招行与建行之间的债权债务关系。
此 ...
财务知识
会计科目会计科目.xmind
财务报表三大财务报表.xmind
《架构师修炼之道》
刻戒于碑,铸法于鼎
软件特性、质量属性。
将两个元素以某种方式连接在一起,就形成了结构。
module
component-connector 就是我们经常讲的系统交叉点
allocation 就涉及到我们的部署设计
每一本书都会讲到利益相关者,也就是 stakeholder。
主动撰写设计决策,承担设计职责。
软件之所以叫软件,是因为它灵活而易于变动。架构是软件里硬的部分,为变动提供了章法,也制造了约束-否则我们不用经常“对架构产生冲击”,而需要打破架构。
设计原则:
以人为本(能落地能产生价值的架构才是真的好架构)
推迟决策
善于借鉴
化虚为实
推迟决策不是推迟大的设计决策,要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中,导致项目无法受控。
忽视前人的设计,是最低效的设计方法之一。所以寻找架构风格是很重要的。
设计思维模式:
理解:换位思考
探索:尝试各种结构组合,找到最能提升目标质量属性的那种组合。-大多数情况下,是我们手头最简单最现成的解决方案。
展示:用图、表、模型、原型来展示,探讨。原型应该尽量具有交互性,可以直接和客户评审。
评估:评估到底我们要做什么东西
软 ...
《计算机简史》
解决问题的过程,是探索的过程。
19 世纪 30 年代,英国工程师巴贝奇发明了差分机,用来计算数学用表。巴贝奇还构思了分析机,意图使用一般性方法,用来解决通用计算问题。巴贝奇自己还是英国科学学会会员,以及一位经济学家。巴贝奇使用齿轮和条杆来制造分析机,受到时代所限,始终无法落地,没有得到英国政府资助,没有继续下去。后来有长达一百年的时间里,人们转而使用模拟的方式解决问题。
图灵对计算机的贡献是制造了通用机。
冯诺依曼的贡献是制造了“一般性方法”,即编程。
实时计算的发展历程是:美军飞行员的训练需求诞生了旋风计算机,而后又产生了 SAGE 系统。这两个项目为美国的商用计算机行业,培养了大量程序员。而且使 IBM 认识到商用计算机的商业潜力,斥巨资开发了 SABRE 系统。
IBM 是靠生产办公机器起家的。
computer 最早是指计算员。计算机的发展序列为:哈佛马克一号,ENIAC 和 EDVAC、EDSAC(威尔克斯)、UNIVAC。个人计算机首先是阿塔利的“牵牛星 8800”,然后是苹果,苹果 2,丽萨(太贵而卖不出去),麦金塔(平价版 lisa)。
第一个革命性的通用操作系统是 ...
《重新定义团队-谷歌如何工作》
自序领导者总是嘴上以人为本,但对待员工却弃之如敝履。
人的一生用在工作的时间是最多的。工作的经历-甚至为最好的一些雇主工作-令人动力尽失、丢掉本性,这样是不对的。
杰克韦尔奇和人力资源主管比尔康纳迪共同建立了广受赞誉的员工管理体系,严格按照绩效表现对员工进行排名,每 12 个月至 18 个月重新调配拔尖人才的工作岗位,同时还在纽约的克罗顿维尔建立了全球培训中心。
20-70-10 的绩效排名体系。最开头的人才会得到赞扬,最末位的人才要遭到解雇。
韦尔奇最著名的是他的六西格玛(six-sigma)。
谷歌的企业文化不提倡穿西装工作。
前言 为什么谷歌的原则也对你适用“10 亿小时之前,现代智人出现。
10 亿分钟之前,基督教诞生。
10 亿秒之前,IBM 个人电脑发布。
10 亿次谷歌搜索之前……是今天早上”
“用心才能让企业成功,心怀这种愿景,不让客户离开时不开心,我们也依此做决定,善待员工,不计成本。”
命令导向型、低自由度的管理方式非常普遍,因为这种管理方式下容易产生效益,需要耗费的精力较少,而且绝大多数经理都畏惧其他的管理方式。管理一个按指令办事的团队很容易。但是要想他们解释做某 ...
面向不确定性编程
本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。
本文探讨到底不确定性和复杂性源于何处,并引出互联网业务系统的一种“可适应性架构”,适用于平台型业务系统。
定义问题软件难写,是软件工程师的共同感觉。
特别地,对于中国的互联网公司的“业务团队”的工程师而言,“业务系统”在业务的复杂度堆积到一定程度以后,软件本身的“熵增效应”会特别严重:一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支,以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处,去做高风险的维护工作。但是,只要公司正常发展,业务总会越做越大/复杂,所以要维持系统的可维护性,成为了一门很重要的学问。
现实中的系统的高复杂度问题,可以简单表述为“不确定性矛盾”:需求具有高度不确定性,一直都在高速变化;而工程师高度倾向于确定实现(因为高度抽象、反复抽象的成本很高),所以具体的实现难以变更,这两种相反的特性难以调和。
其实我们现在遇到的困境,历史上发生过很多次,比如我们现代的很多软件工程理论,就是从历次的软件危机中诞生的。归根结底,软件之所以叫软件(Software),是因为相对于硬件 ...
郭东白博士《关于中台的思考和尝试》
FROM:《关于中台的思考和尝试》
围绕中台的争议非常多,但是往往争议的原因是连中台这个概念都完全没有达成共识,可以说是毫无意义的争吵。在 12 月 20 日由极客邦科技举办的 QCon 全球软件开发大会 2020(上海站)上,车好多 CTO 郭东白博士发表了主题演讲《从中台技术谈架构师的独立思考能力》。由于演讲时间有限, 关于中台的思考没办法讲得非常透彻,本文是对演讲的补充,期望能与大家形成思想碰撞。识别文末二维码,可免费下载郭东白博士的主题演讲PPT。
中台的定义我们的讨论先从定义中台这个概念开始。
定义中台我认为可以有两个角度, 一个是从中台本身的价值和出发点来: 中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合;另一个定义从中台的相对定位来:前台是面向终端用户的一组业务能力,业务中台是对前台应用的抽象,提供多个前台业务之间共享的业务逻辑、数据和计算能力。
我想特别强调这个定义是相对中性的, 我们能够通过这个定义区分什么东西是中台,什么不是中台。有的中台定义严格来说不是定义, 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略目标”、 ...
如何写复杂业务系统
引言本文只是一家之言。
本文是一系列文章的缩略版本(完整版只写了个开头),尽量只讲具体的东西,如果有东西太干了,没有具体的“体感”,是作者的责任。
不喜欢看纯理论分析的可以跳到单一系统层次和模块设计(大多数人可能更加关注这一节,其实前面的部分更重要)。
几个很干的原则
解决复杂问题要用高级思维,不要用低级思维。
蚂蚁/ebay 等若干家企业架构师四大原则 - 听过的可以往下跳:
分治(其他所有原则都是从分治里衍生的)
分层
抽象
演化
solid 5 原则很重要很重要 -很多人读过,很多人可能没有读过,温故知新很重要。
注重过程质量,拿到结果质量。
业务系统为什么难写?纯粹的业务驱动:技术的输入和决策完全来源于业务同事,甚至只受业务摆布的团队,架构容易混乱
业务又不懂架构、业务又不懂功能点罗列的合理性,业务只会往技术团队身上扔需求。
怎么把需求和实现分门别类是技术自己的事情。
但技术人员如果一直都很忙,没有自己的空闲时间或者对设计洁癖的坚持,慢慢地就会养成“把需求翻译成代码,然后往老的系统里面扔”(混乱根源 1)的坏习惯- 问题:翻译只是普通的低级思维,不能解决很复杂的问题。
...