Archive

Archive for the ‘$Architecture & design’ Category

程序员提高工作效率的方法

April 29th, 2010 西坪 No comments

最近一段时间以来,效率相当地高。 纵观前些年的工作效率中,少有这么利落快速而且不加班的。 回顾这几年,我工作效率的提高主要有下面的几个方面。

一、集中目标

专注目标。凡是工作效率高的时间段里,工作目标都很明确。每天一上班,心里就想明白了今天要干什么,每天下班时,想想今天都实现了什么,有什么目标还没有实现。尽管每天早上来了先看看股票新闻,中午饭后看看股票新闻,偶尔下午还打个盹什么的,但工作的时候确实格外专注,丝毫也不会走神。

分离与当前无关的任务/问题。
专注目标不是那么容易做到的。印象中以前工作中经常会碰到的问题是工作中遇到的问题。一方面可能得益于基本功的增强,最近虽然也遇到了一些问题,但是都能够通过简单阅读或查找文档,或浏览问题相关的库的源码解决; 另一方面,遇到的问题我总是避繁就简,首先倾向于寻找简单可用可靠的方案,并将心中的疑虑记录下来,集中成一个列表,工作之外翻翻书,系统思考和学习,而不会因为这个问题而叉开思路对相关的内容研究一番。总之,专注当前的任务,把新问题记录下来,回头再专心攻克。

例如我第一次用ibatis,遇到了一些表可以用集合和映射来加强Pojo的OO功能,但是我并不熟悉ibatis的这些特性,并且使用简单的方案也是可行的,于是就直接使用简便方案(在我看来,ibatis主要是将SQL集中起来管理、简化SQL操纵,对OO不感冒)。

工作列表。不论是开发还是设计,一个文本格式的位于源代码存储系统下的待办工作列表与IDE中的TODO项一起构成了专注目标的重要工具。工作目标分解是基本工作步骤,记录工作中产生的新的问题(任务),这样,子问题越来越多,项目中要干的事情越来越丰富。经常性地调整当前工作任务列表,根据重要性对这些任务进行划分。每天都干掉一些问题,经常想着那些最重要的问题。

简单但有迹可寻的设计材料。在思考和工作的过程中,一方面,项目的过程通常比较长,另一方面经验相对丰富的人手头总是有多个事情在并行进行。当时间太长记不清出了或者是切换任务时,经常要查看此前的代码和设计,易于修改以及有历史记录的设计材料对于保持设计思路的完整十分有意义。(设计材料还应该包括重要的图)

正式准确可以依靠的需求文档。这一条无论怎么说都不过分,遇到需求不确定的地方,就去查需求文档。如果没有,就请能够回答的人来回答,委托给他,先去做别的。细想在上一家公司,经常要承担多种角色,甚至连需求也经常没人给一个最终决策,设计开发的时候在模棱两可的需求之间做决定,很烦心。对于一个设计/开发人员而言,需求人员在需求问题方面就是绝对的权威。如果有些建议,可以建议,但一切均以需求/产品人员为准。

单元测试。另一有助于集中精力编码的就是单元测试。单元测试让我集中精力实现当前的功能,需要依赖的其他功能,我总是先生成一个接口,让当前的功能通过测试后再专心去实现该接口。一天下来,一个一个的测试点亮了绿色,一个一个的接口被实现,整天都是十分惬意的。单元测试的另外一个收益就是放心地去重构吧,放心地去做新的特性吧。

二、简化问题的能力

无论是在广义的工作方法/工作态度上,还是在针对具体问题的设计/实现上,我认为最重要的个人能力就是化繁为简了。化繁为简是所有工作方法/软件设计的核心。将那些可以砍掉的工作砍掉(最多做个记录),做到尽可能地经济,尽可能地简单。

从工作方法和态度上来讲,真正需要去做的工作才值得去做,大力砍掉那些不应该在当前工作中处理的事情。例如不必要的优化,不必要的扩展性,不必要的性能,不必要的功能,可以不要的技术,不必要的流程,不必要的文档,统统砍掉,一切可以没有的全都不能有

工作中也可能遇到非关键的难题,通常绕过它们,使用更简单的方案就是了。纠缠于这些不重要的难题,最容易浪费时间。例如,eclipse忽然坏掉了,最好的方法是重装一个; 又如以前我经常自己建一个持续集成服务器,现在我直接养成每次写完代码手工跑一遍的习惯(前提是够用)。简化你的工作!简化!

