As a software developer version control you will undoubtedly run into version control of any projects which you are working on. Eventually a developer will have to fix bugs or add a feature to a product. In order to learn more about version control there is no better website to learn from than Github.

What is Version Control?

Github gives an amazing allegory: Imagine you’re a violinist in a 100-piece orchestra, but you and the other musicians can’t see the conductor or hear one another. Instead of synchronized instruments playing music, the result is just noise.

Version control is a tool used to prevent this noise from happening. It helps streamline development, keep track of any changes, and allow for upscaling of projects.

Version Control tool factors

Version control may not be necessary depending on the scale of your project, however most of the time it is useful to have it set up. Some of the factors of deciding to use version control include:

• Scalability: Large projects with many developers and files benefit from VC
• Ease of Use: User friendly UI helps manage learning curves and adoption.
• Collaboration features: Supporting multiple contributors and communication between them.
• Integration with existing tools: Using tools everyone already has access to.
• Supports branching: Ability for developers to work on different parts of development benefits a project greatly.

Common Version Control pplications

• Git: Git is an open-source distributed version control tool preferred by developers for its speed, flexibility, and because contributors can work on the same codebase simultaneously.
• Subversion (SVN): Subversion is a centralized version control tool used by enterprise teams and is known for its speed and scalability.
• Azure DevOps Server: Previously known as Microsoft Team Foundation Server (TFS), Azure DevOps Server is a set of modern development services, a centralized version control, and reporting system hosted on-premises.
• Mercurial: Like Git in scalability and flexibility, Mercurial is a distributed version control system.
• Perforce: Used in large-scale software development projects, Perforce is a centralized version control system valued for its simplicity and ease of use.

Final thoughts

Every developer has at one point heard of Git, and without a doubt it may be one of the best developer tool ever invented. I have prior experience using version control but this research was an important refresher to learn from. If you wish to learn directly from Github you can read the article this blog was inspired by here.

From the blog CS@Worcester – Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Sometimes when a program undergoes consistent updates it can get messy, in cases like this it can be useful to refactor it. I’ve had a few experienced cleaning a program however I have never refactored an entire program. The developers over at refactoring guru luckily have a website dedicated to this subject.

Purpose for refactoring

When you refactor a program you are fighting something they call technical debt and create clean code. With clean code comes a few benefits including:

• Obvious for other programmers
• Doesn’t contain duplicate code
• Minimal number of classes and other moving parts
• Passing of all tests
• Easier and cheaper to maintain

What is technical debt?

“Technical debt” as a metaphor was originally suggested by Ward Cunningham using bank loans as an example.

You can make purchases faster If you get a loan from a bank however now on top of principal you have interest. and with time you can rack up so much interest that the amount of interest exceeds your total income, making full repayment impossible.

The same concept can be applied to code. Speeding up without testing new features will gradually slow your progress.

Some causes of technical debt include:

• Business pressure
• Lack of understanding the consequence
• Failing to combat the strict coherence of components
• Lack of tests, documentation, communication.
• Long-term simultaneous development in several branches
• Delayed refactoring
• Incompetence

So when should one refactor?

Refactoring guru comes up with a few instances on when to refactor.

• Rule of three:
  • When doing something for the first time, just get it done.
  • When doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
  • When doing something for the third time, start refactoring.
• Adding a feature:
  • If you have to deal with someone else’s dirty code, try refactoring it first; Easier for future features.
• Fixing a bug:
  • Clean the code and errors will discover themselves
• Code reviews:
  • Last chance to tidy up the code
  • Best to perform these reviews in pair with an author

We know when, but how?

Refactoring is done via a series of small changes, each making the existing code slightly better while leaving the program in working order.

Here is a checklist on refactoring done the right way:

• The code is cleaner
• There should not be new functionality
• All existing tests pass

Final Thoughts:

Overall, I found this website on refactoring to be really informative and would recommend refactoring guru as a starting point. The most important thing that I got out of this is that developers should always try to write clean code or clean code as its undergoing development. Unfortunately sometimes software development can be very time containing and its not always possible which is why refactoring is important.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Hello everyone, today I will be talking about the Principle of Least Knowledge (AKA Law of Demeter). When first looking into this topic I was unsure of exactly what this was and how it would be applied to programming. When doing my research I found the Khouri College of Computer Sciences at North Eastern University had a page dedicated to this topic, where this law was first introduced.

General Formulation

The LoD is essentially a simple style rule for designing object oriented systems.

“Only talk to your immediate friends” is the motto. 

Professor Leiberherr, the author, states a formulation of “Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.” Its main motivation is to control information overload thus helping memory management as each item is closely related.

You can informally summarize the Law with these three formulations:

• Each method can only send messages to a limited set of objects, namely to the argument objects and to the immediate subparts of the class to which the method is attached.
• Each method is “dependent” on a limited set of objects (organize dependencies)
• Each method “collaborates” with a limited set of objects (organize collaborations)

To formulate the Law we can choose from the following independent possibilities:

• Object/Class
  • Class formulation is intended to be compile-time
  • Object formulation is intended to be followed conceptually
• Messages/Generic functions/Methods
• Weak/Strong
  • If we interpret it as all instance variables, including the inherited ones, we get the weak form of the Law. If we exclude the inherited instance variables, we get the strong form of the Law.

Benefits

In a paper written by Leiberherr, there are a couple facts stated for the benefits:

