Software development philosophies v1

40
Philosophy A theory or attitude that acts as a guiding principle for behaviour Praveen Nair, PMP MVP blog.ninethsense.com

description

Software Development Philosophies slides prepared for a training.

Transcript of Software development philosophies v1

Page 1: Software development philosophies v1

Philosophy

A theory or attitude

that acts as a guiding principle

for behaviour

Praveen Nair, PMP MVP

blog.ninethsense.com

Page 2: Software development philosophies v1

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-Martin Fowler, 2008

Page 3: Software development philosophies v1

Abstraction Principle

“Each significant piece of functionality in a program should be implemented in just one place in the source

code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them

into one by abstracting out the varying parts”

Page 4: Software development philosophies v1

DRY – Don’t repeat yourself

Every piece of knowledge must have a

single, unambiguous, authoritative representation

within a system.

Page 5: Software development philosophies v1

SSOT – Single Source of Truth

refers to the practice of structuring information models and associated schemata such that every data element is

stored exactly once

Page 6: Software development philosophies v1

Code Smells

any symptom in the source code of a program that possibly indicates a deeper problem

Page 7: Software development philosophies v1

Refactoring

process of restructuring existing computer code

without changing its external behavior

Page 8: Software development philosophies v1

S O L I DGuidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible.

1. Single Responsibility

2. Open-Closed

3. Liskov Substitution

4. Interface Segregation

5. Dependency Inversion

Page 9: Software development philosophies v1

Single Responsibility Principle

every context (class, function, variable, etc.) should have a single responsibility

Page 10: Software development philosophies v1

LSP – Liskov Substitution Principle

objects in a program should be replaceable with instances of their subtypes without altering the

correctness of that program

Page 11: Software development philosophies v1

Interface Segregation Principle

no client should be forced to

depend on methods it does not use

Page 12: Software development philosophies v1

Dependency Inversion Principle

Decouple software modules

• High-level modules should not depend on low-level modules.

• Abstractions should not depend on details. Details should depend on abstractions.

Page 13: Software development philosophies v1

Database Normalization

process of organizing the fields and tables of a relational database to minimize redundancy

Page 14: Software development philosophies v1

KISS – Keep it simple, stupid!

most systems work best if they are kept simple rather than made complicated

Page 15: Software development philosophies v1

YAGNI – You ain’t gonna need it

Always implement things when you actually need them, never when you just foresee that you need them

Page 16: Software development philosophies v1

Code bloat

production of code that is perceived as unnecessarily long, slow, or otherwise wasteful of resources

Page 17: Software development philosophies v1

MoSCoW

MUST

SHOULD

COULD

WON’T

Page 18: Software development philosophies v1

Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Page 19: Software development philosophies v1

Agile Manifesto

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Page 20: Software development philosophies v1

Agile Manifesto

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

Page 21: Software development philosophies v1

Agile Manifesto

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Page 22: Software development philosophies v1

Self-organizing team

A group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands

Page 23: Software development philosophies v1

CI - Continuous Integration

Practice of merging all developer working copies with a shared mainline several times a day. Its main aim is to

prevent integration problems (i.e., integration hell)

Page 24: Software development philosophies v1

RAD

Rapid Application Development

Page 25: Software development philosophies v1

UML - Unified Modeling Language

a general-purpose modeling language which is designed to provide a standard way to visualize the

design of a system

Page 26: Software development philosophies v1

UML - Unified Modeling Language

a general-purpose modeling language which is designed to provide a standard way to visualize the

design of a system

Page 27: Software development philosophies v1

TDD – Test Driven Development

first write automated test code

next write some code to pass that test

Page 28: Software development philosophies v1

80:20 rule

20 percent of the code has 80 percent of the errors.

Find them, fix them!

Page 29: Software development philosophies v1

if it ain’t broke, don’t fix it

Leave something alone;

avoid attempting to correct, fix, or improve

what is already sufficient.

Page 30: Software development philosophies v1

if it ain’t broke, don’t fix it

Leave something alone;

avoid attempting to correct, fix, or improve

what is already sufficient.

Page 31: Software development philosophies v1

Code Reuse

Code reuse, also called software reuse, is the use of existing software, or software knowledge,

to build new software

Page 32: Software development philosophies v1

Design Patterns

a general reusable solution to a

commonly occurring problem

Page 33: Software development philosophies v1

Anti Patterns

specific repeated practices that appear initially to be beneficial, but ultimately result in bad consequences

that outweigh the hoped-for advantages

Page 34: Software development philosophies v1

Architectural Patterns

a widely recognized and reused solution

to a recurring design problem

Page 35: Software development philosophies v1

Quality attributes

Design Qualities

1. Conceptual Integrity

2. Maintainability

3. Reusability

Page 36: Software development philosophies v1

Quality attributes

Run-time Qualities

1. Availability

2. Interoperability

3. Manageability

4. Performance

5. Reliability

6. Scalability

7. Security

Page 37: Software development philosophies v1

Quality attributes

System Qualities

1. Supportability

2. Testability

User Qualities

1. Usability

Page 38: Software development philosophies v1

Software Documentation

1. Requirements

2. Architecture / Design

3. Technical

4. End User

5. Marketing

Page 39: Software development philosophies v1

Project Triangle

Scope

Cost Time

Page 40: Software development philosophies v1

Separation of Concerns

a design principle for separating a computer program into distinct sections