Software Engineering Management — Collaborative Engineering To Get The Collaboration Process More Fun and Engaging

Background

Whatever the name, be it a Pull Request, Merge Request, or Code Review. There are rules and SOPs that all teams must follow. Not only to make the development process smoother but to maintain code quality too.

To support and ensure that the Code Review process is carried out as well and as simply as possible (streamlined process), standardization is needed starting from branch naming, and the push commits process until updates can finally be merged and deployed to the server (staging or production).

Branch Naming

The branch name must include the issue/task ID at the front. So a branch can represent what issue/task the developer/engineer is working on.

example: ATOP-12-fix-issue-with-disbursement or MG-43-method-to-capture-create-request

Branch(es) included in Merge/Pull Request may not be reused to continue work or fix bugs on the staging/production server.

Handling Bug Card

Handling the bug card is by “creating a new branch” from the develop branch. If necessary, developers can compare (compare) the new branch with the old branch which is suspected to have a bug or is affected by the merge process (regression).

Branches for bug fixes must also include a bug card ID in the task management tool.

Commit Message

The commit messages used by the team would be better if the team adapts Conventional Commits 1.0.0, where a commit message will have a structure like the one below.

<type>[optional scope]: <description>

[optional body]
[optional footer(s)]

Type

Must be one of the following:

• build: Changes that are affecting the build system or external dependencies.
• docs: Changes only happen in documentation (for example: updating README.md).
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

Scope (optional)

Scope is optional, it can be included when the update that occurs in the commit requires special attention to a specific technology area, for example:

• animations
• common
• compiler
• compiler-cli
• core
• elements
• forms
• http
• language-service
• platform-browser
• platform-browser-dynamic
• platform-server
• platform-webworker
• platform-webworker-dynamic
• router
• service-worker
• upgrade

Examples

1. New features without a scope, without body, and footer.

feat: API endpoints to consume create new post request.

1. Bug fix with body and no footer.

fix: can't update order after insurance is selected bug.

This bug can be reproduced when a buyer tries to process an order but
do not select an insureance.

1. Update packages used in the project with body and footer.

chore: update Golang packages.

- Gorm
- Gin
Please perform a `$ go get` before continuing with this commit.

1. A new feature with scope without body and footer.

feat(animations): adding an animation to the "add new" order form.

Code Review

Quoted from Atlassian

Code review is a very important part of the software development cycle. Code review is also one of the most difficult and time-consuming part of the software development process, often requiring experienced team members to spend time reading, thinking, evaluating, and responding to implementations of new features or systems.

Every update or change that is pushed must be reviewed first before it can be merged with the develop branch and/or main/master branch. With a good code review then:

1. The possibility of bugs occurring can be minimized,
2. Maximum quality of code and features released, and
3. The level of software performance can be increased.

On the other hand, code review is also not an easy job, because it takes a lot of time to read, think, evaluate, and provide responses to the implementation of new features or system improvements. To achieve maximum but effective and efficient results, appropriate methods are needed, and carried out with the same level of understanding by all engineers, leads, and managers. A Code Review Process is required that is good, clear, and carried out as well as possible by each team member.

The main code reviewer is an equal or more senior developer. The hierarchy is that the median reviews the code of the junior and fellow juniors, and the senior can review everything. However, all team members can also provide feedback to each other, even though in terms of experience, the coder being reviewed is more senior. Reviews from others do not always have to be accepted, but there must be a good reason for rejecting the feedback. In the end, if a dispute occurs (related to feedback), EM will act as a mediator

Pull/Merge Request (PR/MR)

Merge Request (MR) or Pull Request (PR) is carried out after the engineer has finished working on the task assigned to the engineer. So in an MR/PR, there must be:

1. Checklist of Acceptance Criteria or Definition of Done (DOD) listed in the User Story or Task.
2. Screenshot or Screencast (screen recording) of the results of manual testing carried out on localhost engineer by the engineer (minimum positive condition).
3. Important information that can affect the deployment process. Such as whether there is a config (ENV key) that must be added so that the new feature can work properly, or whether a rebuild needs to be done so that a new feature works.

The expected output is a Merge Request which has the following characteristics:

1. Small PR Request. Small in size, it only contains updates or additional features from a maximum of 1 Task or 1 User Story. The branch used to create PR is not the result of merged branches that have never been requested via PR.
2. PR Description. The description must be complete and provide detailed, descriptive information and contain all the required information as much as possible.
3. Commit Message. On-point commit messages. By the points in Commit Message above.
4. Helpful Comments PR has comments that can help direct reviewers to areas that require review or additional information about anything that could prevent an update or feature from functioning properly.
5. Visuals. The PR must include all visual information to help reviewers understand whether updates comply with the Acceptance Criteria or not. PR must have screenshots or screen records (video) that show manual testing carried out by engineers at the localhost server level.
6. Clean Code. The code that is pushed to the PR level must be clean, there is no debugging code such as “print or console.log to display raw output”. There are no longer any comments that contain sensitive information, and comments that were used to hide lines for print/debug output have all been removed.