<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Golang on Simple Enough Blog</title><link>https://blog.dev.simpleenough.net/tags/golang/</link><description>Recent content in Golang on Simple Enough Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 23 Dec 2025 10:08:49 +0200</lastBuildDate><atom:link href="https://blog.dev.simpleenough.net/tags/golang/index.xml" rel="self" type="application/rss+xml"/><item><title>Using Constants in TDD with Go</title><link>https://blog.dev.simpleenough.net/blog/consttdd/</link><pubDate>Tue, 23 Dec 2025 10:08:49 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/consttdd/</guid><description>&lt;h2 id="best-practices-pitfalls-and-design-signals" class="heading">Best Practices, Pitfalls, and Design Signals&lt;a href="#best-practices-pitfalls-and-design-signals" aria-labelledby="best-practices-pitfalls-and-design-signals">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>&lt;strong>Test-Driven Development (TDD)&lt;/strong> is not only about writing tests.&lt;br>
Its primary purpose is to &lt;strong>design software&lt;/strong>.&lt;/p>
&lt;p>In Go, the use of &lt;strong>constants&lt;/strong> is often misunderstood in TDD:&lt;/p>
&lt;ul>
&lt;li>should they be exposed?&lt;/li>
&lt;li>tested?&lt;/li>
&lt;li>injected?&lt;/li>
&lt;li>avoided?&lt;/li>
&lt;/ul>
&lt;p>This article proposes a &lt;strong>pragmatic and idiomatic Go approach&lt;/strong>, based on real-world experience, to understand &lt;strong>when a constant represents good design&lt;/strong>… and &lt;strong>when it hides a deeper problem&lt;/strong>.&lt;/p></description></item><item><title>Interfaces, Functions and Modules in Go: Structuring Your Code for TDD Without Adding Unnecessary Complexity</title><link>https://blog.dev.simpleenough.net/blog/go-tdd-interfaces-functions/</link><pubDate>Mon, 15 Dec 2025 10:08:49 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/go-tdd-interfaces-functions/</guid><description>&lt;h2 id="i-introduction" class="heading">I. Introduction&lt;a href="#i-introduction" aria-labelledby="i-introduction">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Go is a minimalist language, but this simplicity can sometimes make developers feel like something is “missing” — especially when dealing with more advanced architectures, Test-Driven Development, or the need to mock dependencies. Developers coming from Java, C#, or Python often ask the same questions:&lt;/p>
&lt;ul>
&lt;li>&lt;em>Should I turn all my functions into structs + interfaces to test them?&lt;/em>&lt;/li>
&lt;li>&lt;em>How should I organize my packages to keep them modular and testable?&lt;/em>&lt;/li>
&lt;li>&lt;em>Where should interfaces live — in the provider or the consumer?&lt;/em>&lt;/li>
&lt;li>&lt;em>How do I isolate a package that only exports functions?&lt;/em>&lt;/li>
&lt;li>&lt;em>How does Go automatically detect signature changes?&lt;/em>&lt;/li>
&lt;/ul>
&lt;hr>




&lt;h2 id="ii-gos-model-simple-modular-but-different" class="heading">II. Go&amp;rsquo;s Model: Simple, Modular, but Different&lt;a href="#ii-gos-model-simple-modular-but-different" aria-labelledby="ii-gos-model-simple-modular-but-different">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Unlike Java or C#, Go does not rely on inheritance, classes, or heavy dependency injection frameworks.&lt;/p></description></item><item><title>How to Handle Optional Parameters in Go</title><link>https://blog.dev.simpleenough.net/blog/optiongo/</link><pubDate>Sat, 15 Nov 2025 10:00:00 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/optiongo/</guid><description>&lt;h1 id="i-how-to-handle-optional-parameters-in-go" class="heading">I. How to Handle Optional Parameters in Go&lt;a href="#i-how-to-handle-optional-parameters-in-go" aria-labelledby="i-how-to-handle-optional-parameters-in-go">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h1>
&lt;p>In most modern languages, you can define default values for function parameters or overload functions to cover various use cases.&lt;br>
Go, however, offers &lt;strong>no optional parameters&lt;/strong>, &lt;strong>no overloading&lt;/strong>, and &lt;strong>no default values&lt;/strong> in function signatures.&lt;br>
Yet the needs remain the same: creating readable, stable APIs that can evolve without breaking users.&lt;/p></description></item><item><title>Reverse</title><link>https://blog.dev.simpleenough.net/projects/reverse-project/</link><pubDate>Tue, 25 Feb 2025 00:00:00 +0000</pubDate><guid>https://blog.dev.simpleenough.net/projects/reverse-project/</guid><description>&lt;p>Visualization tool.
Triggering a scan to generate IaC for AWS.
Infrastructure History.&lt;/p></description></item></channel></rss>