Against Golang Interface{Method}-abuse/pollution

  • using dynamically-typed language (JS, Python, PHP, Ruby, etc) just because it’s the most popular language — only for short/discardable project
  • mocking — there’s better way
  • microservice without properly splitting domain — modular monolith is better for small teams, introducing network layer just to split a problem without properly assessing surely will be a hassle in a short and long run
  • overengineering — eg. adding stack that you don’t need when current stack suffice, for example, dockerizing or kubernetesizing just because everyone using it, adding ElasticSearch just because it’s search use case, but the records needs to be searched are very little and rps are very low, a more lightweight aproach more make sense: eg. TypeSense or MeiliSearch or even database’s built-in FTS are more make sense for lower rps target/simpler search feature.
  • premature “clean architecture” — aka. over-layering everything that you’ll are almost never replace — dependency tracking is better
  • unevaluated standard — sticking with standard just because it’s a standard, just like being brainwashed/peer-pressured by dead people’s will (tradition) without rethinking is it still make sense to be followed for this use case?
  • not making SRS/Software Requirement Specification (roles/who can do what action/API) and SDS/Software Design Specification (this action/API will mutate/command or read/query which datastore or hit which 3rd party) — this helps new guy to be onboarded to the project really fast

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store