- Edward Garson


Functional Programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because emergent properties of the functional paradigm are well positioned to address the challenges posed by our industry's shift toward multi-core. However, while that is certainly an important application, it is not the reason this piece admonishes you to know thy functional programming.


Mastery of the functional programming paradigm can greatly improve the quality of the code you write in other contexts. If you deeply understand and apply the functional paradigm, your designs will exhibit a much higher degree of referential transparency.


Referential transparency is a very desirable property: It implies that functions consistently yield the same results given the same input, irrespective of where and when they are invoked. That is, function, evaluation depends less - ideally, not at all - on the side effects of mutable state.


A leading cause of defects in imperative code is attributable to mutable variables. Everyone reading this will have investigated why some value is not as expected in a particular situation. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability.



And we certainly don't get much help from industry in this regard. Introductions to object orientation tacitly promote such design, because they often show examples composed of graphs of relatively long-lived object that happily call mutator methods on each other, which can be dangerous. However, with astute test-driven design, particularly when being such to "Mock Roles, not Objects", unnecessary mutability can be designed away. 


The net result is a design that typically has better responsibility allocation with more numerous, functions that act on arguments passed into them, rather than referencing mutable member variables. There will be fewer defects, and furthermore they will often be simpler to debug, because it is easier to locate where a rogue value is introduced in these designs than to otherwise deduce the particular context that results in an erroneous assignment. This adds up to a much higher degree of referential transparency, and positively, and positively nothing will get these ideas as deeply into your bones as learning a functional programming language, where this model of computation is the norm.


Of course, this approach is not optimal in all situations. For example, in object-oriented systems this style often yields better results with domain model development(i.e., where collaborations serve to break down the complexity of business rules) than with user-interface development.


Master the functional programming paradigm so you are able to judiciously apply the lessons learned to other domains. Your object systems(for one) will resonate with referential transparency goodness and be much closer to their functional counterparts than many would have you believe. In fact, some would even assert that the apex if functional programming and object orientation are merely a reflection of each other, a form of computational yin and yang.


객체지향형 프로그램의 단점중에 하나라고 하면 지속적으로 변하는 내부맴버변수들을 효율적으로 컨트롤하지 못한다는 것이다.(동기화나 다른 여러가지 이슈)


함수들이 주어진 같은 입력에 대해 언제 어디서 호출되던지 상관없이 지속적으로 같은 결과를 얻도록 하는것이 참조 투명성의 바람직한 특징이다.


그러기 위해서 가급적이면 변하기쉬운 멤버변수들을 참조하기보다 그것들을 함수의 인자로 전달고 좀더 작고 많은수의 함수들로 책임을 나누게 하여서 훨신 더 높은 참조투명성을 갖게 하자는 것이 함수형 프로그래밍의 취지중에 하나이다.


물론 본문의 끝자락에 나와있드시 함수형 프로그래밍과 객체지향은 음과 양처럼 서로의 장단점이 있으므로 각자에 대하여 깊은 이해를 전제하여 각 과제마다 적절한 방식을 사용하는것이 주요하다.



Posted by 빨강토끼
,

Act with Prudence - Seb Rose


"whatever you undertake, act with prudence and consider the consequences" Anon


NO MATTER HOW COMFORTABLE A SCHEDULE LOOKS at the beginning of an iteration, you can't being under pressure some of the time. If you find yourself having to choose between "doing it right" and "doing it quick." it is often appealing to "do it quick" with the understanding that you'll come back and fix it later. When you make this promise to yourself, your team, and your customer, you mean it. But all too often, the next iteration brings new problems and you become focused on them. This sort of deferred work is known as technical debt in his taxonomy of technical debt, and it should not be confused with inadvertent technical debt.


Technical debt is like a loan: you benefit from it in the short-term, but you have to pay interest on it until it is fully paid off. Shortcuts in the code make it harder ot add features or refactor your code. They are breeding grounds for defects and brittle test cases. The longer you leave it, the worse it gets. By the time you get around to undertaking the original fix, there may be a whole stack of not-quite-right design choices layered on top of the original problem, making the code much harder to refactor and correct. In fact, it is often only when things have got so bad that you must fix the original problem, that you actually do go back to fix it. And by then, it is often so hard to fix that you really can't afford the time or the risk.


There are times when you must uncur technical debt to meet a deadline or implement a thin slice of a  feature. Try not to be in this position, but if the situation absolutely demands it, then go ahead. But (and this is a big but) you must track technical debt and pay it back quickly, or things go rapidly downhill. As soon as you make the decision to compromise, write a tack card or log it in your issue-tracking system to ensure that it dose not get forgotten.


If you schedule repayment of the debt in the next iteration, the cost will be minimal. Leaving the debt unpaid will accrue interest, and that interest should be tracked to make the cost visible. This will emphasize the effect on business value of the project's technical debt and enables appropriate prioritization of the repayment. The choice of how to calculate and track the interest will depend on the particular project, but track it you must.


Pay off technical debt as soon as possible. It would be imprudent to do otherwise.


맞습니다.

급한 프로젝트일정때문에 가끔은 "제대로하기"(doing it right) 보다는 "빨리하기"(doing it quick)를 선택해야될 경우가 많다.

그러지 않기 위해서 노력해야겠지만 어쩔수 없는 경우에는

빠른 주기로 재대로 고치를 작업을 해야한다.

그렇지 않고 놔두다보면 나중엔 정말 일이커져서 엄청난 위기에 봉착할수 있다.

 

Posted by 빨강토끼
,