Recently I’ve read about Pieter Level’s impressive way to build minimum viable products (MVP’s).
In the respective article he also descibes his coding style.
Table of Contents
DRY, KISS and no Frameworks?
Pieter explains why he avoids using frameworks and that he uses a „very basic“ tech stack:
Except for jQuery, I don’t use any frameworks. Why? Because many times, they just make things more complex. I kind of just write code. I do want to keep things clean and fast though. I like DRY KISSes: Don’t Repeat Yourself and Keep It Simple Stupid.
In fact he avoids using frameworks and libraries if not needed and creates solutions on his own instead.
No Frameworks
In a time where frameworks are everywhere and only few people seem to question this anymore, Pieter proves that it’s not only possible to create functional, scalable and (from my point of view) appealingly designed websites.
Not only back in 2014 he used almost no frameworks.
Today it’s still the same:
Yes but SQLite as db!
— @levelsio (@levelsio) April 3, 2022
Programming Principles – The Power of Simplicity with Frameworks
To learn more about the powerful simplicity of building software with a reasonable understanding of problem solving and a solid knowledge of the underlying programming languages (rather than frameworks), I’ve gathered some basic information about DRY, KISS and YAGNI.
DRY (Don’t Repeat Yourself)
- use pseudo code
- review your pseudo code an see if you are repeating yourself somewhere
- you should only repeat yourself on purpose (with a good reason)
- e.g. for comprehensibility reasons
KISS (Keep It Simple Stupid)
- use the simplest solution unless there is a good reason not to do it
- beneficial for you and others who work with your code
- may improve readability
- especially improves intuitive comprehensibility
- improves maintainability because of intuitive comprehensibility
- recommendation: Zen of Python guiding principles
- principles may be displayed in Python terminal using
import this
- principles may be displayed in Python terminal using
YAGNI (You Aren’t Gonna Need It)
- do the simplest thing that could possibly work
- start small, one step at a time
- use few tools (frameworks/libraries)
- rather use your own programming skills and do it yourself
- may improve maintainability because we rely less on other peoples software (updates)
Ask yourself
Do I really need that (library/framework/technology)?
May I eventually implement it later if needed?
Open Questions
- (Is it harder or easier to follow the principles compared to not following them?)
- Do we need a deeper and more solid understanding of the underlying languages if we don’t use frameworks, or is it rather a matter of using the language beneficially
- Is it harder or easier to build software based on the plain (vanilla) languages (without using frameworks)?
- Does using no frameworks require to actually master the underlying programming language(s)?
- Is using frameworks an excuse to enable mediocre programmers to be more effective within large companies (e.g. by standardizing the coding style and the way to solve problems)?
- Does using no frameworks require more practice to learn a language to a level where we are able to solve the problems ourselves (instead of using frameworks)?
- Is it beneficial for the process of learning, practicing and understanding the lnaguage if we use the plain language (instead of complementing it with frameworks)?
„Plain“ vs. „Premade“
Some time ago Adam Johnson recommended the following regarding Function Based Views (FBV’s) vs. Class Based Views (CBV’s):
I recommend a read of: https://t.co/6dckQYJBA3
— Adam Johnson (@AdamChainz) February 16, 2022
There seems to be a similar debate (similar to using „frameworks“ vs. „plain code“) about CBV’s vs. FBV’s within the Django community.
Low-Level vs. High-Level (Discussion)
In both debates the point of going the „plain“, low-level way („plain code“ respectively FBV’s) seems to be similar:
„Focus on the language, its capabilities and your own problem solving skills, rather than trying to fit your ideas and thinking inside pre-made layouts, which someone else created.“
In contrast people who advocate the high-level approaches („frameworks“ respectively CBV’s) may argue, that there are certain cases in software development which have been done so often before.
Hence other people have already created greatly working solutions for that, which you could just use by using „frameworks“ (or in case of Django views CBV’s).
„Plain coders“ again may oppose, that they don’t want or need to delve into a certain high-level approach which someone else created (which could hopefully solve their problem).
They’d rather want to solve their problems themselves and they want to know why it works and how it works without relying on someone elses code.
If the code breaks, they want to know what’s going on and they may feel more confident to find bugs in their own code, then investigating potential failures or drawbacks of the framework.
Besides their own individual code may be more flexible compared to the sloth of a giant framework, from which you’d only use a tiny fraction of functionalities anyway.
Neueste Kommentare