Software Development Best Practices You Should Know

The third-party libraries register is published on the project space (Confluence, Wiki) and regularly maintained by the technical leader or architect.
Use of a third-party library must comply with its license agreement.
The application should not use the library directly but through the facade design pattern. This avoids tight coupling between the third-party library and the application code, so the library can be easily replaced with a newer one.
Integration tests of the application’s functionality should cover the code of a third-party library. These integration tests ensure that the new version of the library does not break the functionality of the application.
The development team should use libraries that are actively maintained.

When logging a message, the application should use the most appropriate logging level (Trace, Debug, Info, Warning, Error, etc.).
It should be possible to change the logging level through the config file without redeploying the code.
Use a structured logging technique when logging messages so that you can analyze a large number of logs by writing queries.
Even actively sending large numbers of logs to the monitoring tool should not significantly impact the performance of the application. Logging calls should be non-blocking. Additionally, they can be batched and sent in a separate thread.
The monitoring tools like Application Insights, Stackdriver, or others are used. The monitoring tool is configured to send notifications when the application exceeds any thresholds.

The code review has a higher priority than the development task to avoid long-lived pull requests.
Code review process is automated, not manual. GitHub, Crucible, Review Board, or other tools are used.
No more than 300–400 lines of code are sent to the code review. Consider splitting a big functionality into smaller tasks that developers can review separately.
The reviewer should have the ability to log the time spent on code review.
The reviewer clearly understands the acceptance criteria of the code he is reviewing.
The reviewer reviews the code against the code review checklist. The checklist should exist in the project space so that all developers can access and use it.
Each commit should be reviewed by at least one or two team members before pushing the code to the main branch.

Developers should create well-descriptive technical debt tickets in the issue tracking systems as soon as they see tech debt in the source code.
All technical debt tickets should be grouped in some way: 1) technical debt epic, 2) “technical-debt” label, or 3) naming convention for ticket titles.
The development team should prevent a tech debt from growing by including a few tech debt tickets in each sprint, or by dedicating an entire sprint (technical sprint) to dealing with tech debt.
The development team should prioritize and estimate technical debt tickets during backlog refinement sessions.
Each stakeholder needs to know how to quickly find all the tech debt tickets.

The entire development team is involved in estimations, not just the technical lead or architect.
Definition of Done (DoD) for stories is defined and published in the project space. Before doing estimations, the team must reach a consensus on the Definition of Done.
Developers use 3-Point estimation or PERT Formula to estimate the work, not just single values.
Estimates should include efforts needed to write unit tests, to pass code review and testing activities.
Analogy-based estimation, story points, planning poker, decomposition, and recomposition techniques are used during estimation.
Existing estimates should be reviewed regularly by the team during backlog grooming or sprint planning meetings and refined as needed.
All team members should be involved in the sprint planning process.
All developers should be involved in the design phase, not just senior staff.
Technical leaders do delegation of work in the form of separate tasks.
Each task should have written acceptance criteria.

The project source code and all related scripts (database scripts, build, or deployment scripts) should be stored in the version control system.
Each commit to the branch should contain a work item ID from the issue tracking system and a description.
Developers push changes to the feature branch a few times per day.
Each commit must contain functionality that is specific to the only work item.
Developers should merge pull requests to the main branch as soon as it's approved to avoid merge conflicts.
Binaries that are compiled output from source code or third-party packages should be excluded from source control by configuring the gitignore file.
Environment-specific data such as connection strings should be separated from the source code and stored in configuration files or environment variables.
The development team should define branching and merging strategies that meet the needs of the project and describe them in the project space.

The database schema and reference data (data that is required to run the application) should be stored in the source control.
The development team should choose between state-based and migration-based approaches according to the project needs.
Developers should always modify the database through database scripts in source control. If a developer has changed the database directly, he should make the same change in source control.
Each developer should have their local database, which they can easily create by running database scripts taken from the repository.

The continuous integration workflow should be documented by the technical manager or architect and shared with the team.
Running the static code analyzer tool should be included in the continuous integration pipeline and cause the build to fail when the code quality metrics are less than specified.
The continuous integration pipeline should run all unit tests and cause the build to fail if any unit test fails.
Developers should run the unit tests locally before committing the code to the repository.
Build notifications are configured. The build server automatically sends a notification about build status to all interested parties.
Build artifacts should be versioned using semantic versioning.
Each build is associated with a corresponding commit from the repository.
Rollback procedure is defined and configured for failed deployments.

The development team should regularly collect and analyze code quality metrics to identify any code issues as quickly as possible.

All team members should use the same static code analysis tool with the same configuration as the build server.