Skip to content
MichaelKohler edited this page Nov 14, 2012 · 18 revisions

We were asked to review the project of ese2012-team5 according to the guidlines provided here.

Main use cases

UML Use Case diagram:

UML

Code review

According to criteria found here.

Design

Violation of MVC layers

Controller responsible for deleting user and user's item images (delete_account)?!

Usage of helper objects between view and model

Not given - direct access to model attributes. Helper objects used for functionality that doesn't clearly belong to either model or controllers.

Rich OO domain model

Limited to User, Item and Database "Master" object (singleton).

Clear responsibilities

Is Database as such really necessary? It might be easier and more intuitive to just store items and users in arrays in Item and User.

Why not call the validator CredentialsValidator as that's all it can do?

Sound invariants

No consistent invariant checking seems to be used.

Overall code organization & reuse, e.g. views

Unused handler get '/buy' do

Coding style

Consistency

Intention-revealing names

What does categories_items do? Why not use a verb in the name? Why not have an object for stuff related to categories?

# categories all ACTIVE items by their name
# @return [Array of Arrays] array with arrays for every different item.name
def categories_items

Ruby idioms

Not always used, e.g.

  if password != password_conf
    return "error ~ password and confirmation don't match. "
  end
  if password.length<length
    return "error ~ password too short. "
  end
  if !(password =~ /[0-9]/)
    return "error ~ no number in password. "
  end

cloud be written with return ... if/unless ...

Do not repeat yourself

Why always copy params[] to local variables?

password = params[:password]
password_conf = params[:password_conf]
hash = params[:hash]

This calls for a helper method:

begin
  !(Integer(price))
rescue ArgumentError
  session[:message] = "error ~ Price was not a number!"
  redirect '/createItem'
end

begin
  !(Integer(quantity))
rescue ArgumentError
  session[:message] = "error ~ Quantity was not a number!"
  redirect '/createItem'
end

Exception, testing null values

Not used (at least not with exceptions).

Encapsulation

Not used, would be possible by using custom accessors/setters, even in ruby.

Assertion, contracts, invariant checks

raise and fail never used...

Utility methods

Used rarely, controllers would benefit from this.

Documentation

Documentation is generally good, comments are short, but informative. Really short methods where the name already gives away the purpose don't have comments, but sometimes comments are missing from methods complex enough to "deserve" and own comment. Most comments also use @param and @return semantics.

Understandable

Some comments are not very descriptive, e.g: # append image at the end

The item.split(at) method does not do what is described in the comment, the newly created item actually has the quantity at instead of rest and vice versa for the current item. For the current stage of the project this doesn't really make a difference though.

Intention-revealing

Why is this method necessary?

# move image to position 0 (profile)
# @param [Integer] position
def move_image_to_front (nr)

Describe responsibilities

Class comments are missing.

Match a consistent domain vocabulary

"Remove" or "delete"?

# removes this item from the item list
def delete_item(item)

Test

Clear and distinct test cases

Most test functions have clear names, it is evident what they do/test, the use cases in store_simulation_test are transparent.

Number/coverage of test cases

Database's test coverage is below 50%. user_test sets up instances of database.rb for every test without using it (since it is not needed for creating/manipulating/deleting users).

Easy to understand the case that is tested

Well crafted set of test data

There are unfinished tests in database_test.

Readability