What I learned in OOSE

OOSE (Object Oriented Software Engineering) is about writing beautiful code.

Beautiful code is code that separates concerns and is can be easily changed without disturbing most of the code base.

At the beginning of the course we were given a small, very unstructured codebase that was filled with bugs. Over the course of the semester, we analyzed the code and made changes to it to move it towards being correct and well designed.

The first concepts we learned in OOSE were Code Qualities. Code Qualities are attriutes of a given codebase. Code Qualities can be quantitative or qualitative, and can be Internal (visible to development team) or external (visible to the end users). Here are a few examples of Code Qualities:

  • Scalability

  • Maintainability

  • Testability

  • Usability

  • Performance

  • Readability

Code qualities give ways to talk about the current state of the codebase, and any future updates or changes. When developers make changes to the codebase it can improve code qualities in one area. Improving code qualities in one area often hurts code qualities in another area. Be sure to think about how your changes affect the codebase and if they are in line with the overall goals of your system.

After discussing code qualities we needed to build a common language for discussing how and why parts of the code were not optimal. We learned about a type of anti-pattern called Code Smells. Code Smells are parts of the code base that feel wrong and are most likely indicative of an underlying problem with the code. Code smells are un-ideal ways of solving a problem. Here are a few examples of code smells:

  • Lazy Classes

  • Data Classes

  • Switch Statements

  • Message Chain

  • Magic Numbers

After studying Code Smells, we looked at how to fix them using Refactoring. Refactoring is a technique which improves the internal design of the code without affecting what it does. This could mean extracting some logic out to a different function, creating new classes to handle some work in a bloated class, or changing naming conventions and moving hard coded data out to variables.

Next we learned about design patterns. Design patterns are ways to implement your code from the beginning to be clean and well structured. Design Patterns are discovered and not invented. They emerge as a common solution to a recurring problem. If you have an existing codebase it is possible to move your code towards these design patterns using the power of refactoring.

A few design patterns are listed below:

  • Wrapper

  • Factory

  • Decorator

  • Facade

  • Strategy

Design Patterns are where we ultimately wanted to guide our codebase. The assignments during the course were Refactors to the code that brought the codebase in line with several design patterns. Bugs were discovered and fixed once the code was well structured and the overall function of the codebase was much more sound.

The main takeaway from the class was that buggy and messy code can be shaped over several refactors toward well structured design patterns. These design patterns generally separate the concerns of the code across several files, classes, and functions that make the code easier to understand and easier to change with minimal impact to other code.

How this will help me as a software Engineer:

  • I. understand that combining all your code into a single file or trying to consolidate everything into one function is not a sign you are some genius coder.

  • separating concerns into multiple files, functions, classes, or modules is very ideal because changes that need to be made in the future will only impact small parts of the codebase.

  • I can identify code smells in our codebase and explain what it is and why it is bothering me

  • I can find a Pattern that cleanly does what the code smell is trying to do

  • I can refactor the code, removing the code smells, and move towards good Patterns

  • I now understand very important concepts like code qualities, separation of concerns, code smells, refactoring, and design patterns. These concepts are very crucial to discussing and improving code, and communicating effectively to other engineers

Previous
Previous

What I learned in Software Architecture

Next
Next

What I learned in Req. Engineering