Usability Driven Development 4

Veröffentlicht von Jens am 29. April 2008

Usability Driven Development (UDD) ist ein Vorgehensmodell der Softwaretechnik das Usability in einen agilen Prozess einbindet.

Es soll Entwicklern ein Werkzeug an die Hand geben um Anwendungen in einem iterativen Entwicklungsprozess, auf die Anforderungen von Kunden maßzuschneidern. Dabei soll das System so schnell wie möglich in Produktion gehen und in kurzen Releasezyklen weiterentwickelt werden.

Das Vorbild hierfür ist Extreme Programming das um Elemente des User Centered Design erweitert wurde. Die Grundprinzipien des Vorgehensmodel sind das DRY und das KISS-Prinzip, die in jeder Phase konsequent verfolgt werden.

UDD wendet diese Prinzipien auf alle Aspekte eines Softwarepro jektes an, von grafischen Oberflächen, über Quellcodes und Dokumentation bis zu Verträgen mit Kunden. 

Styleguide for Rails Projects 1

Veröffentlicht von Jens am 11. April 2008

Principles

DRY - Don’t Repeat yourself.
http://www.jensjaeger.com/2008/04/das-dry-prinzip/ (german)
http://en.wikipedia.org/wiki/DRY

KISS - Keep it Simple Stupid
http://www.jensjaeger.com/2008/04/das-kiss-prinzip/ (german)
http://en.wikipedia.org/wiki/KISS_principle

General

General Ruby Styleguide
http://rubygarden.org/ruby/page/show/RubyStyleGuide

General Rails Styleguide:
http://wiki.rubyonrails.org/rails/pages/CodingStandards

Language

Everything in the source code must be written in english. Including comments, variable names and function names.

Encoding

All files must be encoded with UTF-8.

Methods

Every method should have a meaningful name.
For a procedure name use a strong verb.
Example:

Report.print

 

For a function name use a description of the return value
Example:

Report.publishing_date

 

Avoid meaningless or wishy-washy verbs.
Descripe everything the method does.
Make names of routines as long as necessary.
The average length of methods should be from 15 to 20 characters.

Variables

Every variable should have a meaningful name.
The most consideration in naming is that the name fully and accurately descripe the entity the variable represents.
The average length of a variable should be from 8 to 15 characters.
Use shorter name only for iterators in really short scopes.
Example:

reports.each do |r|
  r.print
end

 

The scope of a variable should be as short as possible.
Arrays should have a plural name.
Example:

reports = Report.find(:all)

 

Everything else should have a singular name.
Example:

report = Report.find_by_id(1)

Constants

Naming like variables.
There should be no numbers in the sourcecode. Every number should be a constant defined in environment.rb.
Example:

PAG_PAGES = 10 #items per page for pagination

Comments

Comment as much as possible.
You shouldn’t comment WHAT your code does (this would be hurt the DRY-Principle), you should comment WHY your code does something.

Stay DRY

If you are doing something more than once, extract it into a method. This is especially the case when it comes to conditional queries. So instead of writing:

@reports = Report.find(:all, :conditions => ["deleted = ", 1])

you should write a method:

class Report < AR::B
  def find_deleted
    find(:all, :conditions => ["deleted = ", 1])
  end
end

Paranthesis

Use paranthesis with “standard” method calls and no paranthesis for helper-style hash arguments. Example:

Report.find_by_id(1)
#instead of
Report.find_by_id 1

but

link_to "view", { :action => "view" }
#instead of
link_to("view", { :action => "view" })

Acknowledgments

Thanks to Florian Gilcher for the helpful comments.

Das KISS-Prinzip 5

Veröffentlicht von Jens am 09. April 2008

Das Akronym KISS steht für Keep it simple, stupid. Es besagt, dass stets die einfachste Lösung für ein Problem gewählt werden sollte. Bereits 1654 wurde vom deutschen Philosophen Johannes Clauberg die bekannte Formulierung aufgestellt, dass „Entitäten nicht über das Notwendige hinaus vermehrt werden dürfen“.

Johannes Clauberg bezog sich in seinem Buch auf wissenschaftliche Theorien. Vereinfacht ausgedrückt bedeutet die Aussage: Eine Theorie sollte möglichst einfach gestaltet sein und trotzdem alle wesentlichen Zusammenhänge erklären.

Das KISS-Prinzip verallgemeinert Claubergs Aussage und kann auf Softwaretechnik angewandt, als eine der Vorraussetzungen für agile Softwarentwicklung angesehen werden.