One aspect of creating software solutions is much like working in a Google Doc with five authors. Imagine one writer deciding the text must be bolded. Another writer decides all text must be italicized. And yet a third author says the text must be written in .
If you were to write a story, it might take a while to complete the story, let alone tell the story in a way that the audience would understand.
This is something engineers deal with as they write code as part of a solution. There are two areas of managing coding - trunk and pull requests - that we've used at Kingland.
Trunk vs Pull Requests
Trunk-based development allows developers to collaborate on code in the same version of that code. Imagine having a giant line of code that everyone is working on, much like the earlier Google Doc example. If engineer number 41 makes a change to her code, engineer number 17 will know about it immediately. Even though developers can move through code quickly, they can trip over each other and disrupt the development process since there is a constant churn of changes. This opens the door for errors due to the complexity of working on the same version of code at the same time. It also decreases the number of people who can work on a component, as that complexity increases with the number of developers assigned to a component. Increased complexity increases cost, and increases time to develop features. You can combat this by having small teams assigned to individual components, but this doesn’t scale down well to smaller team sizes that most departments need to use.
Pull request let you tell others about changes you've pushed to a repository and work in conjunction with what are called feature branches. Using a tree analogy, think of the trunk as the whole solution. Imagine the branches as different features, many of which are being worked on at once. One or more of these branches may be a feature that isn't ready. If, when working on features, the timeline moves sooner and we need to update the solution the pull trunk can pull all of the completed branches in and ensure everything runs as expected. Using pull request, we can respond in a more agile fashion to requests from customers, pushing some features when they're ready and holding off on others.
At Kingland, to help us manage code and ensure we're working from a standard process,
Coding with Precision
While coding, engineering is always concerned about speed and quality. Our use of Codacy allows us to analyze our effort automatically. When an engineer commits code, a series of rules and checks are performed against best practices to ensure the code meets our standards and a notification is sent to the developer. Within minutes of committing code, the developer gets feedback on what needs to be fixed.
Peer reviewers can focus on understanding if we're building the right functionality into Kingland solutions or see that the code meets design requirements.
If we reference our Russian writer from the Google Doc example, he would get an error notification, alerting him that he needs to write in English.
Developers get consistent, objective feedback almost instantaneously. We reduce the number of quality issues. Clients are able to receive solutions in less time.
With all the changes, updates, reviews and edits that occur while working on software solutions, Codacy helps us efficiently manage and maintain several different versions of our software - for many clients.
-1.png)
1401 6th Ave South, Clear Lake, IA 50428
1-641-355-1000
No Comments Yet
Let us know what you think