Java Magazine, Nov/Dec 2016

ORACLE COM JAVAMAGAZINE NOVEMBER DECEMBER 2016 39 junit 5 the smallest possible increment of functionality Where did that view come from What was important about the smallest possible increment Beck If you have a big beautiful Italian salami and you want to know how long its going to take to eat the whole thing an efective strategy is to cut of a slice and eat it and then do the arithmetic So 1 millimeter takes me 10 seconds then 300 millimeters are going to take me 3000 seconds now maybe more maybe less There may be positive feedback loops negative feedback loops other things to change that amount of time but at least you have some experience with it The diference between a journeyman programmer and a master from my perspective is that the master never tries to eat the whole salami at once Number one they always take some big thing and they put it into slices Thats the first skill figuring out where you can slice it The second skill is being creative about the order in which you consume the slices because you might think you have to go left to right but you dont Somebody says Well you have to write the input code before you can write the output code I say I respectfully disagree I can build a data structure in memory and write the output code from that So I can do input and then output or output and then input If I have n slices I have n factorable permutations of those slices some of which dont make any sense but many of which do So the two skills of the master programmer are slicing thinner slices and considering more permutations of the slices as the order of implementation Neither of those skills ever reaches any kind of asymptote You can always make thinner slices and you can always think of more orders in which to implement things to serve diferent purposes If you tell me I have a demo on Friday I implement things in a diferent order than if you tell me I have to run a load test on Friday same project Im going to slice it diferently and Im going to implement the slices in a very diferent order depending on what my next goal is Binstock So the smallest possible increment is a general rule to apply when there are other factors that dont suggest thicker slices Beck I dont believe in the smallest possible slice I believe in figuring out how to make the slices smaller As small as I think Ive gotten the slices I always find some place some way to make them half that size and then I kick myself Why didnt I think of this before Thats not one test case thats three test cases Then progress goes much more smoothly Binstock Well if it hews very closely to the single responsibility principle it seems to me that you could have the same dynamic there where methods do just very very small operations and then you have to string together thousands of little tiny BB sized methods and figure out how to put them together Beck That would be bad because if you had to open 40 or 50 classes I would argue that violated cohesion at some point and thats not the right way to factor it out Binstock I think were heading the same way that there is a limit at which cutting the slice even thinner doesnt add value and starts to erode other things Beck Well today and then I sleep on it and I wake up in the morning and go Why didnt I think of that If I slice it sideways instead of up and down clearly it works better Something about walking out the door on Friday afternoon and getting in my car to go home that was the trigger for me Literate programs just dont maintain very well because theres so much coupling between the prose and diagrams and the code