Akira Chou

Data Sci + Econ

9 minute read

CS169: Introduction to Software Engineering. I took this class during summer 2023 with Ethan Thomas Gnibus and Simon Jovanovic. The following notes are taken from Armando Fox and David Patterson’s textbook, Engineering Software as a Service: An Agile Approach Using Cloud Computing, Second Edition.

Module 1 & 2

Plan-and-Document lifecycle

  • Before development, come up with a project plan, including an extensive, detailed documentation **to improve predictability
    • Waterfall, Spiral, Rational Unified Process

Agile lifecycle

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • Progress is gauged by velocity: rate that a project completes features

Software Quality

  • Verification: Did you build the thing right? (Did you meet the specification?)
  • Validation: Did you build the right thing? (Is this what the customer wants?)
  • Testing
    • Problem: Non-exhaustive nature of testing
    • Solution: divide into unit testing, module testing, integration testing and system acceptance testing; Alternatives: Formal Methods
  • Beautiful Code: long-lasting code that is easy to evolve.
  • Legacy Code: software that, despite its old age, continues to be used because it meets customers’ needs. However, its design or implementation may be outdated or poorly understood.

Productivity

  • Clarity via conciseness
  • Synthesis
  • Reuse
  • Automation via Tools

SaaS

  • makes it easier for customers to use the service and the single version of the software at a centralized
  • Cloud Computing provides the scalable and dependable hardware computation and storage for SaaS

Module 3 & 4

Architectures

  • Client-Service Architecture — clients are programs whose specialty is asking servers for information and (usually) allowing the user to interact with that information, and servers are programs whose specialty is efficiently serving large numbers of clients simultaneously.
  • Peer-to-Peer architecture—every participant is both a client and a server

Web Infrastructure, HTTP, Restful APIs

  • Web browsers and servers communicate using the HyperText Transfer Protocol
    • request-response protocol: every HTTP interaction begins with the client making a request, to which the server delivers a response
    • stateless protocol: every HTTP request is independent of and unrelated to all previous requests
  • The fundamental protocol linking all computers on the Internet is TCP/IP, Transmission Control Protocol/Internet Protocol
  • Each computer connected to a TCP/IP network has an IP address, although the Domain Name System (DNS) allows the use of human-friendly names instead
  • REST (REpresentational State Transfer)
    • emerged as a simple, consistent way to do so that works well with Web technologies
    • represent each type of thing managed by the service as a resource, and provide a limited set of operations (typically Create, Read, Update, Delete, and Index) that can be performed on a resource
    • One way to apply the RESTful design stance to HTTP routes is to use the HTTP method (GET, POST, and so on) and the URI path to encode the resource and operation to be performed

Model-View-Controller

  • models that implement business logic, views that present information to the user and allow the user to interact with the app, and controllers that mediate the interaction between views and models.

Module 5 & 7

Partials, Validations and Filters

  • DRY—Don’t Repeat Yourself
  • A partial is Rails’ name for a reusable chunk of a view
  • Validations let you collect constraints on a model in a single place. Validations are checked anytime the database is about to be modified
  • Controller filters let you collect conditions affecting many controller actions in a single place, or set up instance variables used by many actions in a single place, by defining a method that runs before those actions

SSO and third-party authentication

  • the requesting app can verify the identity of the user via an authentication provider, without the user revealing her credentials to the requesting app

BDD

  • asks questions about the behavior of an application before and during development so that the stakeholders are less likely to miscommunicate
  • SMART: Specific, Measurable, Achievable, Relevant, Timeboxed
  • user stories describe how the application is expected to be used. lo-fi sketches are low cost ways to explore the user interface of a user story. storyboards capture the interaction between different pages depending on what the user does
  • User Stories to acceptance tests ⇒ Cucumber and Capybara
    • Cucumber — framework for writing user scenarios and turning them into acceptance tests
    • Capybara — framework used to simulate the user’s browser as they navigate through your webapp

Module 8 & 9

Test-Driven Development

  • Practice of first writing tests before you write new functional code
  • Red–Green–Refactor
    1. Write test for the behavior you expect the code to have.
    2. Red step: Run the test and verify that it fails since the behavior has not yet been implemented.
    3. Green step: Write the simplest possible code that achieves expected behavior and passes the test.
    4. Refactor step: Refactor/optimize your code and your test while ensuring that tests are passing
  • FIRST: Fast to run, with results Independent of the order in which they are run, thus Repeatably giving the same result. Each test should be Self-checking (the test code itself knows whether the test passed or failed), and should be developed in a Timely way with respect to the code it tests
  • Each test case follows the same structure: arrange (set up preconditions), act (stimulate the SUT), assert (verify the expected results)
  • Code coverage is a measure of how much code an suite of automated tests is running

Legacy Code, Refactoring

  • legacy code — code that stays in use because it still meets a customer need, even though its design or implementation may be outdated or poorly understood.
  • maintainability — easy with which a product can be improved
    • Corrective maintenance: repairing defects and bugs
    • Perfective maintenance: expanding the software’s functionality to meet new customer requirements
    • Adaptive maintenance: coping with a changing operational environment even if no new functionality is added; for example, adapting to changes in the production hosting environment
    • Preventive maintenance: improving the software’s structure to increase future maintainability

