编程随感

1 在你觉得需要写注释的时候写注释：

首先你需要为方法，类或者模块起个简单易懂的名字

如果必须通读一个方法的代码才能了解它做什么，那么开发人员先要投入大量时间和精力才能使用它。反过来说：只需要短短几行注释说明方法行为，就可以让生活更轻松

在class或者module中上部写注释：

说明这个class或者module的用途，并试着用例子来演示使用方法（一个文件中只应该有一个class，module，除非多出的那些类非常简短）


2 通过编写高内聚，低耦合的类，实现关注分离

简单的面向对象分析

oop的原则

1 开闭原则（OCP）

禁止为修改而关闭

允许为扩展而开放


通常来说：一旦有了有效的类并且在使用它，你就不会想要动他，除非有必要。但是记住，改变是软件开发中的一项不变的真理。使用ocp，我们允许通过扩展而改变，而不是回头修正你现有的程序代码。子类能增加并扩展基类的行为，而无需弄乱已知有效且让客户高兴的程序代码

扩展其他类并不是ocp的唯一方法。例如：假如你在类中有一些private方法，那些方法就是禁止为修改而关闭，没有其他程序代码可以弄乱它。

但你可以增加一些以不同方式调用这些private方法的public方法。你正在扩展这些private方法的行为，而无需改变它们


2 不自我重复原则
通过将共同之物抽取出来并置于单一地方来避免重复的程序代码
次数是3


3 单一职责原则
你的每一个对象都只有一个改变的理由
在良好的应用程序里，一个类只做一件事且把事情做好，并且没有其他类共同分担此行为


4 liskov替换原则（LSP）

子类型必须能替换父类型（否则，当引入新的类之后，调用代码必须经常评估并修正，而且，你也让契约不一致了）

能快速响应需求变化才是好的软件


模式的原则

1 隔离变化之物

2 针对接口编程，而不对实现编程

if is_car

my_car = Car.new

my_car.drive(200)

else

my_plane = AirPlane.new

my_plane.fly(200)

end

my_vehicle = get_vehicle

my_vehicle.travel(200)


3 组合优于继承（汽车）


4 委托（链接和聚合）


3 代码复审

A -》 B

一段时间后

A -》 C

让别人审核自己的代码，但是别人是不固定的


4 测试驱动开发

先用它再实现它


消除那些还没有编写的类，这会很容易简化代码。相反，一旦你已经编写了代码，也许会强迫自己保留这些代码，并继续使用它

让你的测试作为你的代码的第一个用户


5 度量真实的进度


我们不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没完成。如果你最初估计这个任务需要40个小时，在开发35个小时后，

你认为还需要另外30个小时的工作，那就得到了很重要的度量结果（这里诚实很重要，隐瞒真相毫无意义）


6 什么是完成

1 写完

2 测完

3 交付完


在要求时间的时候还要为意外考虑（容错机制，避免在压力中开发），而意外是不可预估的，我个人是一切顺利的时间 * 1.5


7 开发时的注意事项


不要让瀑布思维侵蚀迭代项目

需要强调的是：瀑布思维仍然时常侵蚀着迭代项目。“让我们在开始编程前编写完所有的测试“，或者“让我们在开始编程前完成全部设计“


变更对于软件项目是永恒的，之所以用迭代，最常见的情况是：“不错，这是我要求的；但现在我试用过后，发现和我现在真正想要的有一些差异。“

这种不错……但是的过程并不是失败的标志，与之相反，早期频繁地在不错……但是中循环，正是改进软件和发现什么是真正有价值需求的途径


所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的


需要让团队其他人了解你负责的代码架构和你当前的工作进度。帮助团队识别是否在某些东西上有重复劳动而耗费精力，或者是不是某个问题有人已有现成的解决方案。所以每日立会是必要的，立会上要注意细节。例如：“我正在开发登录页面“就不够详细。要达到“登录页面目前接受guest/guest作为登录用户名和密码，我今天会连接数据库来做登录验证“，这样的详细程度才行。同理，changelog也是必要的。重大的提交，必须有详细的提交信息，方便别人了解你的开发情况和代码复查


8 专家的态度

如果你没有犯过任何错误，就说明你可能没有努力工作

没有任何计划在遇敌后还能执行，所以，改动计划，不一定是坏事。但是做计划还是有必要的。即使初始的设计到后面不再管用，你仍需要设计：“计划是没有价值的，但计划的过程是必不可少的“。在设计过程中学习是有价值的，但设计本身也许没有太大的用处

如果一个团队成员误解了一个需求，某个部分的架构，或者最近一次会议做出的决定，那么也许意味着其他成员也有相同的误解。要确保整个团队尽快消除误解


防微杜渐，不要容忍破窗户

脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或者不太实际的情形去批驳它；再者，你基本无法赢得争论。通常，有个好技巧：引导性地提出一个疑问，让他们自己去意识到问题。


9 系统分析


聚集在那些表示系统本质，最具有商业价值，和最具风险的功能上

在项目架构阶段，你所做的每一件事情都应该减少项目的风险

假如你不需要用例的所有细节，编写详述软件能如何被运用到的场景可帮你快速搜集好需求