Scribd
Upload
23 views4 pages

Study Guide

The document summarizes several software development principles and practices including: - The Open-Closed Principle which states that software should be open for extension but closed for modification. Examples given are how plugins extend applications without changing source code. - The Single Responsibility Principle which says every module should have a single responsibility and that responsibility should be encapsulated in the class. - Dependency Inversion which states high level modules shouldn't depend on low level modules and both should depend on abstractions. - Agile "Scrum" development including daily standups to discuss work and artifacts like task boards and burn down charts. - Continuous Integration using services like Travis CI to automatically build, test,

Uploaded by

dk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
23 views4 pages

Study Guide

The document summarizes several software development principles and practices including: - The Open-Closed Principle which states that software should be open for extension but closed for modification. Examples given are how plugins extend applications without changing source code. - The Single Responsibility Principle which says every module should have a single responsibility and that responsibility should be encapsulated in the class. - Dependency Inversion which states high level modules shouldn't depend on low level modules and both should depend on abstractions. - Agile "Scrum" development including daily standups to discuss work and artifacts like task boards and burn down charts. - Continuous Integration using services like Travis CI to automatically build, test,

Uploaded by

dk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Open Close Principal: Software, classes, modules, and functions should be open for extension

and closed for modification.

Example: Eclipse, chrome, visual studio, game mods, all follow open close principal.
They are easily extended with plugins without modifying the source code.

Single Responsibility Principle: Every module or class should have responsibility over a single
part
of the functionality provided by the software, and that responsibility should be entirely
encapsulated
by the class.

Dependency Inversion Principle:


- OO concept. We start with a high-level problem and break it up into smaller parts.
- continue breaking into smaller and smaller parts
- The high level design is therefore described by the terms of these smaller parts.
- Therefore it directly depends on those smaller, more detailed parts.

Abstractions should not depend on details


-Abstractions: Vehicles, users
-Details: {cars, mustangs}, {students, professors, criminals}

Code should depend on things that are at the same or higher level of abstractions
-Cars and mustangs can depend on vehicles
-Students, professors, criminals can depend on users.

Agile "Scrum" Development:


-The Standups
-Talk about?
-what you did
-what you are going to do
-any blocks/impediments

-What Artifacts?
-Task Board
-Burn-down chart
-Code view
Continuous Integration:

Check in changes to github (Commit, Push) -> Fetch Changes (Travis CI) -> Build -> Test ->
Fail/Succeed

-> Notify team of success of failure.

Design Patterns:

*Structural(Patterns for composing classes and objects so that new functionality is added
in scalabe ways)
-Facade: Provide a single, high-level interface to complex subsystem.
-Decorator: Allow users to add sub-features, state or behavior to a feature
-Adapter: Wraps new code around old or imported code so that it can be used in
a new system.

*Creational (Patterns for flexible ways of instantiating classes)


-Abstract Factory: For creating different groups of related objects without creating
separate classes for each.

-Object pool: Manages "Object caching" so that instead of creating and


destroying objects, they are reused. EG: New "enemy" avatars that keep
showing up while dispatching others.

-Builder: Separate the code that reads a specification from the code that builds
the object based on the specification.

-Singleton: When you need only one instance of an object.

*Behavioral (Patterns for helping objects "Communicate" with each other):


-Observer: Pattern often used decouple a GUI from poorly understood underlying
buisness logic and storage. (GUI UPGRADES ON EXISTING APPLICATIONS)
-Strategy: Pattern for easier adherence to open close principle and
"Programming to an interface."
(When expecting to release better performing implementations of an
algorithm.

-Iterator: Pattern for applying different functions to different data structures


without havint to know details of each: EG: Searching or sorting sets of
photos and sets of songs.

Lean Start Up:


-Embraces "failing fast" (If you are wrong, you want to know fast)
-Brings market and feature into the engineering process.
-Claims to validate what you learn about the product and business by making the test
pieces small enough.

GIT STORAGE MODEL:

-Working Directory: Where code im currently writing resides, even after I save it.

-Staging Area: Where I put the code just before I commit. This allows for
commiting only some files in your working directory to a repository.

-Local Repository: Where the code is stored that I commit. For code that I have tested
and otherwise believe should be saved for continued use and possible sharing.

-Shared/Remote Repository: Where the code is stored that I commited and pushed. For
code that I have tested and otherwise believe should be saved and integrated with the
teams code.
Travis.YML

language: python

python:
-"2.7"

script:
-python helloworld.py
-python hellobrian.py
-python hellocharles.py

You might also like