added thing_07 in pt_br

pt_br/SUMMARY.md

@@ -7,7 +7,7 @@
 1. [Automatize seu padrão de codigo](thing_04/README.md)
 1. [A beleza está na simplicidade](thing_05/README.md)
 1. [Antes que você refatore](thing_06/README.md)
-1. [Beware the Share](thing_07/README.md)
+1. [Esteja ciente da sua parte no todo](thing_07/README.md)
 1. [The Boy Scout Rule](thing_08/README.md)
 1. [Check Your Code First before Looking to Blame Others](thing_09/README.md)
 1. [Choose Your Tools with Care](thing_10/README.md)

pt_br/thing_07/README.md

@@ -0,0 +1,21 @@
+# Esteja ciente da sua parte no todo
+
+It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned — commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon!
+
+How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?
+
+It turns out that I was missing something critical.
+
+Context.
+
+The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those four lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along.
+
+The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.
+
+While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.
+
+These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context, these techniques are valuable. In the wrong context, they increase cost rather than value. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.
+
+Beware the share. Check your context. Only then, proceed.
+
+By [Udi Dahan](http://programmer.97things.oreilly.com/wiki/index.php/Udi_Dahan)