从设计/实现来讲,最好的方案就是最简单直接、一眼就能看懂的方案。记得刚到一个新的环境,有一个统计任务,既要用到数据库也要用缓存,我做了精细的设计来保证最终一致性,状态流程都很完整,并且使用线程池来并发运行分批处理,最后再合并。虽然控制得很完美很精细,但是流程和结构都很复杂。上头根据此前的项目经验给出了一个更简单的例子,直接将各个任务划分为多个线程,分开存储,到了该统计的时候,冻结数据在所有的分区上做统计。状态砍掉一半,流程缩减一半。

事实上,作为简单直接的一个附带效应,最简单直接的方式,通常性能也最好。

简化问题的能力,是一个人的核心能力。

三、基本功

基本功的内容十分复杂。首先,对整个计算机体系的理解,对操作系统/虚拟机/数据库本质的理解,对语言基础类和库的理解,我觉得是核心基本功

第二项基本功,就是学习能力。 通过快速阅读核心文档理解核心思想,然后其他的东西总是能从文档中查到就行。细枝末节的东西,即学即用,学过就忘可也。

第三项基本功,就是文档、资料的搜索和收集

要想在工作中如行云流水,另外一个方面就是避开暂时还不熟悉的技术和工具,不熟悉的东西很难用好,更难用顺畅。尤其是那些纠结复杂、华而不实的技术,不要去碰。这属于简化能力的范畴。

四、工具

选择工具的核心标准,就是简单朴素可信赖

文本格式的设计,加上易于修改的图。 我喜欢用一个简单的文本格式来记录设计,随时修改,随时查阅。而附上几幅简单直接的图,经常能够更简单直接地表达更多的内容。

简单的可信赖的工具。我曾经将很长的时间用来构建Maven的环境上,用Maven管理依赖,尤其是跟Eclipse协作时,经常出现诡异。现在我用ant,或者只用Maven,maven不与eclipse纠缠在一起。如果一个工具出几次诡异现象,那就干脆丢掉它。

版本管理工具。 不仅仅源码要由版本管理,整个项目过程的所有知识,全部用版本管理系统管理起来,集中存放。现在我用subversion和git。

设计与开发的五条原则

December 15th, 2009 西坪 No comments

从2004年初(大学二年级第二学期)加入学校就业信息网站,靠写代码获得第一笔收入,迄今已经将近六年。

第一条原则,首先弄清你的问题是什么。这一条规则无论怎么强调都不过分。

《Programming Pearls》第二版的开篇,Jon Bentley 讲的就是,首先弄清你的问题是什么! 在你没有详细、明确地定义好你的问题之前,你所做的大部分工作只产出废物。这些年,最头疼的事情,就是经常搞了一大堆东西,累死累活,甚至加班加点,最后总才发现很多事情偏离了目标。但这样的事情,总是在周围一遍一遍地发生。

一个工程师,如果在接到一个问题时首先不是尽可能挖到细致的资料,定义问题,并向了解问题的人去反馈,详细讨论问题的定义。虽然问题定义不是那么容易,但不首先定义好问题,那就是不合格的工程师。

还有很多原则,大抵都是这个原则的派生品。

第二条规则, 弄清你要干什么,以及哪些先干,哪些后干,哪些根本就不需要干。

说白了,就是把问题分解,列个表,排个先后顺序。这是大部分程序员最蹩脚的部分。高效的本质不是捧着ThoughtWorks那本《卓有成效的程序员》,而是我这条原则。我对Joel的书里印象最深刻的就是有关用Excel列任务列表的部分。

这条仍然是如此重要,以致于著名的YAGNI, (You ain’t gonna need it )仅仅是一条推论而已。

当然,区分的标准是什么?It depends. 但是最重要的参照是,怎么做你能获得最大产出?也许你会在所谓的扩展性、适应需求变化与可工作的代码,用户的需求之间抉择。 最重要的还是可工作的代码,能够按时 ship the beta!

记住,先列出来要干什么;然后分清先后顺序,然后淘汰那些可以不干的。

第三条规则,KISS。 Keep It Simple Stupid。
用郭靖和杨过来比喻,代码要像郭靖一样用最简单直接的方式强壮地工作,不需要太多的波折。你的程序要是像杨过的人生那么复杂、聪明,早死翘翘了。 你的程序要简单强壮地干活,思想越简单越好,功能和特性越少越好。

这一条对于设计是至关重要的,浮躁的程序员们经常要在架构设计中引入模式、分层,又或者是绚丽的Ajax效果之类,完全是无知下的自虐。我也是好些年后才明白这条道理,直到后来开始使用Unix下的那些让无数人着迷的工具,才真真地看到了这条规则的巨大威力。

