Software development philosophies v1

Post on 01-Jul-2015

200 views 0 download

description

Software Development Philosophies slides prepared for a training.

Transcript of Software development philosophies v1

Philosophy

A theory or attitude

that acts as a guiding principle

for behaviour

Praveen Nair, PMP MVP

blog.ninethsense.com

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

-Martin Fowler, 2008

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”

DRY – Don’t repeat yourself

Every piece of knowledge must have a

single, unambiguous, authoritative representation

within a system.

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

Code Smells

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

Refactoring

process of restructuring existing computer code

without changing its external behavior

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

Single Responsibility Principle

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

LSP – Liskov Substitution Principle

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

correctness of that program

Interface Segregation Principle

no client should be forced to

depend on methods it does not use

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.

Database Normalization

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

KISS – Keep it simple, stupid!

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

YAGNI – You ain’t gonna need it

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

Code bloat

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

MoSCoW

MUST

SHOULD

COULD

WON’T

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.

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.

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.

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.

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

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)

RAD

Rapid Application Development

UML - Unified Modeling Language

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

design of a system

UML - Unified Modeling Language

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

design of a system

TDD – Test Driven Development

first write automated test code

next write some code to pass that test

80:20 rule

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

Find them, fix them!

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

Leave something alone;

avoid attempting to correct, fix, or improve

what is already sufficient.

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

Leave something alone;

avoid attempting to correct, fix, or improve

what is already sufficient.

Code Reuse

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

to build new software

Design Patterns

a general reusable solution to a

commonly occurring problem

Anti Patterns

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

that outweigh the hoped-for advantages

Architectural Patterns

a widely recognized and reused solution

to a recurring design problem

Quality attributes

Design Qualities

1. Conceptual Integrity

2. Maintainability

3. Reusability

Quality attributes

Run-time Qualities

1. Availability

2. Interoperability

3. Manageability

4. Performance

5. Reliability

6. Scalability

7. Security

Quality attributes

System Qualities

1. Supportability

2. Testability

User Qualities

1. Usability

Software Documentation

1. Requirements

2. Architecture / Design

3. Technical

4. End User

5. Marketing

Project Triangle

Scope

Cost Time

Separation of Concerns

a design principle for separating a computer program into distinct sections