Metrics, Code Smells and SOFA

  • Software metrics provide quantitative measure of code quality. No consensus on which metrics are most important
    • Cyclomatic complexity and ABC score can be used to guide towards code that is in particular need of attention
    • C0 coverage: low coverage identifies under-tested code
  • Code smells — qualitative but specific descriptions of problems that make code hard to read
  • SOFA — four desirable properties of a method: it should be Short, do One thing, have Few arguments, and maintain a single level of Abstraction

Refactoring

  • Refactoring is needed for development to keep code maintainable. Refactoring while transforming the code improves software metrics and eliminate code smells
  • Without good test coverage, we lack confidence that refactoring or enhancing the code will preserve existing behavior

Module 10 & 11

Scrum Model

  1. What have you done since yesterday?
  2. What are you planning to do today?
  3. Are there any impediments or stumbling blocks?

Bugs

  1. Reporting a bug
  2. Reproducing the problem, or else Reclassifying it as “not a bug” or “won’t be fixed”
  3. Creating a Regression test that demonstrates the bug
  4. Repairing the bug
  5. Releasing the repaired code

Design Pattern

  • 23 Gang of Four design patterns are divided into Creational, Structural, and Behavioral design patterns
  • antipattern—a piece of code that would be better structured if it followed a design pattern
  • common issues ⇒ SOLID
    • S: Single Responsibility ⇒ A class should have one and only one reason to change
    • O: Open/Closed ⇒ Classes should be open for extension but closed for modification
    • L: Liskov Substitution ⇒ Substituting a subclass for a class should preserve correct program behavior
    • I: Injection of Dependencies ⇒ Collaborating classes whose implementation may vary at runtime should depend on an intermediate “injected” dependency
    • D: Demeter Principle ⇒ Speak only to your friends; treat your friends’ friends as strangers
  • Avoid common problems
    1. Viscosity: it’s easier to fix a problem using a quick hack, even though you know that’s not the right thing to do.
    2. Immobility: it’s hard to be DRY and because the functionality you want to reuse is wired into the app in a way that makes extraction difficult.
    3. Needless repetition: possibly as a consequence of immobility, the app has similar functionality duplicated in multiple places.
    4. Needless complexity: the app’s design reflects generality that was inserted before it was needed.

Unified Modeling Language

  • UML comprises a family of diagram types to illustrate various aspects of a software design and implementation

Module 6 & 12

Document Object Model, jQuery, Callbacks, Event Loops, AJAX

  • DOM — a standard representation of an HTML, XML, or XHTML document consisting of a hierarchy of elements
  • jQuery — introduced to provide an easy to use DOM API that hides differences in between browsers
  • Events — changes in the DOM such as when user mouse moves to a new element or user clicks a button or checkbox. Callback are functions that are setup to be run when certain event
  • Event loop — a paradigm in which programs wait for events to dispatch functions.
  • AJAX — Instead of making the user wait for a request to be processed (which leads to “freezing” the UI), the request is processed asynchronously

Dev/Ops

  • Development - Testing to make sure your app works as designed
  • Deployment - Testing to make sure your app works when used in ways it was not designed to be used
  • Three-tier architecture includes a presentation tier, which renders views and interacts with the user; a logic tier, which runs SaaS app code; and a persistence tier, which stores app data

Performance and Security

  • Responsiveness: How long do users wait before app delivers response?
    • ex. “99% of requests within any 5-minute window should have a latency below 100 ms.”
  • Release Management: How do we deploy/upgrade app in place without compromising availability and responsiveness?
  • Availability: What percentage of time is the app correctly serving requests?
    • gold standard of 99.999%
    • Apdex: SLO; 0 < value < 1; assigns full/half/no credit based on latency
  • Scalability: As users increases, does the app maintain availability + responsiveness without increasing cost per user?
  • Privacy+Data Integrity: Is data accessible/mutable to/by authorized parties?
  • Data integrity : Can the app prevent customer data from being tampered with, or at least detect tampering has occurred or that the data has been compromised.
  • Authentication: Can we trust that the user is who they claim to be?

Abusive Database Queries

  • “n+1” Query Problem: Association performs more queries than necessary
  • Table Scan Problem: Lack of proper indices for speeding up queries

Security

  • Least Privilege: User should have no more privilege than necessary for task.
  • Fail-Safe Defaults: User should be denied access unless explicitly authorized.
  • Psychological Acceptability: Protection should not make app harder to use.

Attacks

  • Cross-site request forgery (CSRF attack): tricking the user’s browser into visiting a different web site for which the user has a valid cookie, and performing an illicit action on that site as the user
  • Cross Site Scripting: Javascript Code added and re-rendered by a website can trigger execution of malicious scripts on other users’ browsers
  • Clickjacking (a.k.a. UI Redress): Attacker mimics legitimate web pages with carefully overlaid UI elements that, when interacted with, cause users to unintentional perform unwanted actions
  • SQL Injection: Poorly written queries + unsanitized inputs allows attackers to manipulate a database by passing in parts of SQL queries as form data.
  • Self-denial-of-service: A malicious denial-of-service attack seeks to keep a server busy doing useless work, preventing access by legitimate users
  • Prohibiting Calls to Private Controller Methods, Protecting Data Using Encryption