[카테고리:] 개발

Architects must continuously develop and exercise “contextual sense” – because there is no one-size-fits-all solution to problems which may be widely diverse. (by Randy Stafford) “영역에 맞는 감각”으로 번역한 이 말은, No Silver Bullet (SW 개발에 있어서 한방에 모든 것을 해결할 수 있는 방법은 없다) 과 같은 맥락을 가지고 있는 말이다. 문제를 해결하는 방법이 상황(경우)에 따라…

생각의 다름을 인정하는 것이 참 중요함을 느낀다. 그러나 쉽지 않다. 우리가 사람이기 때문이 아닐까? 그 다름이 틀린 것, 잘못된 것이라고 공격하는 순간! 소통에 비상이 걸린다. 비난과 비판의 차이로도 볼 수 있으나 아주 좋은 비판도 쿨하게 받아드리기가 쉽지 않다. 상대방을 배려하는 비판이 필요하다. 어쩌면, 나와 다른 생각이 정말 틀린 것, 잘못된 것일 수 있다. 그것이 고쳐져야…

직장 생활을 처음 시작한 2000년도에는 움직이는 작은 흑백 이미지를 휴대폰에 보여주는 것도 대단한 시절이었다. 내가 있던 회사는 그 기술을 만들어서 응용과 콘텐츠를 팔아 돈을 벌었다. 콘텐츠가 답이다. 당시 모 차장님께서 했던 말인데, 그 말을 지금도 기억하고 있다. 콘텐츠가 돈이 된다는 뜻이었다. 그러나 일부 회사를 제외하고는 생각보다 돈을 벌기 쉽지 않았던 것 같다. 통신사에게 굽신 굽신해야 했고, 통신사를…

팀에서 함께 세미나 했던 책이다. 각각의 주제에 대한 친절한 설명이 주어지지 않고, 제목과 내용이 약간 안맞는 것들도 있는 듯하지만 여러 가지 통찰력을 얻을 수 있어 읽어볼 만한 책인 것 같다. 여러 번 읽어보면 도움되는 주제들이 꽤 많다. 97 Things Every Software Architect Should Know, PDF Other Things Software Architects Should Know

업계에서 유명하고(?) 훌륭한 아키텍트와 회사 임원 앞에서 아키텍트 활동을 보고하고 평가 받는 자리가 있었다. 많은 경험과 실력으로 내공이 느껴지는 아키텍트의 코멘트가 무척 의미가 있었다. – 아키텍트는 훌륭한 표현력을 활용하여 개발자에게 도움이 되는 Communicator 역할을 해야 한다.– Reference Implementation 이 반드시 필요하다. 거룩한 말씀만 하는 사람이 되면 안된다.– SW에 맞지 않는 툴 혹은 프로세스(예:식스시그마)를 적용함에 있어서…

TV를 너무 가까이 보면 눈에 좋지 않고 너무 멀리 보면 잘 감상할 수 없다. 시청에는 적당한 위치가 있다. UI 전문가는 이를 고려하여 <10피트 UI>를 개발한다. 모든 일이 그러하겠지만 architect에게도 소프트웨어를 바라보는 적당한 위치가 있어야 한다. architect를 바라보는 외부의 시각도 그때 그때 다르다. “당신이 지금 코드를 보고 있으면 어떡합니까?” 하는 분들도 있고 “architect가 lockup 이슈도 못…

개발자의 역량이 중요하다. 절대 틀린 말이 아니다. 다만, ‘개발자의 역량’ 이란 이름으로 모든 책임을 개발자에게 전가 시킬 때가 있어 불만이다. – 개발자가 문서를 잘 쓸 수 있도록 Technical Writing 교육을 시키자.– 요구 사항 분석이 중요하니 개발자가 잘 분석해서 작성할 수 있도록 하자.– 개발자가 단위 테스트를 잘 할 수 있도록 가이드 하자. 개발자가 내적 동기를 통해…

