This week we have one of the hottest days in Ireland in over a decade. It’s very humid and in my appartment unbearable heat; I can’t even concentrate properly on the prep work at home, so I am more often than ever chilling down in my office air con while studying. I couldn’t progress much as I planned over the past three days, not only because of the weather, but rather a complexity of the material. Believe me, if I say I am a test driven student. Now because of the lack of progress, I am putting, even more, the effort now – I want to finish my plan for this month as scheduled. I have just finished writing my first advanced pseudocode for an elevator. It took me 4 hours to finish it and almost 200 lines of pseudocode during the most creative moment. I cut it down to 99 lines in the end. As it’s just pseudocode, it’s hard to talk about a level of correctness… well its only pseudocode, but I hope to code it in Ruby one day in the future to find it out.
I started this assignment being very optimistic, but then new complications began to unveil. In the end, I started asking myself questions like “what If I call down the elevator from the 3rd floor and someone presses in near moment number 6, and all this while the elevator is on its way to number 8.” Well, I have figured out to create a trip plan for the elevator with a changeable array. This problem came to my mind after two hours as I was just pseudocoding simple situations like what happens if the lift goes to number pressed, or is called from other floors, or someone is between doors, etc.
All this is almost Object Oriented Programming, but in these lessons of Viking Code Camp, I am focusing on pseudocode and modules (one of the simplified ideas behind OOP) only. Splitting whole program into different modules would have been easier if not taking Object Oriented Principles for doing that. All of them sound great and make great sense, but as I am not advanced in coding, it’s pretty hard to grasp all the concepts. The main three of them are encapsulation (modules should not reveal their functionality), high cohesion (modules are focused on main goal) and low coupling (very low dependence between modules). There is a way to code with these principles, and it’s called SOLID guidelines presented in relatively easy way by Kaur Mätas and Viking Code Camp
- Single Responsibility Principle (SRP) — modules should only exist to serve one purpose and may only change if that purpose is modified
- Open/Closed Principle (OCP) — modules should be open for extension but closed to modification
- Liskov Substitution Principle (LSP) — modules that inherit from a parent should not alter any of that parent’s functionality
- Interface Segregation Principle (ISP) — each different user of a module should get to access it via a specialized interface that only requires them to supply the minimal amount of information.
- Dependency Inversion Principle (DIP) — Higher level modules should dictate the implementation details of lower level modules, not the other way around.
I got a few days ago also through concepts of Test & Behaviour Driven Development. I thought before that writing test first before writing code is an incredible waste of time. I read and watched many explanations on this subject; it convinced me how the even greater waste of time and stress would be to look for a bug in code during the production phase. Moreover, “When a change is made to the application, all that must be done is run the existing test cases to see if the change has adversely impacted any other piece of the application. This removes all roadblocks from updating legacy applications and making changes within the current development.” (Source http://www.base36.com/2012/07/benefits-of-test-driven-development/)
I have also worked with Pivotal Tracker to prepare a different assignment earlier on. I was trying to be Scrum team, Scrum Master and Product Owner in one person. However, it shows real complexity and importance of teamwork as user stories and whole effort done in short sprints is complex enough for one person.