juniqlog

원본글은 github에 있습니다. 애자일이 무엇인지는 이해하더라도, 실제로 일하는 방식을 어떻게 바꿔야 하는지 알기는 쉽지 않은 것 같다. 내가 생각하는 애자일한 개발자가 되는 구체적인 방법은 다음과 같다. 계획보다 대응하기 '계획보다 대응(적응)'은 애자일의 4가지 가치 중 하나다. 관련 원칙은 '요구사항변경 환영'이다. 애자일은 고객의 경쟁 우위를 위해 변경을 활용한다. 실천방법: 테스트 코드 요구사항 변경을 수용하는 하는 것은, 개발자의 시간을 빼앗아 간다. 만든 코드를 더럽힌다. 더럽혀진 코드는 시간을 더 빼앗아 간다. 코드는 더 더러워 진다. 요구사항이 변경되지 않는 프로젝트/소프트웨어는 거의 없기 때문에, 일반적으로 개발자는 자신이 만든 코드에 자신이 없다. 이 고통스러운 굴레에서 벗어나는 방..

원본글은 github에 있습니다. 애자일은 태생이 포괄적이다. 그래서 추상적이다. Plan(Predictive) Driven 마틴파울러에 따르면, 90년대 전통적인 개발방식(traditional plan-driven software engineering)의 문제점을 보완하려고 나타난 여러가지 방법론들이 있었다. XP, Scrum, Crystal, DSDM, FDD 등등의 방법론들이 발전하고 있었지만, 소수의견 이었고, 주류(전통적인 개발방식)에 대항하기 위해 힘을 모은 것 같다. 그 방법론들을 만든 사람들과 대표자들이 모여서 통합 선언문 만들었다. Agile이란 이름으로 결정되기전, 또 하나의 이름 후보는 'Adaptive'였다고 한다. 나는 그 동안 XP가 애자일의 구현체라고 생각했다. 모호한 애자일의..

원본글은 github에 있습니다. Alan Kay's OOP Pratices in Java (내 나름대로, 내가 이해한)앨런 캐이의 객체지향을 자바코드에 적용해보자. Smalltalk와 LISP에서만 가능하다고 했지만, 가능한 부분만 시도해보자. Pratices setter 금지 인스턴스 필드는 final 공개메소드의 요청/응답을 단순하게 예제 먼저 간단한 코드를 준비했다. RealWorld라는 블로그 애플리케이션은 글을 만들때 제목으로 slug를 만들어야한다. 'How to train your dragon' -> 'how-to-train-your-dragon' 이 요구사항을 코드로 만들어 보았다. DataStructureArticle makeDataStructureArticle(String title,..

원본글은 github에 있습니다. 상속보다 구성이 좋는 것은, 많은 사람들이 공감하는 주류의견인 것 같다. 나 또한 상속을 멀리하고 구성을 좋아하고 즐겨썼다. 그런데 Alan Kay가 틀렸다고 하는 글에 남긴 Alan 반박글에서 소개한 yegor의 글에 있는 댓글을 보고 생각이 많아졌다. 요약해보면, David West 아이디어의 핵심은, 문제공간(problem space)의 객체분해(object decomposition)다. 메세지의 핵심은 분해가 일어나도록 하는 것. 객체는 명령/제어 관계에서 벗어나지 않으면 독립적으로 행동할 수 없다. 한 곳에서 문제를 처리할 뿐이다. 객체는 문제 공간에서 스스로 작동할 수 있는 의인화된 개념. 메세지는 이를 가능하게 하는 체계. 메세징이 시스템에서 필요로하는 상태..

원본글은 github에 있습니다. Alan Kay가 틀렸다고 하는 글에 남긴 Alan 반박글에서 소개한 yegor의 글에 앨런은 많은 댓글을 남겼다. 인상적이었던 멘트들을 모아봤다. 객체간의 비명령적(non-command nature) 메세지는 자동으로 캡슐화를 제공한다. 객체는 발신자가 누구냐 등의 이유로 서로 다른 응답을 할 수있다. 이건 인터넷의 컴퓨터(서버)와 같은 개념이다. 다형성이란 용어는 우리가 만든거 아님. 우린 generic messages/methods라고 부름. 상속방식은 싫어서 위임사용. 좋은 동적 시스템을 설계/구현하는 것은 어렵지만, 그 방법이 hign level이라면 또 가능한 simple하면 좋겠다. 코딩해본 어른보다 어린이가 OO 배우는데 어려움이 없다. 객체간의 비명령적 ..

원본글은 github에 있습니다. 아래링크는 엘레강트 오브젝트의 저자 예고르의 글이다. https://www.yegor256.com/2017/12/12/alan-kay-was-wrong.html ‘object’라는 용어는 오해의 소지가 있으니, ‘messaging'이라는 용어가 더 적절했다. 라는 앨런 캐이의 말에, 예고르는 그렇지 않다고 했다. 글을 요약해보자면, messaging, composition 객체 간 상호 작용에는 ‘messaging’과 ‘composition’이라는 두 수단이 있는데 messaging 객체들이 동등하고 독립적인 ‘모듈'로서 통신한다. 다른객체와 ‘연결'되기 위해 불가피하게 많은 데이터를 노출해야된다. 캡슐화가 아니다. composition 통신해야하는 객체들을 더 큰 객체..

원본글은 github에 있습니다. Alan Kay는 Object Oriented이란 용어를 처음 만들었다. Alan Kay의 OO에 대해 좋은 글들이 있다. Alan Kay의 OOP (I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.) OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. ..

그때그때 기록을 잘 남겼으면 좋았을텐데, 지난 기억을 되새기며 작성했다. 부정확한 부분들이 있다. 시작 나는 경력을 시작하고 10년 동안 외주개발자(솔루션SI)로 일했다. 업무를 빠르게 파악하고, 소통하고, 문제없는 개발결과물 내는 것을 잘했다. 처음 3~4년 야근을 많이하고, 업무시간 이후에 업무/개발하는게 너무 싫었다. 개발은 나에게 일이고, 재미없지만 억지로 하는 것이었다. java, spring, javascript, jquery, oracle등 기술스택을 사용하고 controller, service, dao의 3layer에 업무를 구현했다. DB가 중심인, 트랜잭션 스트립트였다. 4~5년차쯤 하나의 회사에 4년정도 파견근무 했다. 년차도 차고, 한 코드를 오래보게 되었다. 코드에 뭔가 개선이 필..