Why?
The reasons why we're created this page is to:
- Keep whole team on the same page of style (architectural and code)
- Have a place with the links to community-approved guidelines
- Have an opportunity to provide link to rule reviewed person has violated (and avoid writing an explanation)
- Make our source and software clean and readable
Basics
Use SOLID
This is our basis. Nice guide available here - https://www.baeldung.com/solid-principles
Use GRASP
You really should know at least definitions of this patterns - https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)
Use REST carefully
Read this before you start to develop API - https://www.restapitutorial.com/
Read this and try to reach at least 2 level - https://martinfowler.com/articles/richardsonMaturityModel.html
12-factor app
Reactive Systems
https://www.reactivemanifesto.org/
API and you
This tag is very useful. Read articles time to time https://martinfowler.com/tags/API%20design.html
Style guide and checkstyle
Oracle Java Coding conventions - compulsory to follow: https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
Let's make sure we use single Checkstyle configuration and IntelliJ configuration for whole team. The best I've found is Google. Please find the configuration guide below.
How to configure Idea Collapse source
Install checkstyle plugin {
File -> Settings -> Plugins -> Marketplace
Find and install CheckStyle-IDEA
Restart Idea
}
Configure checkstyle {
File -> Settings -> Other Settings -> Checkstyle
Make Google Checks active
}
[Configure IntelliJ Idea {
Download this file https://github.com/google/styleguide/blob/gh-pages/intellij-java-google-style.xml
File -> Settings -> Editor -> Code Style -> Java
Press a gear icon next to Scheme combobox and select "Import scheme" -> "IntelliJ Idea code style XML"
Provide a path to downloaded file
Make sure that Scheme combobox is set to Google scheme
}]
There are also some common-sense rules to follow:
- A lot of files inside existing projects can't pass checkstyle for now. This is ok.
- If you want to make some class checkstyle-pass - DO NOT DO ANY OTHER MODIFICATIONS in this commit.
- Again - split checkstyle-oriented changes and code modification to different commits
- New classes must pass checkstyle, except special cases (e.g. package name is given legacy and not pass checkstyle). The start date of this rule is 09 Oct 2019
Other
This article is useful - https://blog.codinghorror.com/new-programming-jargon/
SDLC
This section is for developer's part of work only.
The Guide to tickets
- Get your ticket in JIRA.Your colleague may provide it for you or you can take new ticket by yourself,
When you're in the process of choice - remember about priorities. Do not take minor ticket while there are new ticket with higher priority. Hot pies is your choice,
Press START in ticket to change ticket's state. - Make sure you understand your ticket and the job contents you should doCheck ticket's link to PRD in Confluence,
Clarify requirements if there is uncertainty,
Ask stakeholders if you have a question,
Clarify definition of done. - Make sure you know HOW will you do your ticketDiscuss API with colleagues (API first is mandatory),
Draw some UML to describe what you're going to do and attach to PRD,
Follow the rule: bigger task - better description,
It's a good idea to split big tasks into smaller. Especially if your ticket's estimation is more than 3 days. - Create a branch for your taskSelect a branch to inherit your from (ask colleagues),
Create a branch and name it using task ID [such as CD154104-1234]. - Write some code and version itSplit different code modifications to different commits. https://crealytics.com/blog/5-reasons-keeping-git-commits-small/,
Push your commits to the remote of your branch at least once per day,
Before you start new day - checkout diffs from remote parent branch and your remote (if you're not alone),
When you push to shared feature branch - make sure that tests are green and application is working before push. - Code complete? Pull Request a review!Checkout parent branch, perform some merge conflict solving if needed,
Make sure tests are green, fix otherwise,
Run IntelliJ Idea's code inspect, fix bad things,
Run checkstyle, fix warnings,
Run FindBug, fix at least criticals,
All above is for your code modifications - don't take too mach at one time,
Create a pull request. - Your pull request gained some comments? So,Clarify comments you don't understand,
Discuss comments you recognize as incorrect or bad-ROI,
Fix,
Return to Pull Request section. - Your pull request is merged? Congratulations! It's time to get another ticket.
- Do not take more than 3 tickets at a time. Inform your colleagues about all paused and wait-for-business tickets.
- Work smart, not hard.
Tests policy
This can be very useful for this section https://www.kentbeck.com/
- Private static methods should not be tested.
- If you need to test private static method - you've met design mistake. Fix it.
- According to 1,2 you don't need PowerMock.
- While we haven't Spock - use Mockito to mock, JUnit to run, Hamcrest to beautify.
- Coverage can be reached easily. The goal is maintainability, not coverage.
- If changes in code not breaking tests - your tests are bad.
- One test method - one test - one condition is a good rule.