Archive for June 2015

Week 27, year 2015

  • Test-induced design damage or why TDD is so painful - I’m going to write a couple of posts on the topic of TDD. Over the years, I’ve come to some conclusions of how to apply TDD practices and write tests in general that I hope you will find helpful. I’ll try to distil my experience with it to several points which I’ll illustrate with examples. Test-induced design damage or why TDD is so painful How to do painless TDD Integration testing or how to sleep well at nights The most important TDD rule Stubs vs Mocks TDD best practices [Enterprise Craftsmanship]
Permalink | From 29 June 2015 to 05 July 2015 | Last updated on: Mon, 7 Jun 2021 09:11:15 GMT

Week 25, year 2015

  • About - Hello, I’m Nick Chamberlain. I write articles and gather content for this site and buildplease.com I have also authored Intuitive Testing with Legacy Code, Applying Domain-Driven Design with CQRS and Event Sourcing, and Event Sourcing and CQRS with .NET Core and SQL Server. What is this site all about? I’m a continual student of Domain Driven Design. While I share a lot of my expertise in C# and .NET at buildplease. [DDD Weekly]
  • KISS revisited - Today, I’m going to discuss the KISS principle. I consider it the second most valuable software development principle. [Enterprise Craftsmanship]
Permalink | From 15 June 2015 to 21 June 2015 | Last updated on: Mon, 7 Jun 2021 09:11:15 GMT

Week 24, year 2015

  • YAGNI revisited - I’m starting a new blog post series about the most valuable principles in software development. Not that I think you might not know them, but I rather want to share my personal experience and thoughts on that topic. The order in which I put those principles reflects their significance relative to each other, as it appears to be in my opinion. That is quite a large subject and I’m going to dilute it with articles on other topics, so it might take a while. Okay, let’s start. [Enterprise Craftsmanship]
  • Make hard-coding your default choice - Hard coding is often considered an anti-pattern. Having values that can change over time hard-coded in the source code requires recompilation every time these values actually change. While this statement is true, I think that hard coding should be the default choice when developing an application. Hard coding vs configuration file When you work on a project or feature, there always are some magic numbers or strings that potentially can change in future. [Enterprise Craftsmanship]
Permalink | From 08 June 2015 to 14 June 2015 | Last updated on: Mon, 7 Jun 2021 09:11:15 GMT