Development practices

• Objectives
• General best practices in Code
• Estimations and Technical documents
• Demos and Checkpoints
• Definition of "Done"
• Communication
• Closure and retrospective

Objectives

At the end of the talk we should be able to:

• Identify and avoid the most common mistakes in the process of writing software
• Improve the overall quality of our codebase
• Use techniques for effectively developing software

This is a living document and should be adjusted as we need.

General best practices in Code

General best practices in Code

• Keep It Simple & Don’t Repeat Yourself:
  • "Write less code. Delete code. Don’t write code you don’t need."

General best practices in Code

• Get your code reviewed as soon as possible
  • Keep reviews scoped to people with deep understanding of that particular system

General best practices in Code

• Pair program when stuck

General best practices in Code

• Write at least minimum unit for core functionality

General best practices in Code

• Build composable classes on large systems

General best practices in Code

References and further reading:

• https://opensource.com/article/17/5/30-best-practices-software-development-and-testing
• https://by.dialexa.com/five-best-practices-for-the-ideal-software-development-project

Books: Working Effectively with Legacy Code

Estimations and Technical documents

This is a critical session and needs to be lead by a team leader!

Estimations and Technical documents

• Determine what's the problem at hand and involve the Owner for anything that is not crystal clear
  • Reject anything that has a high amount of uncertainty

• User Story must have an acceptance criteria well defined

• Develop a technical document of the required changes and high level overview of the system, if there is none
  • Must have an Owner
  • Must be versioned (use Bookstack)
  • Must be updated regularly (as the system evolves)

• Keep in mind scalability, security (authentication, authorization), fault-tolerance, and auditing

Scalability:

• Can this query run for 100x records, 1000x, 10000x
• Can I process this task in parallel or serialized? across multiple servers?

Security:

• Who can access this information?
• Access can be leaked, transfered, revoked? What are the implications?

Fault-tolerance:

• Does the system keeps working if a single subsystem fails?, ex: a worker, a cronjob
• What needs to be done to recover from errors

Auditing:

• Keep an easy to access trace of status changes, requests made, errors
• All information must be easily accessed and audited (create dates, updates, status changes)

Demos and Checkpoints

Demos and Checkpoints

• On large projects it's recommended to break it into sub-projects
  • Sub-projects can have their own deadlines and demos

Demos and Checkpoints

• It's important to show-off the overall progress of the task during "checkpoint" sessions with team members and team leaders

Demos and Checkpoints

• Develop from the top-down (visual features first, low level work later), if there are enough team members, work in parallel

Definition of "Done"

Definition of "Done"

• It follows all the requirements in the User Story.

Definition of "Done"

• It was tested by the Owner and gave written approval. See "Communication".

Definition of "Done"

• It has a technical document explaining the ins and outs of the new system.
  • High level overview of all parts of this system, toolings (scripts, crons, schedulers, monitors), entities and frontend (routes, plugins, modules).
  • See http://bookstack.afluenta.com/books/afluenta-wiki/page/asynchronous-lender-extractions

Definition of "Done"

• It has a monitor (if considered necessary), auxiliary tooling (scripts, queries, diagnostics etc) to help out in Operation.

Definition of "Done"

• It may require a technical talk and knowledge transfer session.

Definition of "Done"

• Acceptance criteria described in the User Story are tested in Dev and Beta.

Definition of "Done"

• Might have a "Nice to Have" / roadmap for further enhancement
  • To take into consideration for next sprints

Deployment

Deployment

• Build a roadmap/checklist for large deployments (with multiple parts: crons, schedulers, monitors)
  • Use iterative approach when possible

Deployment

• Take into account dependencies and the complexity of installing them on multiple servers

Deployment

• Any database migration (alter, create, etc) must be benchmarked
  • Take into account database Production size

Deployment

• Take into account production credentials setup
  • Take time to test sub-systems in isolation

Closure and retrospective

Closure and retrospective

• Write down all missing pieces
  • Errors in deployment
    • Missing/wrong configs
    • Issues with processes, permissions and crons

Closure and retrospective

• Determine steps to take in order not to make the same mistakes next time

Closure and retrospective

• Party!