New chapter: data flows

content/books/things-i-learnt/_index.md

@@ -13,6 +13,7 @@ template = "section-contentless.html"
 		* [Write Steps as Comments](steps-as-comments)
 		* [Gherkin Is Your Friend to Understand Expectations](gherkin)
 		* [Design Patters Are Used to Name Solution, Not Find Them](patterns-not-solutions)
+		* [Thinking Data Flow Beats Patterns](data-flow)
 	* Testing Software
 		* [Unit Tests Are Good, Integration Tests Are Gooder](integration-tests)
 		* [Testing Every Function Creates Dead Code](tests-dead-code)

content/books/things-i-learnt/data-flow/index.md

@@ -0,0 +1,35 @@
++++
+title = "Things I Learnt The Hard Way - Thinking Data Flow Beats Patterns"
+date = 2019-06-26
+
+[taxonomies]
+tags = ["en-au", "books", "things i learnt", "data flow", "design patterns"]
++++
+
+When you're trying to find a solution to your problem, think on the way the
+data will flow through your code.
+
+<!-- more -->
+
+Instead of focusing on design patterns, a better way is to think the way the
+data will flow -- and be transformed -- on your code.
+
+For example, the user will input a number. You'll get this number and find the
+respective record on the database. This is a transformation -- no, it's not
+"I'll get the number and receive a complete different thing based upon it",
+you're actually transforming the number into a record, using the database as a
+transformation.
+
+(Yes, I know, it's not that clear at the first glance, but you have to think
+that they are the same data with different representations.)
+
+Most of the time I did that, I managed to come with more clear design for my
+applications. I didn't even think about how many functions/classes it would be
+needed to do these kind of transformations, that was something I came up
+_after_ I could see the data flow.
+
+In a way, this way of thinking gets things more clear 'cause you have a list
+of steps of transformations you need to do, so you can write them one after
+another, which prevents a lot of bad code in the future.
+
+{{ chapters(prev_chapter_link="/books/things-i-learnt/patterns-not-solutions", prev_chapter_title="Design Patters Are Used to Name Solution, Not Find Them", next_chapter_link="/books/things-i-learnt/integration-tests", next_chapter_title="Unit Tests Are Good, Integration Tests Are Gooder") }}

content/books/things-i-learnt/integration-tests/index.md

@@ -66,4 +66,4 @@ parts.
 [^1]: There is no "unit" in "unit tests". "Unit test" means the test _is_ a
   unit, indivisible and dependent only on itself.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/patterns-not-solutions", prev_chapter_title="Design Patters Are Used to Name Solution, Not Find Them", next_chapter_title="Testing Every Function Creates Dead Code", next_chapter_link="/books/things-i-learnt/tests-dead-code") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/data-flow", prev_chapter_title="Thinking Data Flow Beats Patterns", next_chapter_title="Testing Every Function Creates Dead Code", next_chapter_link="/books/things-i-learnt/tests-dead-code") }}

content/books/things-i-learnt/patterns-not-solutions/index.md

@@ -35,4 +35,4 @@ but above 50%); what happens then is that people start twisting the problem to
 fit the pattern or, worse, add new layers to transform the problem into the
 pattern.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/gherkin", prev_chapter_title="Gherkin Is Your Friend to Understand Expectations", next_chapter_link="/books/things-i-learnt/integration-tests", next_chapter_title="Unit Tests Are Good, Integration Tests Are Gooder") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/gherkin", prev_chapter_title="Gherkin Is Your Friend to Understand Expectations", next_chapter_link="/books/things-i-learnt/data-flow", next_chapter_title="Thinking Data Flow Beats Patterns") }}