Answer to a gentle polemic on Lessons Learned

This is an answer to: http://feelings-erased.blogspot.com/2020/03/robert-pajaks-lessons-learned-post.html Dear Grzesiek, I am very happy to see your answer to my blog post! It is a very valuable feedback for me. Thanks a lot. I wanted simply to leave a comment in you blog, but there is a limit of 4,096 characters. Therefore I decided to write my … Continue reading Answer to a gentle polemic on Lessons Learned →

Lessons Learned after 1 year of programming in Go as a C# developer

Before pointing out my lessons learned, I am going to describe my background and the way I was learning and using Go to give you some context and better understanding. I was writing in C# from 2009 to 2018. I was developing different sort of applications such as desktop apps, web apps, web services. Some … Continue reading Lessons Learned after 1 year of programming in Go as a C# developer →

Parsing Configuration

Most of the software needs some kind of configuration, which is dynamically loaded during runtime. Application Configuration For applications, usually the best place where to parse the application configuration is Composition Root, preferably close to the program entry. package main import ( "log" "github.com/caarlos0/env/v6" ) func main() { var cfg struct { URL string `env:"URL,required"` … Continue reading Parsing Configuration →

Do not believe any documentation

TL;DR; Do not believe any documentation. It might be incorrect or you may not understand it. Test everything. MSDN lies A few months ago I was writing some code in C# to get executable paths for all running processes. Generally, I tried the most common approach using BCL: string executablePath = process.MainModule.FileName; However, for some … Continue reading Do not believe any documentation →

TDD is not (only) about testing

Test-Driven Development is rather a design tool than a testing tool. Believe me (or not), but developers are not great at testing. They are too focused on getting the functionality done. Testers are always going to find bugs, even if there is 100% code coverage. What are the main benefits of TDD? Thinking first about … Continue reading TDD is not (only) about testing →

High code coverage does not guarantee high quality software

Let's look at an academic example: function CalculateQuadraticRoots(a, b, c) { delta = b*b - 4*a*c d = Math.Sqrt(delta) x1 = (-b-d) / 2*a x2 = (-b+d) / 2*a return [x1, x2] } function Test_CalculateQuadraticRoots() { result = CalculateQuadraticRoots(1, -1, -2) Test.Assert([-1, 2], result) } The code has 100% code coverage, yet it works (without … Continue reading High code coverage does not guarantee high quality software →