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. ..

원본글은 github에 있습니다. 번역된 도메인 주도 설계 책 날개?를 보면 유명한 개발자들이 책에 대해 찬사한 짧은 글들이 있다. 워드 커닝햄의 글이 특히 좋아서 원문을 찾아보았다. 내가 deepl의 도움으로 번역해보니 번역책하고는 느낌이 좀 다른 것 같다. Ralph Johnson의 글을 보면, DDD는 extreme programming과 서로 다르지 않다. DDD를 이야기하면서 왜 익스트림 프로그래밍은 이야기 되지 않을까? Kent Beck This book belongs on the shelf of every thoughtful software developer. 이 책은 모든 사려 깊은 소프트웨어 개발자의 선반위에 있다. Ralph Johnson, author of Design Patterns..