Thoughts about software development

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler https://www.martinfowler.com/bliki/TwoHardThings.html . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does...

Currently the most popular version control system is git and I'll be writing this based on git and it's functionalities and capabilities. Git is often seen as a way to enable distributed programming i.e. multiple programmers can work on the same code repository quite easily without disturbing each others work (much). In addition to that just like other VCS's it's also a log of work but to my experience that part is often unfortunately neglected. What I will be focusing this time is the log part because I think it deserves more attention. Why to create a meaningful log? The git log should consist from small meaningful changesets where each commit addresses a single problem. By dividing the log to small commits it enables resilient way of working. Being resilient enables simple and fast procedures to rollbacks, reviews, tags, branching etc. Lets say that a developer is implementing a REST API. The API needs a web layer that receives the HTTP requests, it probably has some...

Acceptance test are a great tool to verify that the application or system works as expected from end to end. Sometimes these tests can be called as end-to-end tests but sometimes end-to-end tests have a different meaning. Another term to describe the same functionality is QA tests and a subset of acceptance tests is often referred as smoke tests. The idea The idea is to define a input and the expected output and once the system and all it's dependant services are running the whole system can be verified to work as expected. In a ideal world the acceptance tests would be implemented based on the acceptance criteria of the use case. The implementation Acceptance tests can and should be implemented in the code just like unit and integration tests are implemented. The acceptance tests don't neccessarily reside in the same code repository as the code but they can, depending on what's the need. When a system is API the acceptance tests could be e.g. predefined HTTP requests with ...