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:

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"

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

Communication

  • Always involve the Owner and CC all relevant team members
  • Require written approval for all tasks (in Beta) before deploying to production

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!

Fin!

Made with Slides.com