For the developer, Of the developer, To the developer For the developer, Of the developer, To the developer

많은 개발자들이 이 3가지에 대해 종종 혼돈을 일으키는 경우가 있다. 그래서, 이 부분에 대해 좀 더 명확히 하고자 한다. 물론 구글링을 하면 많은 답변을 얻을 수 있다. 그렇지만 서로 답변이 다르기도 하고 애매모호하게 말하는 경우가 있어 여기서 정리를 하고자 하는 것이다. 그렇다면 이제 자세히 알아보자. Feature 에 대해서 영어사전을 찾아보면 다음과 같은 답변을 얻을 수 있다. 특징, 출연하다, 기능 등등이다. 그렇다면 software에서는 feature를 무엇이라고 말할 수 있을까? 기능에 가깝다. 정확하게 말하자면 어떤 대상체가 무엇을 하는지를 말하는 것이다. 즉, 대상체의 특징은 대상체가 무엇을 하는지를 통해 규정이 된다. 즉, feature는 이것을 내포하고 있다. 대상체가 왜 존재하는지에..

그린마일이라는 영화를 아시는지? 우연히 티비를 돌려보다가 미션임파서블 폴 아웃을 보았습니다. 우리의 톰 아저씨보다도 그 옆에 조연들이 눈에 띄더군요. 그 중에서도 한명 덩치 큰 같은 요원 한명이 더욱더 눈에 띄더군요. 왠지 얼굴이 낯설지 않고 어디선가 봤던거 같고... 그린마일이라는 영화에서 톰 행크스가 갖고 있던 고환의 문제를 거기를 움켜줘서 해결했던 분이 비슷하기도 하고... 네 바로 그렇습니다. 그린마일의 주인공이 아닌가 싶었죠. 궁금하면 모합니까 인터넷의 세계인데. 그 세계로 들어가 그 분을 추적했죠. 빙 라메스라는 분이더군요. 그분의 필모 그래피를 쫓아갔죠. 어랏? 안보이네요. 그 분의 작품라인에 그린마일이 안보입니다. 이건 모지 하면서 다시 그린마일로 검색에 들어갑니다. 앗.. 실수 했네요. ..

나는 일을 잘하는 사람이 아닙니다. 그렇다고 끈임없이 끈질기게 일하는 사람도아닙니다. 그저 정의롭지 못한것을 멀리하고 참된일을 가까이 하였습니다. 그것이 날 여기까지 오게 한 이유였습니다. 그러다 보니 적당히 즐기면서 일하자라고 해도 마음 한켠에서 죄를 짓고 있다는 죄책감에 일을 열심히 하게 되었습니다. 물론 항상 놀지 않고 일만 한 것은 아닙니다. 놀기도 했지요. 그럴때마다 두 다리를 뻗고 자지 못했습니다. 불안했습니다. 쉰다는 것은 피로를 푼다는 것인데 쉬며서 정신의 피로를 풀지 못하고 오히려 쌓였다면 이것이야 말로 쉰것일까요? 아님 쉬지 못한 것일까요?  누구 아시는 분!!!!

글을 써라 계속 살아가다 보면 간혹 내가 지금 이 길을 왜 걷고 있지 내가 무얼 하고 있었지 라는 듯한 치매기가 보이게 되는 경우가 있다. 최근 들어 나도 종종 그러는 경우가 많다. 이런 경우 내가 치매가 있나? 라는 생각 보다는 내가 지금을 무엇을 하고 있었지를 찾지 마라 그건 당신이 치매기가 있어서 그러는 것이 아니다. 목표가 명확하지 않아서 그러는 것이다. 목표를 머리속에 심어두고 움직이지 않으니 그냥 하루 하루가 습관의 반복이 될 뿐이다. 좋은 습관은 날 좋은 것으로 이끈다는 생각에 좋은 습관을 만들려고 하지만 그 습관의 바탕에는 목적이 명확해야 한다. 그 목적을 통해 습관을 만들었다고 모든게 다 잘 이루어질 것이라 생각하지 마라. 목표를 끊임없이 머리속에서 떠들어야 한다. 그래야 내가 지금 할일..

3.4 다면적인 추상화 추상화에 할당된 책임이 둘 이상 있을 때 이런 악취가 발생한다. - 설계 구성 요소에서 일어나는 잦은 변경과 발생한 결함 수 사이에는 종종 강한 상관관계가 존재한다. 이것은 다면적인 추상화가 엄청난 결함으로 고통받기 쉽다는 사실을 의미한다. 다면적인 추상화는 설계 품질을 떨어뜨리므로 리팩토링을 거쳐 기술 부채를 해소하며 더 이상 쌓지 말아야 한다. 추상화에 여러 '책임이나 '측면'이 존재하므로, 이런 악취를 '다면적인 추상화'라 명명한다. 주기적인 리팩토링을 통해 계속 쌓일 수 있는 technical debt 을 제거해야 한다. 제거하지 않으면 결국 design smell 이 발생할 수 밖에 없다. 3 Abstraction smells 3.1 Missing abstraction 3..

꿈을 먹고사는 괴물이 있었습니다. 그 괴물은 꿈을 먹어야 살 수 있었습니다. 그래서 꿈을 만들어야 하기 때문에 괴물은 계속 꿈을 꾸어야 했었습니다. 이룰 수 있을 것 같은 꿈. 이룰 수 없을 것 같은 꿈. 그 괴물은 방 한구석에서 계속 꿈을 꾸었습니다. 자기가 먹을 수 있는 꿈을. 그런데 그 괴물이 커갈 수록 그 괴물이 먹을 수 있는 꿈은 적어졌습니다. 그래도 계속 꿈을 꾸려 했지만 그가 꿀 수 있는 꿈은 너무 줄어들어 꿈을 꾸기 힘들었습니다. 이전에는 실현 불가능한 꿈만 꾼 게 아니라 조금만 더 하면 꿀 수 있는 꿈도 꿀 수 있을 수 있었습니다. 그런데 그 괴물은 살아가면 살아갈 수록 꿀 수 있는 꿈이 적어졌습니다. 그 이유는 이미 지나간 시간의 꿈을 꿀 수 없었기 때문입니다. 그리고, 현재의 모습에서..

이 책의 구성은 다음과 같다. 큰 챕터 UML, Architectural pattern, … 에서는 왜 이 것을 해야 하는지를 설명한다. 작은 내 생각들을 풀어나가면서… 물론 기술을 읽는 부분이 중요하지만 왜 이걸 이렇게 이 단계에서 해야 하는지를 이해하지 못하고 단순 기계처럼 기술만 읽는다면 내가 여기서 말한 것만큼만 가능하지 그 이상을 발전시킬 수 없다. 내가 설명하는 것이 지금은 맞을 지라도 나중에는 맞지 않을 수도 있기 때문이다. 기술은 하루가 다르게 변화하기 때문에 그 기술을 사용하기 위해서는 최적의 방법이 계속 바뀔 수 밖에 없는 것이다. 이 책을 읽는 독자분들은 나랑 동등한 레벨에서 시작해서 더 나은 레벨로의 발전이 필요하고 해야만 하기 때문이다. 그리고나서 해당 부분의 하위 카테고리에서 자..

UML Component diagram Class diagram Sequence diagram State diagram UML structure Component vs Module Class and Package Dependency Diagram SOLID principle SRP (Single Responsibility Principle) OCP (Open/Closed Principle) LSP (Liskov Substitution Principle) ISP (Interface Segregation Principle) DIP (Dependency Inversion Principle) Design pattern Hardware proxy pattern Factory method pattern Abstra..