REST APIs

• How to (and how not to) design REST APIs
• How to Create a RESTful API with Python and FastAPI
• How to Create Microservices with FastAPI
• system-design-primer
• Microservices-in-python-using-flask

• microservices showcasing Kubernetes, Istio, and gRPC.

Code Review Checklist

The rules are:

𝟭. 𝗔𝘃𝗼𝗶𝗱 𝗖𝗼𝗺𝗽𝗹𝗲𝘅 𝗙𝗹𝗼𝘄: Steer clear of tricky control structures; stick to simple loops and conditionals.

𝟮. 𝗕𝗼𝘂𝗻𝗱 𝗟𝗼𝗼𝗽𝘀: Ensure loops have a clear exit point to prevent endless looping.

𝟯. 𝗔𝘃𝗼𝗶𝗱 𝗛𝗲𝗮𝗽 𝗔𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Favor stack or static memory allocation to dodge memory leaks.

𝟰. 𝗨𝘀𝗲 𝗦𝗵𝗼𝗿𝘁 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀: Keep functions concise, handling a single task. This goes along well with Clean Code practices (Signe responsibility principle).

𝟱. 𝗥𝘂𝗻𝘁𝗶𝗺𝗲 𝗔𝘀𝘀𝗲𝗿𝘁𝗶𝗼𝗻𝘀: Utilize assertions to catch unexpected conditions.

𝟲. 𝗟𝗶𝗺𝗶𝘁𝗲𝗱 𝗗𝗮𝘁𝗮 𝗦𝗰𝗼𝗽𝗲: Keep the scope narrow to maintain clarity. Use the smallest scope for your variables (e.g., private or protected in C#).

𝟳. 𝗖𝗵𝗲𝗰𝗸 𝗥𝗲𝘁𝘂𝗿𝗻 𝗩𝗮𝗹𝘂𝗲𝘀: Always check the return values of functions, handling any errors.

𝟴. 𝗦𝗽𝗮𝗿𝘀𝗲 𝗣𝗿𝗲𝗽𝗿𝗼𝗰𝗲𝘀𝘀𝗼𝗿 𝗨𝘀𝗲: Minimize preprocessor directives for readability.

𝟵. 𝗟𝗶𝗺𝗶𝘁 𝗣𝗼𝗶𝗻𝘁𝗲𝗿 𝗨𝘀𝗲: Simplify pointer use and avoid function pointers for clearer code.

𝟭𝟬. 𝗖𝗼𝗺𝗽𝗶𝗹𝗲 𝗪𝗶𝘁𝗵 𝗔𝗹𝗹 𝗪𝗮𝗿𝗻𝗶𝗻𝗴𝘀 𝗘𝗻𝗮𝗯𝗹𝗲𝗱: Address all compiler warnings to catch potential issues early. This is often neglected in many projects!

Coding Guidelines

How I spend my time as a developer:

• 10% writing code
• 20% refactoring
• 70% reading code

This is why I optimize my code for readability while still in the writing stage.

It always pays off in the long run.

And I know the next engineer reading that code will be thankful.

So think about this next time you're hurrying to finish a task.

Here's a checklist in no particular order:

• Variables defined close to where they are used
• Fluent syntax structured vertically
• Names are descriptive
• 80 characters per line
• Early return principle

Keep Exploring!!!

Code Review pointers

• Purpose of the code, the approach taken, and any specific areas 
• Error and Exception Handling: Look for proper error and exception handling for robustness. The application should be able to survive erroneous situations.
• Separating source code, tests, and configuration files neatly.
• Separate Data Preprocessing, Modeling, and Evaluation Code: It’s crucial to separate stages of the development process into distinct steps. This allows both modularity and an easier debugging experience, as issues can be located more swiftly in well-defined sections.
• Design a Configurable Pipeline: A pipeline that can be configured allows for easy adjustments to be made and allows various models, data, and preprocessing steps to be swapped out with one another efficiently.
• Breaking up a configuration into separate classes can increase modularity. Each config class can be responsible for one part of the application's configuration. This makes the code easier to read and maintain.
• How easy to test, How standalone it is
• Key approaches applied / Do's and do
• Is it at a level people can come/contribute / Open to DS forecast tracking people
• Basics needed to work on it
• Basics needed to understand it / Any references/patterns to cross-check
• Does it have good enough documentation/testing 
• Have we implemented for one DB, or have we implemented for others to follow the pattern?
• Have we tested end-to-end in one flow?
• How do we manage configurations across data, ML, jobs, and results? Are these separate classes? 
• This current work is fetching results, running pipeline, fetch status, Is there equivalent work done?
• What flow do we need porting type work? Mimic the same patterns?
• How to test standalone?
• What minimal knowledge to operate on this

Keep Exploring!!!

Learning from code reviews

An interesting read from link

My favorite list

Perspective #1 - You don’t need hundreds of engineers to build a great product

[Siva] - Have a set of ideas, experiment, fail, learn, unlearn, relearn, and Build a vision of the product not under the pressure of timelines

Perspective #2 - Simple Outperformed Smart

[Siva] - Start to crawl before you learn to run

Perspective #3 - Our highest impact findings would always come within the first and last few hours of the audit.

[Siva] - Functionality, Scalability, Performance matters

Perspective #4 - Business logic flaws were rare, but when we found one they tended to be epically bad

[Siva] - Product is a for customer need not for experimenting technology. Build what is needed for the customer, provide the customer experience

Perspective #5 - Quick turnarounds on fixing vulnerabilities are usually correlated with general engineering operational excellence.

[Siva] - Quality ideas come from the domain, data, and functional understanding. Think from the long term no near term fixes

Good Read - Link

• How does the number of reported defects in source code files correlate to source code quality?
• How much longer development time is needed to resolve an issue in files with low-quality source code?
• To what extent is the code quality of a file related to the predictability of resolving issues on time?

Keep Thinking!!!

Python coding review tools - Docker, Kubernetes

Good read on code quality Tools - Link

Picked and checked on below tools for example project

• Bandit - security issues
• Pylint - coding standard 
• pycodestyle - code style 

Download Project - Link

Result #1

Result #2

Result #3

This CI / CD 8th Lab video  was motivational to explore these tools. Need to re-read this session again.

Tool Links

pylint

bandit

pycodestyle

code - link

Todo List

Good Reads

• Exploring Shap - Link1, Link2
• Python Best Practices for a New Project in 2021 - Link1
• ML-Ops_ModelDeployment_k8s - Link1

Keep Exploring!!!