• If the weak or strong LoD is followed and if class A’s protocol is renamed, then at most the preferred client methods of A and A’s subclasses require modification.
• If the weak or strong LoD is followed and if the protocol of class A changes, then only preferred client methods of A and its subclasses need to be modified and only methods in the set of potential preferred clients of A and its subclasses need to be added
• There’s even more benefits highlighted in the paper pertaining to limiting information overload.

Final Thoughts:

Prior to this webpage I knew nothing about this law/principle, however I now understand that it is a fairly useful rule or its respective use case. The law teaches you a way to program Classes, Inheritance, Abstraction, and a few other techniques. Infact There is so much more depth to this that I cant even fully fit it into this blog post. I would highly recommend you check out this page as It contains all the information you need along with sources to learn this.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

By Petraq Mele

Hello again to those reading this blog, this time I want to talk about an extremely topic relevant in the programming atmosphere, that being a concept known as SOLID. I managed to find a great section written by Manoj Phandis on these principles.

SOLID is an acronym of five OOP design principles designed to help make it more understandable, flexible, and maintainable.

What are the main 5 design principles?

SINGLE RESPONSIBILITY PRINCIPLE: This principle states a class should have one, and only one, reason to change. Lets take an Animal class example, as opposed to the animal class having a sound and feed parameter, separate those responsibilities into separate classes.

Some benefits include:

• more readable, that is easier to understand
• less error prone
• more robust
• better testable
• better maintainable and extendable
• maximizes the cohesion of classes.

OPEN CLOSED PRINCIPLE: “Open for extension” means the behavior of a module can be extended. “Closed for extension” means when we are adding/extending a modules behavior it should not result in changes to a modules source or binary code.

An example Manoj gives is a credit card company wanting to introduce a new preferred credit card product with double reward points. Instead of using conditionals, you create an extension via implementation inheritance or interface abstraction.

LISKOV SUBSTITUTION PRINCIPLE: LSP states functions that use references to base classes must be able to use objects of the derived class without knowing it. For LSP compliance we need to follow some rules that can be categorized into 2 groups:

• Contract rules
  • Preconditions cannot be strengthened or weakened in a subtype
  • Invariants must be maintained
• Variance rules
  • There must be contra-variance of the method argument in the subtype & be covariance of the return type in the subtype
  • No new exceptions can be thrown by the subtype unless they are part of the existing exception hierarchy.

INTERFACE SEGREGATION PRINCIPLE: Clients should not be forced to depend on methods they do not use. Interface segregation violations result in classes depending on things they don’t need & an increase of coupling and reduced flexibility/maintainability.

Tips to follow:

• Prefer small, cohesive interfaces to “fat” interfaces
• Creating smaller interfaces with just what we need
• Have the fat interface implement your new interface.
• Dependency of one class to another should depend on the smallest possible interface.

DEPENDENCY INVERSION PRINCIPLE: This principle has two parts. The first part says high-level modules should not depend on low-level modules. Both should depend on abstractions. The second part says Abstractions should not depend on details. Details should depend on abstractions.

Part one example:

Part two example:

Final thoughts:

Overall these principles are very useful when it comes to object-oriented software development. I learned quite a good amount and I want to thank Manoj Phandis for their amazing outline of the SOLID principles, I would advise you to check them out in his website incase you’re interested in learning more.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

As a software developer there is a significant chance that you will develop software in a team environment. I know as an entry level developer gaining this experience beforehand would be a massive boost for my career but what exactly does team management entail?

The importance of team management

In a perfect world a team of developers all work perfectly together synchronously & complete a task in the best way possible. In reality, each team will have people of different skillsets, creativity, and ideas for development. Therefore, teams need to be managed in order to optimize development as much as possible.

Creating a team

Before assembling a team for a project its important to highlight the scope & needs in order to figure out how many, and the type of, developers. According to itrex, some examples of developers you may need would be:

– Software Developer: Engineers and stabilizes the product & solves any technical problems emerging during the development lifecycle
– Software Architect: Designs a high-level software architecture, selects appropriate tools and platforms to implement the product vision, & sets up code quality standards and performs code reviews
– UI/UX Developer: Transforms a product vision into user-friendly designs & creates user journeys for the best user experience and highest conversion rates
– QA(quality assurance) Engineer: Makes sure an application performs according to requirements & spots functional and non-functional defects
-Test Automation Engineer: Designs a test automation ecosystem & writes and maintains test scripts for automated testing
– DevOps Engineer: Facilitates cooperation between development and operations teams & builds continuous integration and continuous delivery (CI/CD) pipelines for faster delivery
– Business Analyst: Understands customers business processes and translates business needs to requirements.
– Project Manager: Makes sure a product or its part is delivered on time and within budget & manages and motivates the software development team
– Project Owner: Holds responsibility for a product vision and evolution & makes sure the final product meets customer requirements

Post-team assembly

Depending on your project you now have an idea on what team you have, the next step is actually managing them. This entails setting clear objectives/goals, creating a timeline, allocating resources, setting communication strategies, delegating, implementing, tracking progress, monitoring project, managing risks/challenges & maintaining flexibility.

Final thoughts

I now have a better understanding the importance of team management in software development. In order to maximize efficiency towards a project/goal you definitely need to manage a significant amount of aspects related to development. The ability for a team to work together is also valuable & must be taken into account. Overall, I really enjoyed researching this topic, the main sources I used in my research was this section in Atlassians website as well as this section in the itrexgroup website.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.