小屋I+Tea+Book+Wife=My LifeSkip to contentAbout« Older posts第2章 组织领域逻辑2011/08/13 – 13:36领域逻辑的组织有3种主要模式：事物脚本领域模型表模块By cottage|Posted in 企业应用架构模式|Comments Off第1章 分层2011/08/06 – 11:31分层是一种重要的技术。也有缺陷：层次不能封装所有的东西。有时它会为我们带来级联修改。过多的层次会影响性能。分层中最困难的问题是：建立哪些层次，每层的职责是什么。三个基本层次：表现层领域层：逻辑，系统真正的核心数据源层By cottage|Posted in 企业应用架构模式|Comments Off0 引言2011/08/06 – 11:00企业应用的特点：持久化数据大量数据很多人同时访问大量操作数据的用户界面屏幕与其他企业应用集成业务逻辑复杂通过简化架构和过程，将一个大型项目简化成小型项目。关于性能的几个指标：响应时间响应性：系统响应请求的速度有多快。等待时间吞吐率负载：系统当前的负荷。如，20个用户连着系统。负载敏感度：响应时间随负载变化的程度。A系统10用户时，平均0.5s，20用户平均2s；B系统同样情况下响应时间变化不大，则A系统敏感度更高，也就是衰减的快。效率：性能（可以指吞吐率或响应时间）除资源。如，4个cpu，120tps，比率为30；2个CPU，20tps，比率为10；则前者效率高。可伸缩性：向系统加资源（通常是硬件）对系统性能的影响。如加了2台服务器，性能提高一倍。By cottage|Posted in 企业应用架构模式|Comments Off第8章 注重实效的项目2011/07/17 – 11:5360 围绕功能，而不是职务进行组织。组织代码的原则也适用于组织资源，如解耦，正交性等，有助于使团队作为整体与变化的各种效应隔离开来。61 不要使用手工流程尽可能自动化62 早测试，常测试，自动测试65 测试状态覆盖，而不是代码覆盖覆盖分析工具的覆盖率只是个参考，软件有无彻底测试，要看软件的各种状态是否被覆盖。66 一个bug，只抓一次bug出现一次后，应该写入自动化测试里，每次都检查。44.全都是写所有的文档都是代码的反映。如果有歧义，代码才最要紧—无论好坏。代码应该有注释，太多和太少一样糟。一般而言，注释应该讨论为何要做某事，它的目的和目标。代码已经说明了它是怎样完成的,为此注释是多余的。45.极大的期望项目的成功是由它在多大程度上满足了用户的期望来衡量的。69 温和的超出用户的期望额外的一英里。70 在你的作品上签名By cottage|Posted in 程序员修炼之道|Comments Off第7章 在项目开始之前2011/07/09 – 11:4336节 需求之坑完美，不是没有什么需要增加，而是没有什么可减。分清什么是政策，什么是真正的需求。需求是抽象的。找出用户为何这么做的原因，而不是方式，并记录下来作为开发决策时的参考。好的需求文档保持抽象。不要太过具体。政策类可另记。53. 抽象比细节活动更长久54.使用项目词汇表37节 解开不可能解开的谜题问题通常有很多约束，但其中有假想的，有真实的。尊重真实的约束，打破假想的约束。”找到盒子“—找出那些问题真正的约束。56.倾听反复出现的疑虑—等你准备好再开始57.对有些事情“做”胜于“描述”规范越来越详细，回报会递减，甚至负回报。58.不要做形式方法的奴隶注重实效的程序员批判地看待方法学，从各种方法学中提取精华，融合成每个月都在变得更好的一套工作习惯。By cottage|Posted in 程序员修炼之道|Comments Off第6章 当你编码时2011/06/25 – 11:4544 不要靠巧合编程47 早重构，常重构需重构的特性：重复，违反了DRY原则非正交的设计。过时的知识。需求变了，对问题了解的更深刻了，等。性能重构的建议：不要试图重构的同时增加功能开始重构前，确保有良好的测试。采取短小，深思熟虑的步骤。48 为测试而设计49测试你的软件，否则你的用户就得测试50不要使用你不理解的向导代码By cottage|Posted in 程序员修炼之道|Comments Off第5章 弯曲，或折断2011/06/05 – 12:2036.使模块之间的耦合减至最少函数的得墨忒耳法则，某个对象的任何方法都应该只调用如下情形的方法：类自身的方法参数传入的对象方法内创建的对象直接持有的组件对象(如基础库)然而，降低耦合也有代码，包装器类的数量会增多。在项目中需权衡。37.要配置，不要集成颜色，文本，数据库，算法等可以通过配置而不是集成来实现。38.将抽象放进代码，细节放进元数据。为一般情况写程序，具体情况放到别处（元数据）。By cottage|Posted in 程序员修炼之道|Comments Off第4章 注重实效的偏执2011/05/21 – 11:52你不可能写出完美的程序。31. 按照合约进行设计32.早崩溃如果一个错误发生了，与其让系统继续可疑的运行，不如及早中止系统。33.如果它不可能发生，用断言确保它不会发生。34.何时使用异常异常不应作为程序流程使用，它是另一种”goto”，泛滥使用会让程序难以维护。异常用于意料之外的事，如，某个文件肯定存在，但偶发情况下也会不存在，此时使用异常；如果文件可能存在也可能不存在，此时返回错误状态(True/False)。35.要有始有终资源使用要结对，有初始化就得有清理。By cottage|Posted in 程序员修炼之道|Comments Off第3章 基本工具2011/04/04 – 13:19工具放大你的才能。工具越好，越能掌握用法，你的生产力就越高！14. 纯文本的威力用纯文本来保存知识。因为纯文本不会过时。更易懂更容易测试linux下有大量文本处理工具可以成为公共标准进行通信15.shell游戏利用好shell！它能使你的生产力放大无数倍！16.编辑器用好一种编辑器！它可配置，可扩展，可编程。
17.源码控制
总是使用源码控制。即使电话本，使用一次的代码，只开发一周的项目等都使用源码控制。它还可以帮你实现自动化构建系统。
18.调试
修正问题，而不是指责。
橡皮鸭。对一个同事解释这个问题，对方不需问答什么，只需倾听和点头。
先不要怀疑第三方代码，如OS等，检查自己的代码。
找到bug后，要反思原因，并想办法不重犯。
19.文本操纵
学会一门文本操纵语言
20.代码生成器
编写能编写代码的代码（write code that writes code）
By cottage
|
Posted in 程序员修炼之道
|
Comments Off
第3章 架构优化和索引
2010/11/17 – 21:22
3.1 选择优化的数据类型
更小。如:tintint 好于 int
简单。比较操作int好于字符串
尽可能定义为NO