Craftsmanship

It was a busy month, all work no play... more about polishing, both code and UI, to make a better product.

1. Code Polishing

In the current Java Spring project, there are a few things worth mentioning.

1. Service layer for MVC.

My previous projects are mostly architected under MVC pattern. There is nothing wrong about that. However, when the logic gets more complexed, handling all the logic in the controller layer would not be as clean and efficient. Another layer named Service for better data access and logic control is used in the our project. http://stackoverflow.com/questions/5702391/mvcs-model-view-controller-service

The controller would not be handling too many logics, instead, it only handles routing and  parameter passing. Most logics will be handled in the service layer.

2. Exception handling vs error codes

In the beginning, I didn’t do any exception handling in the service layer, neither do I create many exception handlers in the controller layer.After reviewing my peers codes, I realize that it is more elegant to throw exception than returning error code. http://stackoverflow.com/questions/253314/exceptions-or-error-codes

In the project, we used exception handling in the service layer to return exceptions which are inherited from IOException. I found the logic clearer after shifting to the exception handling idea in my codes.

3. Bad thing about lazy fetch type

In hibernate, it specifies the lazy fetch type, which is intended to reduce database memory access for relationships such as @OneToOne, @OneToMany,  @ManyToMany ,etc.

In the following blog post, the author stated some good explanations about the difference of each fetch type. http://howtoprogramwithjava.com/hibernate-eager-vs-lazy-fetch-type/

“FetchType.LAZY = Doesn’t load the relationships unless explicitly “asked for” via getter

FetchType.EAGER = Loads ALL relationships”

However, lazy can be very troublesome in some circumstances. I had a lot of null pointer exceptions when trying to get lazy type relationship entities. I've got to manually parse these relationship entities into Map before sending them to the view, which makes the code very dirty.

For instance, in the following code, I want to get all users and their associated roles. Simply get the user list array won't return the roles because of the lazy issue. But I still need to display the associated role information in the view. I've got to use the ugly way to parse the role list into strings before sending to the view. If you know any better approaches, please let me know. Thanks!

    public List<Map<String,String>> getUserList(){


        List<Map<String,String>> userList = new ArrayList<>();





        List<DashboardUser> allDashboardUsers = Lists.newArrayList(userDao.findAll());


        for (DashboardUser dashboardUser : allDashboardUsers) {


            Map<String, String> aMap = new HashMap<>();


            aMap.put("id",dashboardUser.getId().toString());


            aMap.put("email",dashboardUser.getEmail());


            aMap.put("username",dashboardUser.getUserName());


            String roles ="";


            for(Role role:dashboardUser.getRoles()){


                roles+="/"+role.getName();


            }


            aMap.put("roles",roles);


            userList.add(aMap);


        }


        return userList;


    }

2. UI polishing

Switch to angular.js.

Previously, the project is developed under jQuery. The views are not structurally organised, until it becomes quite a messy.The team decided to use angular because it’s clean and structured. After one week's polishing, the codes become much more beautiful, both in the front end and the backend.

I may write another blog about angular when the project gets more polished.

3. Project management

1. We tried to explore the scrum 
meeting(http://en.wikipedia.org/wiki/Scrum_(software_development)) inside the small team. It works quite good. The basic scrum workflow consists of sprint planning, daily scrum meeting and end review meeting.  

The daily scrum meeting is not hard to follow. We started the meeting at 9:45am for <=15 minutes everyday at the same location asking the following questions:

“1. The basic What have you done since yesterday?
2. What are you planning to do today?
3. Any impediments/stumbling blocks? “

The tasks will be noted down by the scrum master and posted on a public wall. It makes every one involved and aware of the progress.

2. Github feature branch

Previously, we develop the features under our own develop branches and make pull requests to the origin develop branch when a new feature was added. However, that’s not a good design. The new feature commits are mixed with the develop branch and you can hardly distinguish which features are added by whom in a structural manner.

Thanks Peng jun and Xu Fan for sharing this. 

http://nvie.com/posts/a-successful-git-branching-model/

http://danielkummer.github.io/git-flow-cheatsheet/

Another tip for using github is to use git stash for saving unfinished changes in the current branch before switching to another local branch.