Code Complete Lessons Learned

General Considerations

Design is part of the software engineering process
Also need to cater for how the engineers will review their code and how quality assurance will be ensured.
Need to know if we are doing a blackbox testing, integration testing, unit testing etc
Data Design - how is data organised
Database - key restraints, key value no cache, sql nosql
Files organised
Single data storage or multiple storage
High Fan In - determines how many classes uses utils/constants. Signifies if classes are reusable

Authentication for API - JWT, cookies, passwords, encryption
Data input/output
Scalability
Internationalisation - should it be an issue
Buy vs Build Decisions
Error Processing - how is error codes organised (https://stripe.com/docs/api/errors)

Problem needs to be solved at least once or part of it, and then solve it again for a more stable solution
Case Study: Tacoma Narrows Bridge - a suspended bridge, where the engineers only catered for how heavy the bridge should be able to handle, but did not cater for the air
Heuristic Approach - a.k.a Trial and Error approach

We need to specify how each subsystem will interact with each other, otherwise spaghetti interaction will ensure sooner or later
- For Example: Business Logic starts depending on GUI
Establish communications rules for each subsystem
- User Interface
- Application Level Classes/Business Logic
- Data Storage
- Graphics
- Enterprise Level Tools
  - for example, if you are doing windows dependent system, you need to seperate logic for it. Down the line you might need to change to OS, Linux
Division into classes within packages
Division into data and routines
- Interfaces, private classes etc

This is what usually programmers do everyday. This is done routinely consciously or not. Below are the things to consider.

Binding Time - binding specifies when a value is set to a variable
- Coding time (magic numbers)
- Compile time (constant)
- Run time (just in time, use of a method to fetch on run time)
Live time - variable declared vs when it is used
Learn to use abstract data types
There are different ways to handle errors
- Global exception handling
- Handle locally as much as possible
Declare only exception if calling method needs to know the error - this breaks encapsulation
- Return neutral values, ie, 0, “”, null, etc
Exception handling differs in different system see below (Robustness vs Correctness

if you are working on data critical system, i.e medicinal software, better the system shutdowns when an error occurs rather than returning incorrect values

A number of developers has been tested to prioritize: speed, readability, memory allocation, least code, time. And they all scored number one on what they prioritized. Programmers do what they are told to focus on.
Unit testing is never enough, one form of testing alone leaves the code brittle. It is a combination of tests that ensure quality
Logic tests are tests that check and variations in the logic. Every if for else any control flow.
No one testing method is enough.
- Keep a testing/error database record to assess the health of your application Scientific way of debugging. Dont just guess. Give brute force trying a definite limit
Make sure you put in architect that is well respected to set the standards rather than a non technical person

Hybrid Coupling - when a variable has more than one use.
- Example: pageCount will be set to -1 if a error occurs
Recursion is overrated, Stack space is limited and is quite slow
Table driven methods, direct table access like a month lookup, or insurance rate tables
- No Encapsulation, any change will immediately break code
Complexity can be determined by the number of decision points in a method. If or then and are all decision points
Data logic tests initializations of data in the the code.
"Dont document bad code rewrite it" Kernighan 1978

more people does not mean more progress. 9 women cant make a baby in a month