随笔分类 - 阅读笔记
摘要：架构设计不是纯粹的技术问题，是要面临对技术与业务的关系问题，最终，要求架构师不仅懂技术，懂业务，而且能理顺复杂的技术与业务之间的关系。架构设计就是要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁，所以架构师必须懂需求，不用像需求分析师那样懂各种需求技术，但需求类型、需求影响架构的原理、质量属性
阅读全文
摘要：通过阅读这部分，学到如下： ##1.关于概念架构和细化架构 1）层次：系统 用户 业务 角度：功能 约束 质量属性 2）架构=组件+交互 3）概念架构仅关注高层组件，对高层组件的“职责”进行了笼统的界定，并给出了高层组件之间的相互关系，其不涉及接口细节（只有抽象组件和抽象交互机制）。 4）而在细化架
阅读全文
摘要：通过阅读第前5章，我明确了很多概念性的东西，比如，用例是功能需求的实际标准，用例涉及但不涵盖非功能需求等。本书在绪论部分讲到了四个核心主张，通过阅读后面的，我发现这四个主张贯穿本书全文。 1）方法体系是大趋势 一线架构师真正需要的，是覆盖需求进、架构出全过程的实践指导--只有综合了不 同方法优点的“
阅读全文
摘要：通过阅读第三篇案例分析，我对第13章大型网站典型故障案例分析印象深刻。其一，流程规范。文章中案例讲的是发现某应用发布以后数据库Load迅速飙升，超过报警值，发现该应用发布后出现大量数据库读取操作，而这些数据本来应该从分布式缓存读取。检查发现，缓存的代码被注释掉了，开发的时候忘了取消注释。 自己平常写
阅读全文
摘要：软件架构需要考虑具体的功能模块以及非功能的设计与决策。系统的各个重要组成部分及其关系构成了系统的架构，这些组成部分可以是具体的功能模块，也可以是非功能的设计与决策，他们相互关系组成一个整体，共同构成了软件系统的架构。一般来说，除了当前的系统功能需求外，软件架构还需要关注性能、可用性、伸缩性、扩展性和
阅读全文
摘要：消息队列。在书中第一章给出的网站架构图中，提到将用户管理，商品管理等共同的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作。大多数网站架构问题都可以通过这个解决。在这个架构中，网站被拆成了许多不同的应用，
阅读全文
摘要：其一，如何切分架构。切分就是利益的调整，当人们认识到要主动的去切分一个系统的时候，毫无疑问，我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点，这是大方向。那确定问题主体以后，系统的利益相关人就确定了下来，那么某个或者某些利益相关人负载太重；时间上的负载太重；空间上的负载太重，本质上还是时
阅读全文
摘要：就架构入门来讲，我觉得本书是非常适合阅读的。首先，什么是架构，又怎么理解架构，然后如何做好架构。先解决其一，架构的来源于社会的分工，同一个事情分解成多个小事情，让擅长的人完成擅长的事情，又快又好的完成部分局部工作，最后组合成一个整体，并完成这个整体所需要的所有活动，这就是架构。架构是一个动词，是解决
阅读全文
摘要：摘自百度百科：所谓架构师，通俗的说就是设计师或结构设计者，这些定义如果用在建筑学上，则是很容易理解的。在软件工程领域中，软件架构师实际上就是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者。 正如《架构漫谈》作者所说，架构师必须是一个组织的领导人。软件架构师的主要任务并不是从事
阅读全文
摘要：这周读了《代码大全2》的第27-35章，将印象深刻部分整理如下： 第一处是关于软件开发的规模。作者提到如果你习惯于开发小项目，那么你的第一个大中型项目有可能严重失控。对于个人项目，你需要做的就是与顾客的交流，人越多，需要花在交流的时间越多，这个时候就需要取一些组织技术来改善交流效率，比如采用正式文档
阅读全文
摘要：这周阅读了《代码大全2》的第13-26章，整理出几处印象深刻的如下： 第一处是关于如何改善软件质量。一种强有力的方法就是根据软件的各种外在特性和内在特性明确定义出软件质量的目标。这个步骤经常被忽视，一般来说，只有设立了明确清晰合理的目标，程序员就会知道该朝着哪个方向去努力。然后接下来要明确定义质量保
阅读全文
摘要：这周我开始读《代码大全2》，现在已经读了该书的1-12章，将对我比较重要的部分整理如下： 第一处是前期准备的重要性。在项目的初期、中期、末期都要考虑质量。这点我是深有感悟的，自己以前都是一直堆代码，直到写完了才运行开始找错找bug，可是这样做的效率并不高。会花费很多的时间去找错。可是如果自己一开始就
阅读全文
摘要：这段时间我读完了第13-17章，将对我影响深刻的部分整理如下： 第一部分是软件的质量保障问题。软件质量 = 程序质量 + 软件工程质量 程序的质量体现在软件外在功能的质量。衡量软件的功能，基本的判断可以 用“是|否”来判定。程序的质量还有其他方面，例如用户体验的质量、国际化的质量和安全性的质量。 这
阅读全文
摘要：这段时间自己阅读了构建之法的第7-12章，现将感觉对自己帮助比较大的地方整理如下： 第一处是关于如何找到需求。我觉得这个对自己是很有帮助的，我们这次让开发团队项目，可是自己并不知道如何做起，怎么去寻找用户需求。用户会提各种各样的问题，可是怎么能够把这些问题快速梳理，做出一个较为准确的需求，我觉得这是
阅读全文
摘要：第一阶段读了构建之法的1-6章，感觉自己收获比较大、印象深刻的有如下几处： 第一个是初级软件工程师如何去成长的问题。 1.要积累软件开发相关知识，提升技术技能。 技术有很多种，你不需要做到全会，但至少你要对其中一种做到熟练掌握，每一个都懂一点，每一个又都不太懂，这样的感觉以后如果在公司最多就是个杂工
阅读全文
摘要：第六章阅读笔记及其个人感受 我们想要让编写代码所花的时间越少，想要尽可能在开发周期的早期抓住并修正代码错误，想要在一开始就少制造错误。如果我们能够深思熟虑的编程，那这些会对我们有所帮助： 总是意识到你在做什么。 不要盲目的编程。（试图构建你完全不熟悉的应用或者使用你不熟悉的技术） 按照计划行事，不管
阅读全文
摘要：第三章阅读笔记及其个人感受 笔记1）要接受事实：调试就是解决问题，要据此发起进攻。 个人感受1）自己以前很抵触调试，因为觉得调试特别麻烦，比如写一篇博客需要两个小时吧，调试却整整需要花上一天都不一定能够改完所有的bug。这种心态很不好，首先应该学会接受事实，而不是逃避。在发现了别人的bug之后，不是
阅读全文
摘要：这段时间读的是第1章注重实效的哲学和第2章注重实效的途径。 第一章阅读笔记及其个人感受 笔记1）在所有的弱点中，最大的弱点就是害怕暴露弱点 个人感受1）感觉自己过去经常逃避问题，害怕面对自己的缺点、弱点，可是这样很不对。一个注重实效的程序员会对他自己的职业生涯负责，并且不害怕承认无知或错误。发生了这
阅读全文
摘要：终于读完了这本《人月神话》，对后面的章节中印象最深刻的部分还是祸起萧墙和银弹章节。 “项目怎么会被延迟了整整一年的时间……延迟的时间是一天天积累下来的”。通常灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。项目进度就是这样，经常以一种难以察觉，但是残酷无情的方式慢慢落后。一天一天的进度落后是难以识别、不容易
阅读全文
摘要：读完了5-11章，收获颇丰，现在想分享一下自己的心得体会和一些要领。 作者提到有一种普遍的倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，所以第二个系统是设计师们所设计的最危险的系统。想到作者举的两个例子，一个是被嵌入到 7090 的 IBM 709 系统，709 是对非常成功和简洁的 7
阅读全文
浙公网安备 33010602011771号