Published on 4 June 2020. This is approximately 50 minutes long. This episode is sponsored by Anchor.fm.
In this episode we dive into the topic of Defensive Programming with a focus on how to be defensive in a low code / no code platform. We talk about best practices, SDLC, coupling, and cohesion, and much more!
Listen on Anchor.fm
Listen on Spotify
Watch on YouTube
Defensive Programming Slide Deck
Timing for the topics is approximate, and meant to help you find specific parts of the conversation.
Definition of Defensive Programming
- Philosophy of writing code with the intention of handling unintended and unforeseen errors, bugs, and circumstances
- Defensive Design for the Web
1 min: Decisions we make as developers
Write an application which is correct
- Write code easy enough to understand so you don’t need documentation
Slide deck we’re discussing in this episode
3 min: Why talk about defensive programming?
Not much out there about defensive programming in low code available today.
6 min: Goal of defensive programming
Annotations - best practice in Mendix
Studio Pro - Using Annotations
7:45 min: Stay away from early optimization!
Use Studio Pro to break down a long micro flow which you know works
- Refactor after you have it working, not during the process
10 min: Slide 4 - two similar micro flows, early version, and late version
RESO Unique Organization Identifier (UOI) API
12 min: High level description of creating things in Mendix
13:50 min: Naming conventions
- How do you make sure you can have a consistent naming scheme?
Tools to scan your code for best practice implementation
18 min: Training materials from Mendix
19 min: Defensive Programming is more than error checking
- Architecture diagrams
- Shared context
- All parts of the SDLC help improve code
- Story refinements help understand what you’re trying to accomplish
21 min: Slide 6 - design patterns, even in low code
- Create or Retrieve existing
Slide 7 - validation micro flow to ensure you have good data
Slide 8: XPath selection
26 min: XPath order of constraints
- You need the first element to give you the most bang for the buck
Understand how your application will be used
- Think about the data you have to display, and ensure you’re making the application work correctly
- Keep in mind you’ll have to refactor as your application grows
- Do the most optimal for the audience or user base
30 min: Fail gracefully
- How do you allow the app to fail without leaving the user stuck
- Can you horizontally scale to keep the app running?
32 min: Dealing with bad user input
- Provide specific information to the user
- Handle errors and give back something useful
- Enable your production support team
Behind the scenes, write log information; provide the team the information necessary to solve the issue
- Write actionable log messages for the developers or production support
35 min: Mock data service
- Good data, mixed data, bad data
- Think about how you can easily generate data for testing and proving your defensive development
- Mock Data Generator - example
37 min: External services can change without you knowing
- Can you be defensive enough to handle unexpected changes?
- This isn’t low code, it’s every language
39 min: Cohesion and Coupling
- the amount to which the components of an object relate to each other.
- The goal is to increase cohesion
- the amount to which two objects are dependent upon each other’s behavior.
- The goal is to reduce coupling
Don’t Future Proof Yourself
Don’t let perfect get in the way of better
43 min: Review your logs, understand how your application is being used
- Address the issues you see in the logs
- Make sure you’re not leaving your users stuck in your app
What’s the first thing to think about in Defensive Programming in Low Code / Mendix
- All of the general software best practices still apply
- Give thought to what you’re doing, and what you’re trying to accomplish
45 min: Readability in Mendix
- Straight lines and decision trees in Mendix
- Layout of the micro flow is similar to the Tab vs Space discussion
- Shout out to //+
Rapid development allows you to make things that don’t work if you don’t pay attention.
Final Wrap up
- Naming Conventions
- Design Thinking
- Checking for Bad Data
- Error handling
Disclaimer: Some of the links provided are affiliate links meaning, at no additional charge to you, The Architect and the Executive may earn a commission if you make a purchase.