제 1회 Paper Meeting에 여러분을 초대합니다.
기존의 단방향 세미나에서 탈피해, 새로운 형태의 모임을 만들었습니다.
하나의 Paper를 선택하시시면, 여러분과 동일한 Paper를 선택하신 분들과 조를 나누어 토론/지식 공유 모임을 하고
맨마지막 조별 10분식 자신의 조가 나누었던 애기들을 마인드 맵 형태로 정리해서 나누는 유익한 세미나 입니다.
좀더 자세한 정보및 등록은 http://www.onoffmix.com/e/only2u4u/149 에서 얻으실수 있습니다.
소프트웨어의 현재 상태를 모니터링하거나, 오류시 원인을 파악하기 위해 Log를 남기실 겁니다. 많은 분이 Log4J , Log4NET을 이용하십니다.
하루에 쌓이는 엄청난 로그양때문에, 골치 아프신 경험이 있다면 이 논문을 꼭 읽어 보시길 바랍니다.
이 패턴은 Logging 데이터의 Overflow를 막기 위해 우리가 어떻게 해야되는지 접근 법을 설명하고, Log4XXX(.NET, Java …) 의 내부기능과 비교하여 설명을 합니다.
혹시 소프트웨어를 만드실때, 땅콩버터 방식으로 만드시지는 않나요?
땅콩 버터라는 것은 Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스를 말합니다.
Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들때 주로 사용하는 방법입니다.
이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올수 있는 장점이 있습니다. 마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저수준의 Library를 개발할때는 이러한 방식이 선호 됩니다.
만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야하고, 다양한 시나리오를 요구하는 경우인데도, Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 국내의 많은 회사들이 이러한 구조를 가지고 있는데요. 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될뿐만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제등이 발생됩니다.
여러분에게 좋은 소식을 하나 전해드리고자 합니다.
POSA2에 이어 또 하나의 명서인 Framework Design Guidelines 2nd Edition의 편역을 위한 모임을 가졌습니다.
이 책은 Framework를 잘 설계하기 위한 Guideline을 제공하는 서적으로 Microsoft의 .NET Framework 설계팀들이 직접 집필한 서적입니다. Framework을 처음 설계하는 개발자에게는 매우 유용한 서적이 될듯 합니다.
현재 http://fdg.springnote.com 에서 작업을 시도하고 있으면, 저희 스터디시 만들어진 가치있는 공유물들을 여러분과 함께 나눌 생각입니다.
Conway’s law (콘 웨이의 법칙)
If you have four groups working on a compiler, you’ll get a 4-pass compiler
당신이 하나의 컴파일를 만들기 위해 4개의 팀을 만든다면, 당신은 4단계(four-pass) 컴파일러를 얻을 것이다.
이 말은 시스템의 구조는 시스템을 설계한 조직의 구조(형태)를 그대로 반영한다는 것입니다. 보면 볼수록 묘한 감정과 예전 기억들이 떠오르는 법칙입니다.
성공적인 회사생활을 하기 위해서는 순수한 개발 능력외에 많은 변수들이 우리를 따라 다닙니다.
- 사내 정치에 승리하기 위한 명분 만들기
- 서로간의 책임을 회피하기 위한 일 덜 가져오기
- 영업 / 기획 / 개발 부서 간의 대화 단절
- 직급 문화가 가져오는 대화의 단절 (상명하복의 의사 전달)
Architecture 101 