Skip to content

Latest commit

 

History

History
103 lines (102 loc) · 7.62 KB

software-engineering-problems.md

File metadata and controls

103 lines (102 loc) · 7.62 KB

<- Tilbake

Software Engineering Problems

  • Syntax
    • Read and control digital and analog I/O
    • Print to the Serial Monitor and Serial Plotter
    • Read from the Serial port
    • Create and use global and local variables
      • Why use constants?
    • Use if statements
    • Use while loops
    • Use for loops
    • Create and use functions
    • Basic use of Arrays
    • Pass-by-reference
  • Concepts
  • Communication
    • Serial (SPI)
    • Esp Now
    • I2C
    • MQTT
    • WiFi (Esp32)
    • Node-Red (Webserver)
  • Dicipline
    • Finding documentation and example code
    • Debugging and reading other peoples code
      • Debugging broken logic
        1. Locate the entrypoint of the program
        2. Track down the flow of the program function by function
        3. Add Serial.println() to see where the code fails
      • Debugging error messages
        1. Locating the error message in the stacktrace
        2. Considering whether the error might be caused by a different line than the error message suggests
        3. Googling the error
        4. Recognizing what solutions may look like
          • Typically in the form of a question at the top of a forum post, where the useful info is usually branded as "solution" or upvoted by many.
          • Recognizing what solutions do not look like so time is not wasted
          • Skimming through the solution to see if it makes sense
    • Following style guides and conventions
      • Setting expectations for what different code looks like
        • Easier to make assumptions to save time
        • Being able to trust variable and function names and naming schemes to inform about what the code does
    • Code splitting
      • Function names should in most cases be enough to understand what the code does
        • If not, split the function into smaller functions
    • Solving one problem at the time
      • Demonstrate conplex problems that are not possible to solve for a novice without practicing this principle
    • Testing code early and thoroughly
      • Ensure one has a solid foundation before continuing, to avoid having to go back and fix bugs later in a more complex system.
  • Architecture
    • Structs
      • What they should learn
      • What they should not learn
        • The term "Object Oriented Programming"
        • Constructors
        • Member visibility (Private and Public)
        • Inheritance
        • Overriding
        • Overloading
        • These concepts make up all the complexity of OOP, as well as all the pitfalls. They will not be needed in this course.
    • Creating functions that update globals, instead of returning the result
      • This makes the code more scalable (Mostly applies to the Arduino framework)
    • Subdividing problems and creating isolated systems to deal with them one by one