One might argue “I can’t use a functional programming language.” Functional programming is about changing our way of thinking, not a programming language or technology.
#Thinking rock software code#
Every time they are reused, not much less code is written, but firstOf gives you the what and get(0) the ho w.
The more generic and simple a method is, the higher chances it will be reused. Notice firstOf and list methods are extremely reusable, even in production code. It became easy to read, highly maintainable, and highly reusable. Number of lines of code aside, the code now has phrases as list with item with Id=1 and name=“Toy” or assert that first of returned items equals to first of expected items. The final solution has more code than before, if we consider this one test. On the other hand, test readability is crucial, because tests are documentation, so the syntactic sugar is handy. 7 They don’t do much, and they aren’t ideal for production code, but test performance is less critical. Notice methods with, withId, and withName are syntactic sugar. Putting the functional hat on and using a few Java tricks, this was how it looked after (no Java 8 functional features were used): 6 Imagine if the Item constructor changed, how many places would it impact? The code had a strong smell from duplication.
#Thinking rock software series#
There is nothing wrong with it, except it was one from a series of similar tests, with few differences between them very common when doing test-driven development (TDD). Functional thinking in actionĭuring a recent feature implementation here at eBay, one of the tests looked as follows: 5 This is rock bottom, but the penalty in development costs started a long time before. It will eventually reach a point where it is impossible to change or maintain, becoming a Legacy System. The time taken to read and understand code will increase continuously I would say exponentially. If code is hard to understand, we try to change it the least we can. And I've never met a developer who hasn't felt frustrated when working with hard-to-understand code. Math aside, I have never met a developer who didn’t want to do a good job. 40% reduction in development time translates into a significant productivity increase. If code is improved to a point where reading is reduced by 50%, it yields a 40% overall reduction, as opposed to 10% overall reduction in the case of writing improvement. Overall impact on development from reducing activities time
Imagine a situation where developers spend on average 80% of their time reading code and 20% changing it.
#Thinking rock software software#
4 In the software development case, reading code takes the most time. 3 Amdahl's law tells us bigger overall gains are achieved if we tackle tasks taking longer. Robert Martin accounted “the ratio of time spent reading versus writing is well over 10 to 1”. Developers need to understand the code before changing it to implement new features or simply fix bugs. Why do developers read code? To change it. It has profound productivity implications and long-term consequences on the company. Writing concise and functional code is not about feeling proud of ourselves. How much code would have to be written the "traditional" way? The same required to read and understand the next time someone worked on it. The code above lists the IDs of items with errors sorted by selling date. The functional power is easier to perceive when consecutive methods are composed to solve a more complex problem: If the functional approach is used, every time we'll write less logic, reducing the odds of introducing errors. Very similar problems occur over and over again, sometimes on the same method. The real gain is not having three lines of code less. Nonetheless, it requires reading and understanding four lines of code to get to what the code is doing. Imperative thinking became so natural, we see past verbose code. “Oh, you mean filters sold items with no errors?! Why didn’t you said so?” 1Ĭonsider the following Java code that iterates through a list of sold items and adds the ones with no errors to a new list: Older languages such as Java, Ruby, and C# have incorporated functional principles as lazy evaluation, immutability, pure functions, and higher-order functions. Several new functional programming languages were created in the last decade. The first functional programming language was created in 1960 (LISP), but interestingly, Functional Programming is a buzzword in software development at the moment.
0 kommentar(er)
