读书笔记
逐梦如风
这个作者很懒,什么都没留下…
展开
-
97条架构建议之持续集成-进度调整-取舍
97条架构建议之持续集成-进度调整-取舍持续集成尽早构建,持续集成,每次构建和集成都保证系统的稳定性和可用性。可以提高软件的开发效率避免进度调整失误导致项目失败的原因很多。有些情况我们可以通过加班,等等解决~~最可怕的是时间不变,任务量增加,或者任务量不变,截止时间提前。有种错误的观念:加快速度可以降低成本。由此你可能必须放弃一些看起来不太重要的任务,比如单元测试之类的,就算交付时间不变也要增加原创 2016-11-03 11:46:24 · 415 阅读 · 0 评论 -
深入浅出mysql之基础篇
深入浅出mysql之基础篇mysql的安装windows linux mac 安装会有不同数据库的三大范式1.第一范式(确保每列保持原子性)第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。2.第二范式(确保表中的每列都和主键相关)第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关原创 2016-10-31 15:57:41 · 1403 阅读 · 0 评论 -
深入浅出mysql值开发篇一
mysql学习笔记之开发篇一存储引擎的选择插件式存储引擎是mysql的重要特性,用户甚至可以定制自己的存储引擎存储引擎的分类和他们的特点myisam,innodb,bdb,memory,merge,example,ndb cluseter, archive,csvblackhole,federated查看支持的存储引擎: show engines 或者 show variables like原创 2016-10-31 17:51:35 · 794 阅读 · 0 评论 -
97条架构建议-现实-观察-两面
97条架构建议-现实-观察-两面现实程序世界是可控的有逻辑的,而现实世界却是不可控的。可能出现各种意外的情况。我们设想的完美世界可能在崩溃,我们需要接受现实,然后分阶段去改良我们的代码。观察我们已经进入了分布式,松耦合的时代。松耦合的时代的特点是系统足够灵活,可能因为一点点小变动就支离破碎。设计的演变的,是随着时间不断的灵活变化的。架构师不能妄想掌控一切,这会设计出紧耦合脆弱的解决方案。设计系统我们原创 2016-11-16 10:11:33 · 871 阅读 · 0 评论 -
97条架构建议-架构平衡-负责-多方案
97条架构建议-架构平衡-负责-多方案架构设计要平衡兼顾多方需求软件架构常考虑的:系统建模,定义接口,划分功能模块套用模式,优化性能安全性,易用性,产品支持,发布管理,部署方式等问题除了上面的技术架构外,软件架构师还必须考虑各方的要求和利益。只有充分考虑了各方面的要求,才能确保需求说明书的完整性。架构师实现的一组最终目标可以通过逐步分析相关各方的需求得到。这个分析过程应该贯彻整个软件开发过程。原创 2016-11-01 10:26:01 · 1283 阅读 · 0 评论 -
97条架构建议-边界-团队-决策
97条架构建议-边界-团队-决策边界架构师应该聚焦在边界和接口,大型的软件的边界有时很难界定而且各个领域之间互有纠缠,开发出高内聚低耦合的软件是不易的,我们可以采用一个情境的地图去描述这些边界,能够关注这些部分,开发出高内聚低耦合的软件团队诸事说易行难。架构师容易陷入吹牛皮的状态。其实架构师和架构师的团队一样重要帮助团队有利于项目的展开1 确保开发人员所需工具和工具的熟练度2 确保开发人员的技能,原创 2016-11-17 13:39:27 · 1077 阅读 · 0 评论 -
97条架构建议-业务目标至上-简单可用-亲力亲为
97条架构建议-业务目标至上-简单可用-亲力亲为业务目标至上业务目标驱动,架构师应该在实际的业务目标和实际的开发条件下制定决策系统架构师预估商业价值,避免技术决策造成经费超支建立反馈回路:大图表持续集成频繁发布先确保解决方案简单可用,再考虑通用性和复杂性不能一味强调通用性而不考虑具体应用,从具体中提炼出通用的解决方案先保证方案简单可用,再考虑从业务分析出通用性和复杂性。架构师应该亲力亲为架构师原创 2016-11-02 15:02:27 · 968 阅读 · 0 评论 -
97条架构建议-空白-行话--情境
97条架构建议-空白-行话–情境留意架构中的空白部分软件系统由相互依赖的程序组成,我们装备这些程序和方法见的关联叫做架构我们一般会通过简单的图形表示系统,这是种抽象和概括。其实系统远比这复杂,还有许多空白需要填补。包括硬件的问题。在确定主干后,我们应该考虑更多,考虑越多我们最后遇到的问题就越少。学习软件专业的行话每个行业都有它自己的行话,软件行业也不例外。架构和设计模式就是架构师的行话。架构和设计模原创 2016-11-14 16:25:11 · 969 阅读 · 0 评论 -
mysql学习笔记之管理和维护篇(二)
mysql学习笔记之管理和维护篇(二)MySQL备份与恢复 好的备份方法和策略,能让数据库更加高效和安全。数据库的备份分类:逻辑备份和物理备份备份时需要考虑的因素:1 确定备份的引擎是事务引擎还是非事务引擎,两种引擎的备份方式是不一样的2 确认是全量备份还是增量备份。恢复的时间的查表3 可以考虑做异地复制的方式备份,但是复制不能代替备份4 要定期做备份,备份周期需要考虑5 打开log-b原创 2016-11-14 18:08:03 · 1200 阅读 · 0 评论 -
97条架构建议-管理者--建筑师--重复
97条架构建议-管理者–建筑师–重复管理者架构师更像一个厨师,一个管理者,找到合适的人,做合适的事情,能够协调大家的工作,既有广度,也有深度。 知道如何鼓励大家,尤其是看不到希望的时候。架构师应该考虑技术方面的问题,也要考虑非技术的问题,考虑所有开发人员的性格,为合适的人员安排合适的工作。让大家有机会充分磨合,相互适应,轻松化解各种难题。建筑师建筑师中适用于架构师的理论太多了。向建筑师学习,软件架原创 2016-11-15 10:18:11 · 426 阅读 · 0 评论 -
97条架构建议-假设-分享-模式病
97条架构建议-假设-分享-模式病事实和假设应该记录下每个决策背后的理由,当这一决策包含权衡(性能,维护,成本,上市时间)时尤须如此事实和假设是构建软件的两大支柱,确保软件的基石是否稳固一定要分清楚哪些是事实?一定要分清楚哪些是假设?分享分享知识和经验。真诚的希望通过分享知识和经验,帮助业界持续发展,这也能帮助我们理解和修正一只的知识和经验模式病根据实际情况使用设计模式原创 2016-11-18 14:32:34 · 419 阅读 · 0 评论 -
97条架构建议之隐喻-维护-舍得
97条架构建议之隐喻-维护-舍得不要滥用架构隐喻架构师喜欢使用隐喻。对那些比较抽象,复杂和变化移动的目标,隐喻提供了很好的具体媒体。很容易让人沉迷,滥用隐喻。可能出现的问题隐喻可能导致乐观的解读系统,导致系统缺少任何约束可能缺少对实际业务关注关注应用程序的支持和维护应用程序的支持和维护永远都不应该是时候才考虑的事情,应用程序80%的生命周期 都是在维护上,设计时应该多多关注支持和维护的问题。我原创 2016-11-20 10:08:38 · 679 阅读 · 0 评论 -
97条架构建议-规则-可用-数据
97条架构建议-规则-可用-数据数据是核心数据是系统的核心,如果以为编程是函数,方法对象的集合和只从这方面考虑问题就不会全面的看问题。从数据结构的角度理解系统能够让我们更加容易的,清晰的了解系统, 略过了许多不必要的细节,我们能把握系统的核心。每次数据结构的调整,将会引起较大的变动,对待数据不能不慎重。可行走的骨架我们做一个权衡,分析系统,考虑现在和未来,同时做一个可行走的骨架,然后不断的迭代和增原创 2016-11-21 13:36:48 · 747 阅读 · 0 评论 -
97条架构建议---代码的用处-不存在绝对的方案-提前关注性能问题
几行代码可能比架构更管用设计拥有的无穷魅力,我们容易陷入其中,无法自拔。我们最后会确定架构的最终产物,架构说明书(或者图稿)。我们既需要了解上层组件之间的交互,也需要了解组件内部代码的组织,这样我们不会使我们的架构脱离实际。应该珍惜自己写代码的时光,它不是在分散精力,它是在扩展你的视野和微观世界。不存在放之四海而皆准的方案不存在放之四海而皆准的方案我们需要根据系统的实际情况去分析,决定选择哪种方案。原创 2016-10-31 10:49:15 · 694 阅读 · 0 评论 -
关于阻塞,非阻塞,同步,异步
对于io 的调用过程分两部分 1 等待数据就绪 2 从内核拷贝数据如果从使用的角度来说我们只需要看手册了。 但是咱们还是得明白他的原理,这是一个很奇妙的事情哦。粗略的总结下: 对于阻塞io,等待数据就绪就阻塞了 对于非阻塞io,等待数据就绪不会阻塞,可是从内核拷贝数据还是要阻塞的对于同步,包括 1 等待数据就绪 2 从内核拷贝数据 这个两个过程调用完成之前原创 2016-10-21 10:14:39 · 416 阅读 · 0 评论 -
97条架构建议-重视数据库-确定不确定性-关注细节
97条架构建议-重视数据库-确定不确定性-关注细节打造数据库堡垒业务变化,人员变化,可是数据库却很少变化。牢固的数据模型一直会很少变化。牢固的数据模型真的是太重要了。牢固的数据模型需要既要保证数据的安全性,又要保证可扩展性。牢固的数据模型要素隔离来自应用层的bug遵守引用完整性的规则使用域约束恰当的键阻止无意义的关系必须在开始构建数据库的时候,深刻理解业务的需求。确定的不确定的问题确定你的原创 2016-11-04 11:23:55 · 559 阅读 · 0 评论 -
97架构建议之复用-重点-俯瞰
97架构建议之复用-重点-俯瞰让大家学会复用有人认为大家使用优良的框架就自然知道如何使用里面的功能,懂得如何复用里面功能,不是重复造轮子,其实这里面存在误区。如果想要做到被复用可以从以下三点入手:大家知道知道它们的存在 wiki,邮件,群大家知道如何使用它们 细致精确的文档让大家认识到利用已有资源好过自己动手 这你也必须需要保证自己的功能是可靠的架构里拒绝自以为是架构师原创 2016-11-05 22:34:34 · 399 阅读 · 0 评论 -
97条架构建议-多尝试-掌握领域知识-设计
97条架构建议-多尝试-掌握领域知识-设计先尝试再建议架构需要详细的分析,分解业务再做决策先接触项目在进行架构选型,这个时候你得尽可能多的收集业务相关的信息。你也可以推迟架构决策,尽可能多的收集项目相关的信息,因为确定架构后再去调整它的代价是最大的。掌握领域相关的业务知识对架构师来说,技术知识基础,快速的学习和完善你的业务领域知识,才能让你做出尽可能好的决策。熟练的业务知识,有助于沟通,增加客户的信原创 2016-11-07 11:33:40 · 530 阅读 · 0 评论 -
mysql学习笔记之优化篇(二)之锁
锁问题 mysql锁的分类 1 表锁,开销小,加锁快,不会出现死锁,锁定粒度大 2 行锁,开销大,加锁慢,会出现死锁,锁粒度小 3 页面锁,介于两者之间,会出现死锁myisam 表锁,适合读多的程序innodb 行锁,适合写多和并发高的程序查看表锁的状况show status like 'table%';| Table_locks_immediate | 504 || Ta原创 2016-11-07 15:54:32 · 1185 阅读 · 1 评论 -
mysql学习笔记之优化篇(二)之参数-磁盘-应用调优
优化MySQL Server通过调整mysql server的参数来优化mysql server的效率查看mysql信息和状态查看mysql server参数show variables;查看运行状态 show status;影响mysql性能的重要参数适用于myisam key_buffer_size 设置索引块缓存的大小 查看当前的:show variables li原创 2016-11-07 17:27:02 · 1140 阅读 · 0 评论 -
97条架构建议-信任程序员-时间-架构专业
97条架构建议-信任程序员-时间-架构专业信任程序员你也是程序员过来的,程序员可能擅长写代码,却忽略一些沟通和协作性的问题,又或者是他们实在是做的很烂,你可以指导他们,我觉得最好的办法是使他们有参与感,主动的提出问题。时间的力量时间带走一切曾经看起来美好的东西,大浪淘沙。如何和时间有效沟通选择值得投入精力的工作,明白重点简单原则别跟以前的工作过不去--别自卑,昂步向前争议话题:是否该设立架构专原创 2016-11-08 10:13:46 · 670 阅读 · 0 评论 -
软件架构师应该知道的97件事之复杂性-技术之外-简明沟通
软件架构师应该知道的97件事之复杂性-技术之外-简明沟通简化根本复杂性,消除偶发复杂性业务的复杂性是必然的,我们需要对业务进行分析,对业务的复杂性进行解耦,解耦的过程中有可能产生偶发的复杂性。理科生有个通病,我们喜欢解决复杂的问题,并由此产生自豪感。这个毛病在软件开发上可能带来致命的缺陷。后期维护成本巨高,这点我们得警惕。复杂大多人都会,如何化复杂为简明,这需要高超的技艺了。关键问题可能不是出在技术原创 2016-10-28 10:29:44 · 623 阅读 · 0 评论 -
97条架构建议-道德-管家-规模
97条架构建议-道德-管家-规模控制规模规模是软件的大小。规模的组成项目完成时间人工和资源功能质量难度风险遵守哪些约束条件规模大一倍,项目失败的概率增加十倍的原因1 作者的直觉,更多资源,更多的沟通2 估算与科学计算相差甚远缩小和控制项目的规模1 抓住正则的需求。客户的需求+公司的效益。2 分而治之。大项目划分为小项目3 设置优先级。4 尽快交付敏捷开发提倡:最简单有效的东原创 2016-11-09 10:52:13 · 1125 阅读 · 0 评论 -
软件架构师应该知道的97件事之架构决定性能-分析背后原因-起来发言
架构决定性能架构决定性能。架构才是影响应用的性能和可伸缩性的决定性因素。我们无法通过简单从架构调优和简单的更换软件解决架构问题。分析客户背后的意义我们应该询问客户,分析客户要求的功能和需求的真正的意义,定位真正的问题,从而提出比客户的建议更爱好,成本更低的解决方案。理顺轻重缓急,把最重要的放在第一位。我们需要引导客户说出为什么,因为有时候客户总是以为这个原因是不言而喻的。起立发言架构师应该重视推销自原创 2016-10-29 17:11:35 · 793 阅读 · 0 评论 -
97条架构建议-大厦-混合开发-性能
97条架构建议-大厦-混合开发-性能大厦摩天大楼是没法伸缩的。不爆炸式的软件部署是行不通的。我们应该是逐个部署系统组件。优点如下:1 将风险分散到各个时间段2 迫使我们设计清晰的组件接口,提高系统的一致性和降低耦合性我们可以尝试“尽早发布” 和递增式部署的方式开发软件。混合开发混合开发早就来临了~~。Rest架构风格已经普及~混合开发的时候我们需要注意编程的规范,否则将会导致混乱。架构师需要原创 2016-11-10 13:58:45 · 1007 阅读 · 0 评论 -
高级io函数与服务器程序规范
高级io函数单向管道实现管道pipe(int fd[2]) fd[0]读 fd[1]写双向管道基本本地的,前三个参数和socket一模一样 socketpair(int domain,int type, int protocol,int fd[2])dup函数和dup2函数dup(fd) 复制一个新的描述符,和原来的一样,总是取得当前系统可用的最小值dup(int fd1,int fd2) 同原创 2016-11-10 15:42:01 · 561 阅读 · 0 评论 -
软件架构师应该知道的97件事之架构决定性能-故障终会发生-我们在谈判-量化需求
故障终究会发生硬件错误,可以增加冗余,避免单点错误软件也会出错,我们增加额外的监控程序人无完人,我们把操作,诊断和处理都编程自动化。降低了主动犯错的概率,却增加了错误被忽略的概率。我们为自动化增加监控,结果是更多的软件,导致更高的故障率。系统故障终究会发生,隐患无法彻底消灭。我们需要事先设计防范故障的模型,否则我们无法应对威胁系统安全的意外情况我们常常忽略自己在谈判我们真的常常忽略自己在谈判。我们可原创 2016-10-30 10:39:55 · 558 阅读 · 0 评论 -
97条架构建议-简单-开发-决策
97条架构建议-简单-开发-决策根据投资回报率进行决策我们对项目的每一个决策—无论是技术过程,还是人与人相处,都可以看作是一种投资形式。我们可以使用投资回报率作为衡量架构决策的标准之一。确保架构的务实和恰当的架构师首先是开发人员不管设计方案做的如何优秀,决定实现是否成功的重要因素之一是开发人员愿意开发。架构师的主要目标是创建可行,可维护的解决方案,并能够解决当前的问题。能够帮助开发人员解决问题是很重原创 2016-11-22 13:56:49 · 1027 阅读 · 0 评论