software development philosophies v1
DESCRIPTION
Software Development Philosophies slides prepared for a training.TRANSCRIPT
![Page 1: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/1.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/2.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/3.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/4.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/5.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/6.jpg)
Code Smells
any symptom in the source code of a program that possibly indicates a deeper problem
![Page 7: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/7.jpg)
Refactoring
process of restructuring existing computer code
without changing its external behavior
![Page 8: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/8.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/9.jpg)
Single Responsibility Principle
every context (class, function, variable, etc.) should have a single responsibility
![Page 10: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/10.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/11.jpg)
Interface Segregation Principle
no client should be forced to
depend on methods it does not use
![Page 12: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/12.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/13.jpg)
Database Normalization
process of organizing the fields and tables of a relational database to minimize redundancy
![Page 14: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/14.jpg)
KISS – Keep it simple, stupid!
most systems work best if they are kept simple rather than made complicated
![Page 15: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/15.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/16.jpg)
Code bloat
production of code that is perceived as unnecessarily long, slow, or otherwise wasteful of resources
![Page 17: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/17.jpg)
MoSCoW
MUST
SHOULD
COULD
WON’T
![Page 18: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/18.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/19.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/20.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/21.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/22.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/23.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/24.jpg)
RAD
Rapid Application Development
![Page 25: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/25.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/26.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/27.jpg)
TDD – Test Driven Development
first write automated test code
next write some code to pass that test
![Page 28: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/28.jpg)
80:20 rule
20 percent of the code has 80 percent of the errors.
Find them, fix them!
![Page 29: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/29.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/30.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/31.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/32.jpg)
Design Patterns
a general reusable solution to a
commonly occurring problem
![Page 33: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/33.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/34.jpg)
Architectural Patterns
a widely recognized and reused solution
to a recurring design problem
![Page 35: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/35.jpg)
Quality attributes
Design Qualities
1. Conceptual Integrity
2. Maintainability
3. Reusability
![Page 36: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/36.jpg)
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](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/37.jpg)
Quality attributes
System Qualities
1. Supportability
2. Testability
User Qualities
1. Usability
![Page 38: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/38.jpg)
Software Documentation
1. Requirements
2. Architecture / Design
3. Technical
4. End User
5. Marketing
![Page 39: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/39.jpg)
Project Triangle
Scope
Cost Time
![Page 40: Software development philosophies v1](https://reader033.vdocument.in/reader033/viewer/2022052907/55941bec1a28abf02b8b46fc/html5/thumbnails/40.jpg)
Separation of Concerns
a design principle for separating a computer program into distinct sections