開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《條條大路通羅馬 awesome-roadmaps》
今日推薦英文原文:《The KISS of Simplicity》

今日推薦開源項目:《條條大路通羅馬 awesome-roadmaps》傳送門:GitHub鏈接
推薦理由:一個關於各種學習路線圖的合集。一個職業或者說一個技術方向里包含了各種不同的技術,而路線圖就是指導初學者應當學習什麼的方向標,儘管多學總不會有錯,但是南轅北轍終究還是缺少效率的。路線圖的作者們眼界更廣,見到的東西更多,藉助他們的知識來作為自己下一步的參考自然不是個壞事,如果對接下來要學習什麼感到迷茫的話,興許這些路線圖會幫到你。
今日推薦英文原文:《The KISS of Simplicity》作者:Piotr Gaczkowski
原文鏈接:https://towardsdatascience.com/the-kiss-of-simplicity-b8153a69048e
推薦理由:簡單比複雜更容易操縱,儘可能讓成果變得簡單些

The KISS of Simplicity

Do less but do it better

Imagine a man appearing at a formal ball. He is wearing a perfectly tailored suit, the jacket of which is bright pink with a red checkerboard pattern. His pants are green with purple vertical stripes. The suit is the creation of a renowned designer and it cost quite a bit. The man also has a gold chain around his neck and ruby rings on both hands. Behind him, however, is a woman wearing a black dress and no accessories save for a pair of pearl earrings. Think about the two guests for a moment.

Which of the two would you consider elegant?

The IT industry knows the first type very well. The man in the suit is the equivalent of a system that cost a company millions. The system is made up of several components from different providers that often can』t communicate properly, and more often than not, freeze just at the moment you need to deliver an urgent message to your boss.

Elegance in Tech

Unix philosophy is closer to the lady in the black dress, with a focus on using tools or writing programs that do one thing but do it perfectly.

When we ask Google the definition of 「elegance.」 it offers two.
  1. 「the quality of being graceful and stylish in appearance or manner.」
  2. 「the quality of being pleasingly ingenious and simple; neatness.」
Wikipedia shows something similar with,
「Elegance is beauty that shows unusual effectiveness and simplicity.」
Why am I getting into elegance on a tech blog? Because it is we engineers who are to be blamed for over-complicated systems, a project going over budget, and the general ugliness (better known as 「the technical debt」) that surrounds our work. Most of us know the KISS principle, but we often forget about it each time there is a need to implement just one more feature in our code.

Photo by Dan Gold on Unsplash

What Hinders Elegance?

Tight time constraints are the main killers of elegant solutions. Simple does not equal 「quick」 or 「easy.」 Usually, it is the opposite. Simple design requires careful thought and analysis of all expected use cases, to come up with an idea that is clear and concise.

While you can build software without a proper design and without putting much thought into the scope of possible functions, maintaining that code will be a pain. Because each time there is a bug, it will most likely be caused by your lack of proper edge-case handling. And without a clear scope of what one function should or shouldn』t do, you』ll most likely end up adding a conditional clause somewhere in the code.

But after ten such cases, your code no longer looks like it did after the initial release. It』s now a soup of obscure conditionals and nobody knows what is the desired behavior of the application. Sometimes a change in something totally unrelated at first sight causes errors in a different subsystem. Everybody then scratches their heads and quietly reverts the last commit. Time for another approach.

Why Complex Is Easier to Implement

Elegant solutions require focus and observation. They require analysis, good communication with the client, and a well-thought scope. If you don』t have time to figure out all the possible input arguments or if you just can』t figure them out because you lack a proper design and the customer is unsure about how he will use the product, you end up skipping a few steps in the process of solving the problem.

But there is also another source of complexity. And this one is much harder to overcome. It』s the abundance of ready-made components and abstractions waiting for you to use. Front-End development is especially vulnerable. Writing an appealing web application using plain HTML5, CSS and Javascript is not an easy task.

That』s why we decide to trust a third-party to implement all the nitty-gritty details so we can focus on the important matters. We choose a framework, look out for a few more modules, and end up with the infamous 3GB node_modules directory. All should be quite alright as long as the abstraction layers in those modules align with our way of using them. More often than not, there is something we can』t agree on with our framework so we end up writing a terrible workaround or a special case just to make it work.

I wish I could share a viable way to deal with leaky abstractions, but I can』t. I don』t have one! But I』m aware we can』t just stop using them. This would be a huge waste of resources.

Photo by John Barkiple on Unsplash

How to Keep it Simple

You write a mobile application? Instead of creating your own backend, use a Backend-as-a-Service such as Firebase.

You want to host a landing page or a blog? Go with a static site generator (like Jekyll or Gatsby) and static file hosting (like Netlify).

You want a CMS with that? Check out Contentful or DatoCMS.

Tired of keeping track of SSL certificates for your web service? Go with an automated refresher like AWS ACM, Traefik, Caddy or Zombie Nginx.

Want your code to run 「on demand」 instead of paying fixed price of a VPC instance? Try a Function-as-a-Service (or Serverless) solution.

Oh, by the way, unless you have a very refined taste, it』s a good idea to use a managed database service like AWS RDS/Cloud SQL/Azure SQL.

To achieve simplicity is to reduce the number of components instead of accumulating them.

The Benefits of Keeping it Simple

More moving parts often mean more errors. In a classic blog engine example, you can expect at least the following problems:
  • Poor database performance.
  • Poor blog engine performance (insufficient memory/CPU).
  • Insufficient network throughput.
  • Disk space running out.
  • You overprovision for the most pessimistic use-case thus you overpay the rest of the time.
  • Broken deployments.
  • Database migration can run wild.
  • The VPC may disappear without a trace along with backups.
I』m not here to sell you a protection racket, but if you opt for a static site generator and a static file hosting, most of these problems simply go away. You also gain a free Continuous Delivery pipeline in which each source code change results in changes visible on the page. Both simple and feature-full!
下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/