要特别澄清一下,KISS 与你的程序是否好用,是否易于复用,不但不矛盾,而且是相辅相成的。你要知道的只是你的程序应该做什么,然后努力做好。借用《Programming Pearls》开篇里法国作家兼飞机设计师的话:“设计者确定其设计已经达到了完美的标准不是不能再增加任何东西,而是不能再减少任何东西”。又如Chuck Yeager将军(第一个超音速飞行的人)赞扬一架飞机的机械系统时的用词是“结构简单、部件很少、易于维护、非常坚固”。

第四条规则,一键集成和适当的自动化测试。

这条不多说了,在有条件的情况下做会受益非浅。

其他还有一些很有名的原则,例如 DRY (Don’t Repeat Yourself), 也许是因为一开始我就懂得了这个道理(尤记得大学的时候把ASP代码提取函数,封装Head和Foot,将写HTML Table的封装成方法来根据不同的数据集打印,好傻。),感触没那么深。

六年了,好快。

(Update 2009-12-23)
第五条: 一定需要且只需要数页简单明了的设计说明书。

这个设计说明最好不用word,最好是放在源代码下的html或者txt格式。简单粗线条的UML最适宜用在这种地方。当然设计文档也可以放在别的地方。

P.S.
用原则这个词,是为了强调重要性。遣词或有问题,慎自斟酌之。

Reliability, Availability, and Scalability

September 30th, 2009 西坪 No comments

Reliability, according the Wikipedia:

In general, reliability (systemic def.) is the ability of a person or system to perform and maintain its functions in routine circumstances, as well as hostile or unexpected circumstances.

The IEEE defines it as “. . . the ability of a system or component to perform its required functions under stated conditions for a specified period of time.”

On the page, it also tells:

Reliability may refer to:
Data reliability, a property of some disk arrays in computer storage

Availability, according to Wikipedia:

In telecommunications and reliability theory, the term availability has the following meanings:

1. The degree to which a system, subsystem, or equipment is operable and in a committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random, time. Simply put, availability is the proportion of time a system is in a functioning condition.

Note 1: The conditions determining operability and committability must be specified.

Note 2: Expressed mathematically, availability is 1 minus the unavailability.

2. The ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval.

Note 1: An example of availability is 100/168 if the unit is capable of being used for 100 hours in a week.

Note 2: Typical availability objectives are specified either in decimal fractions, such as 0.9998, or sometimes in a logarithmic unit called nines, which corresponds roughly to a number of nines following the decimal point, such as “five nines” for 0.99999 reliability.

There is another page about High Avaliability on Wikipedia:

High availability is a system design protocol and associated implementation that ensures a certain degree of operational continuity during a given measurement period.

Users want their systems, for example wrist watches, hospitals, airplanes or computers, to be ready to serve them at all times. Availability refers to the ability of the user community to access the system, whether to submit new work, update or alter existing work, or collect the results of previous work. If a user cannot access the system, it is said to be unavailable. Generally, the term downtime is used to refer to periods when a system is unavailable.

Scalability, according to Wikipedia:

In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged.

Methods of adding more resources for a particular application fall into two broad categories: Scale Up (Vertically) and Scale Out (Horizontally). Scale Out could be the better choices in many larger situations.

References:

  1. System Reliability and Availability
  2. Reliability and Availability Basics
Categories: $Architecture & design Tags:

面向对象的几个原则

June 24th, 2009 西坪 No comments

来源:http://snowolf.javaeye.com/blog/403184

  1. “开-闭”原则(Open-Closed Principle,或者OCP):Software entities should be open for extension,but closed for modification.
  2. 里氏代换原则(Liskov Subsitution Principle,或者LSP)    任何基类出现的地方,子类一定可以出现。
  3. 依赖倒转原则(Dependency Inversion Principle,或者DIP)    要依赖于抽象,不要依赖于实现。
  4. 接口隔离原则(Interface Segregation Principle,或者ISP)    应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口。
  5. 组合/聚合复用原则(Composition/Aggregation Principle,或者CARP)    要尽量使用合成/聚合,而不是继承关系达到复用的目的。
  6. 迪米特法则(Law of Demeter,或者LoD)    一个软件实体应当与尽可能少的其他实体发生相互作用。
  7. 单一职责原则(Single Responsibility Principle,或者SRP)  要使每一个软件实体只负责一种职责的实现。
Categories: $Architecture & design Tags: