Software development philosophies v1
-
Upload
praveen-nair -
Category
Software
-
view
199 -
download
0
description
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