These notes are from some bits of paper I had laying on a drawer. I think this a summary of a summary of some college notes.

SLDC

  • Scrum VS Waterfall
  • Lean SW Development:
    • eliminate waste (problems, extra stuff, half done stuff)
    • amplify learning: short iterations, increasing feedback
  • TDD, analytics, CI, …
    • decide as late as possible
    • deliver as fast as possible
    • empower the team
    • build integrity
    • vision of the whole
  • XP: pair programming, extensive code reviews, unit tests, avoiding new features until needed, flat management structure, frequent communication
  • Scrum VS Kanban
  • Defining technical feasibility
  • Defining scope of unit tests: scenarios, requirements, boundaries, assertions, …
  • Code review: code guidelines, tests, architecture

Estimation

  • cone of uncertainty: uncertainty is predictable, depending on stage of feature (from conception to development)
  • source of errors: finding everything that can go wrong
  • diseconomy of scale: scale of project is considered in estimations
  • count > compute > judge
  • delphi method: individual estimations, coordinator proposes value, group notes secretly if they agree. If one agrees, go back to discussion.
  • problems of estimating size: depends on person, on project, maturity, …
  • problems of estimating effort: past projects and different industries may not be comparable
  • problems of estimating schedule: can derive from the others, with historical data.
  • story-based scoping
  • PERT: statistical method of finding the minimum time possible to complete a project. It uses uncertainty not to take consideration of every activity.

Software Requirements

  • functional is what it should do
  • non-functional is what it should be
  • product champions are product owners
  • user classes: features, tasks, privileges, frequency, …
  • SW quality attributes: availability, efficiency, integrity, usability, scalable
  • assumptions vs constraints (risk analysis)
  • modeling techniques: data dictionaries, data flow diagrams, MER (ERD)
  • finding a product vision and keeping the scope

Object Oriented Design

  • Design Patterns:
    • Creational: abstract how objects are created. Singleton, factory, builder
    • Structural: compose classes and objects to form larger structure. Decorator, facade, adapter (when a class does not have the behavior you need)
    • Behavioral: algorithms and responsibility assignment. Observer, iterator, chain of responsibility.
  • Layered Architecture: an application where logic is separated by layers. App, presentation, session, transport, network, data, …
  • MVC: model has data and functionality, view handles presentation, controller handles user input.
  • IoC: dependency inversion, dependency injection. Populates the behavior with the appropriate implementation.
  • SOLID:
    • Single responsibility: one reason to change
    • Open-Close: extend a class behavior, without modifying
    • Liskov substitution: subclasses must be able to replace super classes
    • Interface segregation: fine-grained interfaces
    • Dependency inversion: depend on abstraction
  • Anti-Patterns
    • Cargo cult programming: stuff that serves no real purpose
    • Analysis Paralysis: over-thinking
    • Death march: people feel destined to fail

DB Design

  • MER: entities, relationships, attributes, normalization
  • 1NF: attributes of a tuple must contain one single value
  • 2NF: attributes are dependent on the key, not on each other
  • 3NF: all non-key attributes are mutually independent (postal code not necessary)
  • ACID:
    • Atomicity: all operations happen, or none happen
    • Consistency: transactions leave data in a consistent state
    • Isolation: user must see transactions happening one by one.
    • Durability: if a transaction is committed, its effects must not be lost
  • RDBMS: physical - shared memory - server - client
  • Transaction recovery: logs changes made by each transaction on stable storage
  • Transaction locking: 2PL (2-phase locking), transactions require locks to perform and release them afterwards
  • Transaction isolation: transactions may run in parallel, but they must seem serialized. Locking + time stamping + concurrency control
  • Transaction concurrency control by distributed locking
  • Denormalization can be useful when we want redundancy

Modeling

UML: Unified Modeling Language

  • Class diagrams: classes with functions and variables
    • → arrows are associations
    • ⇾ arrows is a generalization
  • Sequence diagrams
  • State machine diagrams
  • package diagrams (java -> util -> date)
  • MER

Algorithms

  • sorting
    • bubble (n^2)
    • merge (n*log(n))
    • quick sort (n^2, average n*log(n)) - choose a pivot, separate 2 sides in bigger or smaller, place pivot in center of division, start again
  • trees: height is log(n). Visiting can be pre order, in order, post order - log(n) if binary.
  • binary search: log(n) on sorted array
  • hash table: map values to a hash. Collision with chaining (list of elements)
  • stack, queue, linked list
  • balanced trees
  • graphs: directed or undirected, BFS, DFS (labyrinth)

Refactoring

  • Creation
    • replace constructor with creation methods
    • move creation to factory
    • encapsulate with factory or builder
  • simplification
  • generalization

Concurrency

  • threads run on shared memory, processes run independent
  • mutex owns a resource while using it
  • semaphore makes a task wait until it can continue

Distributed Objects

  • REST: GET to fetch, PUT to modify, POST to insert, DELETE to remove

Networking

  • layers
    • Physical (cable)
    • Data Link (Logical link)
    • Network (routing)
    • Transport (reliable packages)
    • Session (TCP/IP)
    • Presentation (translation)
    • App (HTML)