Re-engineering Web Application Development | A paradigm shift
Re-engineering web Application Development | A paradigm shift

Re-engineering Web Application Development | A paradigm shift

Agenda

  • The Challenges and Obstacles in the traditional Development process
  • Moving to New Methodologies to improve overall Development Process
  • Feature wise Incremental Release
  • Strict Code Review Workflow

The Challenges & Obstacles – Traditional Methodologies

  1. Branching & Merging Issues in SVN
  2. Lengthy Production Release Cycle
  3. Unconventional Code Review
  4. Less Design Up Front
  5. Poor Code Quality – Post Deployment Bugs

Obstacles Developers Faced

The NEW Approach

Problem # 1: Branching & Merging Issues in SVN

Solution: New Branching Strategy with GIT workflow 

Problem # 2: Lengthy Production Release Cycle

Solution: Feature wise Release using custom agile Scrumban Method

Problem # 3: Less Design Up Front

Solution: Big Design Up Front – S.O.L.I.D Principle

Design – Should follow S.O.L.I.D principles

S – Single responsibility principle

O – Open-closed principle

L – Liskov substitution principle

I – Interface segregation principle

D – Dependency Inversion Principle

Problem # 4: Unconventional Code Review

Solution: Strict Code Review using GitLab Merge Request

  1. We believe a code review is an intrinsic part of any product development. It is used as an effective measure to increase the quality of the product delivery and make the development process more efficient.

Diagram: Workflow for One-to-One Reviews using GitLab Pull Request

2. Basic Code Review – By Developer

3. Expert Code Review – By Reviewer

4. Continuous Integration & Deployment

Problem # 5: Poor Code Quality – Post Deployment Bugs

Solution: Test Driven Development (TDD)

Moving to Test Driven Development (TDD)

  • TDD is software development techniques that involve repeatedly first writing a test case then implementing only the code necessary to pass the test.
  • TDD stand for Test Driven Development (Test Driven Design)

3 Golden Rule of TDD:

  1. You May Not Write Production Code Until You Have Written A Failing Unit (or Acceptance) Test
  2. You May Not Write More Of A Unit (or Acceptance) Test Than Is Sufficient To Fail, And Compiling Is Failing
  3. You May Not Write More Production Code Than Is Sufficient To Pass The Currently Failing Test
  1. Why Use TDD?

2. HOW MUCH LONGER DOES TDD TAKE?

Personal Experience

  • Initial Progress Will Be Slower
  • Greater Consistency
  • Less Experienced Developer Learning/Ramp-up Time
  • Long-term cost is drastically lower

Studies

  • Takes 15-30% longer
  • 45-90% fewer bugs
  • Takes 10x as long to fix a bug in later phases
  • One study with Microsoft and IBM: Study

3. TDD improves Quality & Design

4. Categories of Tests

5. Tools for TDD (Unit testing)

Regardless of the programming language

6. TDD Result

  • Higher Quality
  • Flexibility
  • Readability
  • Maintainability
  • Predictability
  • Simplicity
  • The Hard Stuff And Surprises Are Tackled Early On
  • Both Internal And External Quality Are Maintained
  • A Well-Designed Application

Overall QC Lifecycle

Copyright images

A couple of images and graphs have been taken from the internet. Those images and icons are copyright of their respective owner.

To view or add a comment, sign in

More articles by Mohammad Salahuddin

Others also viewed

Explore content categories