Jim Weirich: The Building Blocks of Modularity<\/p>\n
Interview questions:<\/p>\n
– What tech books have you read lately? To guage their interest in continued
\nlearning.
\n– How do you recognize a good design?<\/p>\n
Someone said they’d come and listen to him talk about oatmeal. So guess what?
\nHe’s going to talk about oatmeal.<\/p>\n
At one time, the thought was that matter was like a bowl of oatmeal, that it
\nwas fairly consistent all the way through with maybe a few lumps. Someone shot
\na particle emitter at a thin strip of gold, and found out that that wasn’t
\ntrue. Matter is like a bowl of oatmeal with rasins and apples in it. That’s
\nwhen scientists started developing their atomic theory. Several forces in the
\nuniverse: Gravity, Electromagnetism, Strong Nuclear, Weak Nuclear. Why should
\nthere be so many different forces? They tried to come up with Grand Unified
\nField Theory, and they’re still working on it.<\/p>\n
In computers, we have some principles we use to write software:<\/p>\n
– SOLID
\n– Law of Demeter
\n– DRY
\n– Small Methods
\n– Design by Contract
\n– etc.<\/p>\n
Is there a grand unified theory of software development? That’s what he wants
\nto think about and discuss today.<\/p>\n
Everyone should have a mentor when they get started in their careers. He did.<\/p>\n
Coupling & Cohesion. The connection between modules, and how well a module
\nitself fits together. Less coupling is good. Too much coupling is bad. Seven
\ndifferent types of coupling, according to Meyers:<\/p>\n
– None
\n– Data
\n– Stamp
\n– Control – when you have do describe the func with the word “or” or “otherwise”
\n– External
\n– Common
\n– Content<\/p>\n
Which boil down to local data and global data, and whether it’s simple or
\nstructured data.<\/p>\n
A simpler way to thing about coupling: Connascence – things that are born together and change together. If two pieces of software are tied together so that changing one requires changing the other. Rule: As the distance between software increases, the conanascence between the two should be weaker.<\/p>\n
Connascence of Position (with parameters to methods) versus Connascence of Name
\n(using a hash to pass parameters). The latter is better when there’s a large
\nnumber of parameters.<\/p>\n
Connascence of meaning. I.E. Don’t use magic numbers in your code.<\/p>\n
Contra-nascence – when it doesn’t matter what magic number you assign to two
\ndifferent constants, as long as they aren’t the same.<\/p>\n
Connascence of Algorithm. If you change a checksum checking func, and you have
\nto also change the corresponding function that generates the checksum.<\/p>\n
Connascence of timing, of value, etc. This entire talk is on github: git:\/\/github.com\/jimweirich\/presentation_connascence.git<\/p>\n","protected":false},"excerpt":{"rendered":"
Jim Weirich: The Building Blocks of Modularity Interview questions: – What tech books have you read lately? To guage their interest in continued learning. – How do you recognize a good design? Someone said they’d come and listen to him talk about oatmeal. So guess what? He’s going to talk about oatmeal. At one time, … <\/p>\n