똑같은 단어를 쓰면서도 의견이 너무 다르다. 그래서 회의가 길어지고 길어진 회의는 사람을 지치게 한다. 좋게는 합의에 이르는 과정이라고 볼 수도 있겠지만 고민스러울 때가 많다. 서로 다른 각자의 경험과 생각을 기반으로 이해하고 있기 때문이다. 우리가 자주 사용하는 용어(단어)를 정확하게 정의하고 시작하는 것이 필요하다.

아키텍트가 다루는 핵심 주제는 “아키텍쳐 설계”이지만 실제 아키텍트가 다루는 주제는 소프트웨어 엔지니어링 전반에 걸쳐있다. 그 범위가 넓기 때문에 집중하기 쉽지 않고 다양한 이해 관계에서 다양한 요구가 들어온다. 돌고래 처럼 깊이 들어가야 할 때도 있고 높이 올라와야 할 때도 있기 때문에 심리적인 부담이 크다. 알아야 할 것은 많고 잘 알아야 하며 사람들에게 인정을 받아야 한다. 그게…

아키텍처 설계(Architecture Design)는 기술된 형태(Architecture Description) 즉 설계서(Architecture Documentation)로 표현된다. 그래서 조직 및 기능에 맞게 설계된 템플릿은 유용하고 구조화된 설계 문서는 중요한 자산이 된다. 그러나 템플릿에 맞추는 것이 목적이 되는 경우를 종종 본다. 템플릿은 설계를 잘 할 수 있도록 가이드 해 줄 수 있지만 설계라는 본질적 내용을 대체할 수 없다. 주객이 전도되는 그 순간부터 문서화는 재미가 없어지고…

Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value: Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan That is, while there is value in the items on the…

나는 Bluetooth 기능을 담당하고 있다. 최근에 안드로이드 플랫폼이 이슈가 되는 것 같다. 지원이 필요한 것 같아서 잠깐 살펴볼 일이 있었다. Bluetooth SIG에서 찾아보니 현재는 HSP(headset profile)와 HFP(Handsfree profile)만 지원한다. 나머지 프로파일은 언제쯤 지원될까? 안드로이드에서 블루투스 기능 구조는 다음과 같다.

아이폰과 안드로이드를 보면서, 정확한 사실에 근거한 것은 아니지만, 막연하게 ‘대단하다’라는 느낌을 지울 수가 없다. 정말 SW를 잘하는 회사들이 해낼 수 있는 역작인 것 같다. SW의 부품을 만들고 표준화를 진행하고 SDK를 만드는 일들에 적지 않은 시간을 보내면서 그 작업이 얼마나 쉽지 않은 작업인지를 경험상 이해할 수 있기 때문에 더더욱 동경에 가까운 느낌을 받는 것 같다. 일종의…

아래와 같다고 하네요. 선언 시: int function (int a, int b) 에서 a 와 b는 parameters 호출 시: function(11,2) 에서 실제 넘어가는 값은 11과 2는 arguments

코더니 아키텍트니 하는 주제로 많은 이야기들이 오가는 것을 보았다. 나는 코더라는 말을 쓰지 않았으면 좋겠다. 개발자를 폄하할 때 사용되는 경우가 너무 많다. 이런 주제로 여러가지 글들을 찾아서 읽어보긴 했는데 아쉽기만 했다. 코더라는 말을 쓰기엔 시대가 변한 것 아닌가 한다. 아래 그림에서 코드를 꼽고 있는 사람이 코더란다. 요즘 시대엔 코더는 없다. 이것 저것 찾아서 읽어본 글들

소프트웨어 개발을 잘 해보려는 생각이 없다면왜 인생을 그 일을 하면서 보내는가?–  실용주의 프로그래머 TIP 70 중에서 직설적이고 도발적이며 마음에 와 닿게 하는 말이다. 나는 컴퓨터를 좋아했고 컴퓨터를 전공했으며 지금까지 이 바닥에 있다. 그런데 나는 즐겁지 않고 행복하지 않으며 재밌지 않다. 정말 이 일이 나에게 맞지 않는 것일까? 나의 인생 전반에 걸쳐 내 생각과 사고 방식을…