Functional Programming & Team Development

The relation between functional programming & team development

Transcript

1. Functional Programming And Team Development
2. The History Begin at 1930: “The lambda calculus was introduced by mathematician Alonzo Church in the 1930”
3. The Paradigm “a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.” - Wikipedia
4. The Benefits “ our programs can be broken down into smaller, simpler pieces that are both more reliable and easier to understand. “
5. The Jargon - function - expression - immutable - side effects
6. The Easy Way a: (int x) -> return x + 1 “it means there is only one input data, and there is only one output value” Everything is predictable, everything that depends on the function can be replaced with the value (RT). a(a(a(3))) -> a(a(4)) -> a(5) and the result is same -> 6 & no side effects
7. Side Effects Modification of state when calling a function - Update database -> update failed - Change button color -> change failed - Create file on disk -> no such file or directory - Save to memory -> save failed - Send to AMQP -> cannot connect
8. Statement & Expression Statement -> void Expression -> return something (including null/none/nil)
9. Immutable Once data defined it never changes
10. Reality We dont know the effect of our own codes.. ...and that’s why we need a unit tests! if a function there is a two condition return values plus one throws exception, then in our unit test should cover all of these conditions
11. Team We don’t know the effect of our own codes.. We don’t know the effect of our friend codes..
12. Bug! Our codes produce bug, and our friend’s codes too.. WHY?
13. The effect is.. WHO IS TO BLAME?
14. B(lame)D(riven)D(evelopment) I don’t care about your codes!! My code is works, your codes not!!
15. Codes - Not predictable - Too many jobs to do in single function - Too many side effects -> too many requirements ? - Too many return values ? - Not tested - It works in my laptop/device/env!! <- ultimate reason lv 99!!
16. Rules 80/20 - 85% 80% of our codes should be pure function (only) 20% of our codes has side effects Coral’s test code coverage -> 85% of our LOC
17. Software Architecture
18. What should we do as a team ? - Think first code later - Better team communication -> trust issues? - Better abstraction -> implement different solution - Stop iteration, let’s sit and evaluate our codebase (and requirements)! - Help others, not blame!
19. Quote use functional programming is a choice, but create and maintain a functional team (not individual) is a must! choose F(unctional)T(eam)DD not B(lame)DD