▣ 개발관련 이슈 - 해당되는 글 16건
출처 : http://www.bloter.net/archives/62883
세계 모든 미디어와 수많은 IT 업체들의 이목이 미국 샌프란시스코 모스콘 센터에 쏠렸다.
얼마 전 그곳에선 구글이 전세계 개발자를 대상으로 세미나를 개최했다. 뒤이어 애플이 6월 6일부터 10일까지(현지 기준) ‘개발자 컨퍼런스(WWDC) 2011′을 개최하고 있다.
많은 이들이 예상했던 대로 애플과 스티브잡스가 ‘아이클라우드(iCloud)’라는 개인용 클라우드 컴퓨팅(PCC) 서비스를 들고 나왔다. 언제 어디서나 인터넷에 접속하기만 하면 저 ‘구름 뒤편’의 데이터센터에 저장된 콘텐츠들을 실시간으로 활용할 수 있게 하겠다는 것이다. 물론 애플이 제공하는 운영체제를 탑재한 기기에 한 해서지만.
iOS5는 그동안 안드로이드 진영에서 선보였던 기능들을 대거 차용한 느낌도 든다. 서로가 닮아가고 있다. 앞서거니 뒤서거니 하면서 혁신의 경쟁을 하고 있다.
누구나 안다. 클라우드가 대세라는 걸. 하지만 경쟁업체들은 애플이 무슨 카드를 꺼내 들 지 알면서도 매번 당하기 일쑤다. 갑자기 궁금해졌다. 왜 그럴까?
한가지 생각이 떠올랐다. 애플이나 스티브잡스는 일반인들의 생활 자체에 무척 많은 관심을 기울이고 있다는 걸. 애플은 단순히 기기를 출시하는 것이 아니다. 그 기기를 통해서 그동안 복잡했거나 어려웠던 과정들을 깔끔하게 정리하고 편리함을 제공한다. 소비자들에게는 편리함을 주고 자신의 파트너와 개발자들에게는 새로운 수익을 얻을 수 있는 플랫폼을 제공한다.
애플의 행보는 이를 여실히 보여주고 있다. MP3 플레이어를 출시할 때도 애플은 후발주자였다. 하지만 불법복제에 시름하던 저작자들에게 아이튠즈를 통해 소비자들에게 다가설 수 있는 통로를 열어주고 동시에 수익을 보장해 줬다. MP3 플레이어를 가장 먼저 만든 우리나라 제조업체들은 이런 쪽에는 별다른 관심을 기울이지 않았다. 워크맨의 대체제로서만 제품을 출시했을 뿐이다. 기존의 선발업체를 꺾는데는 성공했지만 새롭게 선점한 시장을 지속적으로 이끌어가는덴 실패했다.
애플이 스마트폰을 들고 나왔을 때도 마찬가지였다. 수직 계열화된 통신시장의 구조를 제조사, 통신사, 개발자, 소비자들이 나란히 설 수 있도록 수평하게 만들어 버렸다.
아이패드는 또 다른 시장을 겨냥했다. 바로 출판분야다. 아이패드가 출시되기 전까지 PC나 노트북, 태블릿들은 생산성 향상이라는 분야에 초점이 맞춰져 있었다. 하지만 아이패드는 처음으로 ‘소비형 기기’라는 타이틀을 거머쥐면서 전혀 새로운 시장을 만들어 냈다. 출시 초기 IT 블로거들이 이런 저런 기능이 빠졌다며 손가락질하기도 했지만 아이패드는 보란듯이 성공했다. 연달아 내놓은 아이패드2는 없어서 못 팔 정도다. 가격까지 낮췄다.
애플은 초기 애플TV의 실패에서 경험한 탓인지 10만원짜리 셋톱박스를 통해 새롭게 방송 콘텐츠 시장에도 들어왔다. 많은 방송 사업자들은 음반 업체들이 애플에 목덜미를 잡혔다고 보고 처음엔 적극적으로 동참하지 않았다. 하지만 이들은 이미 아이패드에 여러 형태로 지원을 해왔었다. 애플은 에어플레이를 통해 무선랜으로 연결된 기기들간에 음악과 영상을 손쉽게 주고 받을 수 있도록 했다. 사용자들이 관련 기능을 쓸 때 번거롭게 이것 저것 설정하지 않아도 되도록 했다. 같은 기술을 만들어 내는데 누구는 아주 어렵게 다가가는 반면 애플은 손쉽게 활용할 수 있도록 한다.
애플TV에 콘텐츠를 제공하지 않았더라도 아이패드 앱 마켓에 들어와 있는 영상들은 소비자들이 손쉽게 애플TV와 연동시켜 대화면에서 즐길 수 있도록 했다. 과정도 무척 간편하다. 국내 가전 업체들이 홈네트워크표준인 ‘DLNA’를 통해 관련 기기들을 연동할 수 있도록 했지만 대중화에는 실패했다. 일반 사용자들이 이용하기에 어려웠기 때문이다. 혹자는 말한다. 그게 뭐가 어렵냐고. 그럼 이런 반문은 어떨까. 왜 먼저 만들어놓고 한참 뒤에 나온 애플의 에어플레이보다 더 많은 생태계를 만들어 내지 못했느냐고.
최근 만난 업계의 한 관계자는 이런 차이에 대해 “애플은 사용자들에게 어떤 서비스를 어떻게 전달해야 손쉽게 활용할 수 있는 지 미리 생각을 해 놓고 그 다음 기술을 적용하니 확산도 빠른 것 같다”면서 “이에 비해 우리나라 업체들은 이런 소비자 관점보다는 엔지니어들이 활용 가능한 기술을 조합해 제공하는 데 익숙하다. 그러다보니 사용성이 떨어진다. 서비스를 기획하는 단계부터 이런 차이가 발생하는 데 실제 사용에서는 너무나 큰 차이가 나타나는 것 같다”고 말했다.
얼마 전 우연히 또 다른 이야기를 들었다. “내 친구 중 가수가 있다. 500원짜리 음원이 하나 팔리면 그 친구에게는 3.8원 정도가 떨어진다. 이게 우리나라 생태계의 현실이다. 만약 우리나라 가수들이 대거 아이튠즈를 통해 음원을 유통하게 된다면 어떤 일이 벌어질까. 현재 시장을 장악한 통신사들이나 인터넷 음악 서비스 회사들을 외면하고 해외 플랫폼을 쳐다보고 있는 이런 현실에 과연 우리나라 제조사들은 제대로 관심을 가져봤을까”라고.
세계 최고의 가전 제품을 만들면서도 서로 다른 기기들을 엮기 위한 플랫폼을 얼마나 유연하게 만들어 외부 개발자와 다른 파트너들에게 공개했느냐고. 이 분야는 익숙하지 않은 분야다. 그냥 돈주고 협력사를 소싱해서 서비스를 만들어 내는 방식으로는 더 이상의 부가가치는 물론 기존 시장유지도 어렵다는 걸 우리나라 최고 경영진들은 아직까지 제대로 인식하지 못한 것 같다.
쉬어야 할 주말에도 총괄 임원이 출근해 “왜 저 부서에는 사람들이 없지?”라고 한마디 하고 돌아가는 것이 최고의 업무독려인 줄 안다.
가정을 포기하고 앞만 보고 달려온 우리네 최고 경영자들은 자신의 주위를 둘러보면서 살아올 여유가 없었다. 오직 경쟁사를 주시하며 앞만보고 뛰었다. 당연히 성적표가 중요했다. 자신이 만든 혹은 자기 회사가 만든 제품을 가지고 아내가 혹은 자식들이 어떻게 사용하고 무엇을 어려워하는 지 돌아볼 여유가 없었다. ‘먹고 살만큼 줬으면 됐지 뭘 또 바라냐. 지네들이 누구 때문에 그나마 먹고사는데’라며 협력사를 바라봤던 인식은 요지부동이다. 아무리 ‘상생’을 강조하는 시대가 도래해도 말이다.
도대체 뭘 어쩌라는 거냐는 말 밖에 달리 할말이 없다.
기업의 최고 수장들은 입만 열면 상생을 이야기하지만 연말이 되면 실적에 따라 평가한다. 당연히 협력사를 쪼아서 그들에게 비용을 전가시킨 곳들이 수익이 좋다. 수익이 좋은 곳이 오히려 협력사를 쪼으고 옥죄었다는 평가는 온데 간데 없다. 최고 경영진들의 상생 발언이 관련 시장에 전혀 먹혀 들어가지 않는 구조다.
언제 이 세상을 떠날 지 모를 잡스가 천착해 온 것들은 무엇일까. 전혀 다른 산업에 대한 관심과 사람에 대한 관심. 모든 걸 엮어 내는 핵심에 집중하고 나머지는 개방하면 더 큰 생태계를 만들어 낼 수 있다는 사실이다. 잡스도 초기에는 몰랐을 것이다. 잡스가 애플에서 쫓겨나지 않았다면 지금의 혁신들을 쏟아낼 수 있었을까. 그렇다면 우리나라 경영자들을 억지로라도 일정기간 회사 근처에 얼씬도 못하게 하고 집에서 시간을 보내도록 하는 것도 방법일 지 모르겠다.
대부분의 개발자 행사는 미국에서 개최된다. 소프트웨어 생태계를 만들어 내는 데 성공한 회사와 나라는 많지 않다. 최고의 벤처 생태계가 만들어 진 곳이 미국과 이스라엘외에 찾아보기 힘든 것처럼 소프트웨어 생태계를 만들어 내는 건 그리 호락호락한 일이 아니다. 익숙함으로부터의 탈출없이 혁신은 존재하지 않는다.
WWDC 2011 첫 날 선보인 아이클라우드는 아주 손쉽게 활용할 수 있는 편리함이다. 그 편리함을 이제 우리나라 제조사들로부터도 받고 싶다. 아마도 잡스가 제시한 이 길을 따라잡기 위해 우리나라 각 기업의 실무 담당자들과 엔지니어들은 또 한번 철야 작업에 내몰릴 지 모를 일이다. 아이클라우드를 보면서 멋지다라는 생각을 잠시 한 후 그들을 추격하기 위해 또한번 거센 업무 현장에 투입돼야 하는 이들의 얼굴이 떠오른다. 이들은 또 한번 가정을 포기하고 업무에 투입될 것이다. 워크 스마트를 강조하지만 그렇게 해본 적 없는 국내 제조사들의 경영진들이 변하지 않는 한 지속적인 혁신은 불가능해 보인다.
남의 잔치가 열릴 때마다 입맛이 쓰다. 몇년 간은 이런 씁맛을 계속 보게 될 것 같다.
프로그래밍 영웅과 독불장군
출처 : 'Professional 소프트웨어 개발' , 스티브 맥코넬
부족한 기술 인력과, 너무 낙관적으로 일정을 잡는 일반적 성향을 더하면 어떤 일이 일어날 것 같은가?
그렇다. 이제는 일당백의 능력을 가진 프로그래밍 영웅(programming hero)을 말할 차례다.
프로그래밍 영웅은 항상 자기 능력을 시험해 볼만한 일을 선택하고, 어마어마한 코드를 써 나간다.
그런 사람은 대부분 야근을 밥먹듯 하고, 곧 프로젝트에서 절대로 빼놓을 수 없는 사람이 된다.
성공은 그들의 어깨에 달려 있는 것 같이 보인다.
프로젝트 관리자는 이 영웅 프로그래머를 사랑하지만, 두려워하기도 한다. 그들은 똑똑하지만,
성미가 까다롭고 독선적인 성격인 경우가 많다. 그러나 그들이 없는 프로젝트 수행은 상상할 수 없다.
수급 불균형 노동 시장에서 그들을 대체하는 것은 절대로 선택 사항이 아닐 것이다. 그러나 안타깝게도
엄청난 양의 코드를 뽑아내는 능력이 있는 대부분의 프로그래밍 영웅들은 다른 사람들과 같이 일하는
방법을 모른다는 치명적인 요소가 있다.
이런 사람들은 대부분의 설계 정보와 소스코드를 자기만 볼 수 있도록 숨겨놓고, 테크니컬 리뷰
(technical reviews)에 참여하는 것을 거부한다. 또, 팀이 정해 놓은 표준을 따르지도 않는다.
이러한 행동들은 결국 다른 팀원들의 프로젝트에 가치있는 공헌을 할 수 있는 기회를 박탈하게 된다.
많은 프로그래밍 영웅들은 결국 전혀 영웅이 아니다. 그들은 단지 프로그래밍 독불장군일 뿐이다.
개개인의 탁월한 능력이 프로젝트 성공에 큰 영향을 미칠 수도 있지만, 일반적으로는 팀워크가 더
큰 영향을 미친다. IBM의 연구에 의하면 평균적인 프로그래머는 약 30%의 시간만 혼자 일하는
데 보내고,나머지 시간은 팀 동료나 고객 같은 다른 사람들과 같이 일하는데 쓴다.
31건의 소프트웨어 프로젝트들을 조사한 결과, 전체 생산성에 가장 큰 영향을 미치는 요소는
바로 팀의 융합이라는 것을 알 수 있었다. 물론 개개인의 능력도 생산성 증가에 공헌하지만, 팀 융합이
더욱 큰 힘을 발휘한다. 많은 사람들이 자신의 능력을 더 높일 수 있는 도전적인 프로젝트에 참여하고
싶어한다. 그러나 자신의 한계를 테스트하려는 의지가 있고 효과적인 소프트웨어 개발 지침들을따르며
지속적으로 동료와 협업하는 사람만이 진정한 프로그래밍 영웅이고, 프로젝트에 참여할 자격이 있다.
포스팅 출처 : http://kldp.org/node/43548
=======================================================
우연히 이 글을 보게 되었는데요. 느끼는 점이 많아 함께 공유하고 싶었습니다.
대학교때 진행했던 프로젝트나 현재 회사에서 하는 프로젝트들을 돌이켜볼때 혹시라도
나 자신이 독불장군은 아니었나 말입니다.
대학교때 실버라이트 프로젝트를 시작할때 팀원들의 프로그래밍 실력은 제각각이었긴 했지만
팀원모두 실버라이트에 대해 잘 모르고 있었기때문에 같은 선상에서 시작하겠구나 생각했습니다.
어찌보면 모험이었지만 한번 해보자는 분위기로 시작했지요.
저의 경우엔 팀장이란 역할을 맡고 있어서 밤새 MSDN과 씨름하고 들리지도 않는 영어로 된 동영상
강의를 보면서 스킬을 하나 둘 익혀나갔습니다.
하지만 시간이 지나면서 알게 모르게 프로젝트 전체에 대한 저의 비중이 커지기 시작했습니다.
그리고 팀원들은 실버라이트를 어렵게 느끼기 시작했으며, 점차 흥미를 잃어가는 것이 보였습니다.
다만 몇몇만이 지금까지 완성된 코드를 보며 힘겹게 따라오는 듯한 느낌이 들었지요.
테크니컬 리뷰를 더욱 자주 하고 싶었지만 어떻게 해야 효율적인지 잘 몰랐고, 후반부에는 바쁜 일정에
쫓기다보니 성과 없는 리뷰의 효율에 대해 의심이 들기 시작했습니다. 또한 많은 양의 코드를 뽑아내는데는
익숙했지만 다른사람들과 같이 팀웍을 한다는게 아직은 어렵게 느껴지기 시작했습니다.
돌이켜보면 비록 프로젝트 결과는 성공적으로 마쳤을지 모르지만 프로젝트 과정은 실패했다고 생각합니다.
대학교 프로젝트라서 그렇겠지.. 했지만.. 문제는 그 다음 프로젝트에서도 반복되는 것 같다는 점입니다.
일단은 자바 개발 경험이 있는 사람이 적은 상태에서 자바로 프로젝트가 시작되었고, 도메인 역시 생소하긴
했지만 일정상에는 기간도 길고 문제가 없어보였습니다.
그러고보니 위의 글에서 첫 문장의 조건이 되는군요..
"부족한 기술 인력과, 너무 낙관적으로 일정을 잡는 일반적 성향을 더하면 어떤 일이 일어날 것 같은가?"
구현단계에 오니 문제점들이 드러나기 시작했습니다. 디자인할때 인식하지 못했던 구현상의 문제들을 해결하거나
좀더 효율적으로 처리하기 위해 많은 알고리즘들이 삽입되고 패턴들이 적용되었습니다. 그러다보니 디자인때보다
더 많은 클래스들이 생겨나고 복잡해 보이기 시작했습니다. 저는 그 당시 뛰어난 아키텍쳐의 부재를 아쉬워하며..
이렇게 해야 확장이 쉽고 유지보수에 좋습니다. 라는 말로 설득시켜 모든 짐을 지고서 팀을 끌고왔습니다.
그때그때 팀원들의 이해를 돕기위해 많은 PPT를 준비하고 코드리뷰에도 적극적으로 참여했습니다만
문제는 언제부터인가 제가 전체 프로젝트의 80%이상의 코드를 손대고 있고 팀원들이 제 코드중 핵심 코어부분을
블랙박스라고 부르는데 있습니다.
위 글 중 영웅이고 머를 떠나서 '자기 능력을 시험해 볼만한 일을 선택하고, 어마어마한 코드를 써 나간다' 라는
말에 동의는 합니다만 제가 성미가 까다롭거나 독선적이진 않습니다. 또한 공유는 저의 일상생활이구요.
그리고 기술적인 토론을 좋아하고 언제든지 피드백에 제 자신을 채찍질 할 준비가 되어있습니다.
다만, 팀워크와 관련된 결정에 있어서 딜레마에 빠질까봐 걱정이 됩니다. 그리고 혼자 너무 많은 일을 맡으려
하는 성격(다른사람에게 일을 막 못시키는)도 협업을 할때 풀어야할 과제가 아닐까 생각해봅니다.
그리고...
훌륭한 Co-worker로서.. 또는 Leader로서 필요한 자질은 무엇인지 의견을 부탁드립니다. ^^
출처 : http://hoons.kr/board.aspx?Name=Free&BoardIdx=28609&Page=1&Mode=2
출처 : http://blog.naver.com/seogi1004?Redirect=Log&logNo=110076487990
개발자라면 OOP라는 것을 최소한 한번은 들어봤을 것이다.
이 OOP라는 개념이 나온지가 거의 수십년이 되었고 하나의 트렌드로 잡혀서 실제 프로그래밍에 적용된지도 20년 가까이 되었다.
객체지향프로그래밍을 적극 반영한것이 Java, C++, Object pascal, PHP등등..
이젠 OOP를 언어차원에서 지원하지 않으면 안되는 세상이 됐다.
물론 OOP보다는 절차적 프로그래밍이 중요하게 사용되는 부분도 여전히 많기는 하지만 어쨌든 한참 예전부터 대세는 OOP였다.
그런데 이런때 일반 상식이 된 OOP를 들먹이는 이유가 있다.
OOP를 못하는 개발자자는 개발자의 적이다.
coding의 기본 틀은 빠른 속도? 짧은 코드? 아니다. 다른 개발자가 보기 쉽고 깔끔하게 정형화된 규칙으로 모듈화 된 것이다.
타인이 얼마나 빠른 속도로 이미 짜여진 코드에 빨리 적응할 수 있느냐가 그 코딩이 잘되어 있느냐 못되어 있느냐를 결정짓는다.
근데 OOP가 아닌 절차적 프로그래밍이나 OOP를 잘 지키지 못한 소스의 경우 개발한사람도 유지보수때 힘들겠지만
이후 유지보수에 들어가는 다른 개발자들은 정말 죽고싶은 충동이 날정도로 힘들게 만들어버린다.
기능 하나 추가 하려면 여기저기 다 뜯어 고쳐야 하고, 버그 하나 수정할때마다 사방에서 발생하는 side effect를 처리 해야 하고
아무리 잘된 문서가 있더라도 소스를 이해 하기 힘들다.
짜놓은 개발자 조차도 결국은 수정 못하고 다 뒤집어 엎기도 한다.
유지보수와 프로젝트 후반부에 가서는 OOP가 아닌 개발방법론은 개발자에게 독이되어 돌아오고 수많은 유지보수 이슈와 요구사항변경을 땜질하기 힘들어져서 개발자를 지치게 만든다.
아직도 많은 개발자들이 OOP에 대해서 많은 오해를 하고 있다.
몇가지 예를 들고 설명해보고자 한다.
1. 무조건 class만 사용하면 OOP이다.
OOP란 하나의 프로그래밍 방법론이다. 문제를 얼마나 효율적인 단위로 객체(모듈)화해서 개발자로 하여금 좀더 개발하기 쉽게
만들고 문제가 발생했을때 그 문제의 해결 범위를 축소시켜 기타 side effect를 최소화 하는 것이다.
그렇게 본다면 자바나 C++등의 class라는 예약어를 사용한다고 해서 무조건 OOP일까? 절대 아니다.
필요 없는 부분까지 class로 만들고 함수 한두개만 만들면 되는 상황인데 OOP랍시고 무조건 class로 만들고 객체를 생성시키게
만든다면 전혀 의미가 없다. 또한 효율적인 객체단위로 나뉘지 않고 이문제 저문제가 한꺼번에 다 들어있는 객체, 혼합되어
어떤 부분에 쓰일지 알수 없는 class등은 절대 객체지향이 아니다. 오히려 그런 class하나때문에 다른 많은 부분까지 수정을 해야 할
수도 있다. 착각하지 마라. class썼다고 자신이 OOP를 잘하고 있다는 생각은 위험하다.
"class란 OOP의 가장 기본적인 단위이며 Data와 Method(Function)의 집합체이다." 이걸 꼭 기억하자.
2. C언어 등에서는 OOP가 사용불가능하다.
OOP의 의미를 모르는 사람들이 하는 소리다. OOP란 기능이나. 절차를 모듈화하는 것이다. 다시 말해서 구현 범위를 기능 단위로
쪼개서 나눠 놓고 문제의 발생 범위를 축소 시키는 것이다. 쉽게 자동차 생산을 생각하면 될것이다. 조향장치, 전체 프레임, 엔진, 배기
시스템, 연료 공급부분 등 자동차에 고장이 발생했을 경우 해당 부품만 교환하거나 고치면 차는 문제 없이 작동한다.
소프트웨어 또한 마찬가지다. 그렇게 본다면 C언어를 통해서 개발할때도 이런 식으로 나눠놓는다면 OOP가 안되겠는가?
3. OOP를 하면 개발 속도가 늦춰진다.
초기 가시적인 개발 속도는 OOP가 늦다고 할 수도 있다. 하지만 구조적 프로그래밍을 하면서 초기에 빨리빨리 개발 되는 것처럼 보이
지만 OOP의 초기 모듈화 구축 단계를 넘어가게 되면 OOP가 훨씬 빠르다. "잘 개발된 프레임웍 한개, 열 코더 안부럽다" 라는 말을 하
고 싶다. 구현하는 곳마다 똑같은 일을 반복해서 구현 해줘야 하는것과 초기에 한번 잘 구성해놓고 이후부터는 엔진단에서 자동으로
작동한다면 어디가 더 빠르겠는가? 개발 후반부에 요구사항이 추가되거나 수정되면 그것을 적용할때 구조적 프로그래밍은 그걸 반영
하기 너무 어렵거나 아예 불가능 할 수도 있다. 하지만 OOP는 간단하다. 심지어는 구조적 프로그래밍의 경우 3일 걸릴것 3분만에 끝낼
수도 있다. 소프트웨어 개발의 대세는 유지보수의 편리성이다.
4. OOP를 하면 프로그램 크기가 커진다.
아니라고 할수도 없고 꼭 그렇다고 할 수도 없다.
만약 정말 작은 기능을 하는 프로그램이 있다면 굳이 OOP의 구현 프레임웍을 얻는 것보다 차라리 구고적 프로그래밍으로 하는 것이
프로그램 크기는 작아 질것이다. 하지만 프로그램이 일정 범위이상 넘어가게 된다면 애기는 완전히 틀려진다. 100개의 Page를 개발하
는 프로젝트에서 OOP로 하지 않는다면 100개 모두에 같은 동작을 코드로 넣는다면 OOP의 프로그램크기가 훨씬 작다.
6. OOP를 하면 프로그램 속도가 늦다.
처리 단위를 함수 하나로 하고 switch case문으로 처리 하는 것에는 당연히 함수 포인터가 이리저리 불리고 하는 OOP보다는 빠를 것
이다. 하지만 이미 시스템이 고속화 되고 폰에서도 3D게임이 돌아가는 현실에서 사용자가 체감하지 못하는 그 작은 속도의 차리때문에
인력과 시간을 낭비할 필요는 없다고 본다. 결론은 그런식의 처리보다야 약간 늦기는 하다.
7. OOP를 사용하려면 엄청난 설계 기술이 있어야 한다.
사고를 어떻게 하느냐다. 문제를 보고 문제의 세부 구현 단위를 작게 쪼게서 볼수 있느냐와
뭉퉁그려서 한번에 그 모든것을 한곳에서 다 처리 해야 한다는 것의 차이이다.
개념만 살짝 바꾸면 전혀 어렵지 않다.
8. 상속깊이가 깊으면 멋진 OOP이다.
OOP를 처음 배우는 개발자들의 일반적인 오류인데 절대 그렇지 않다. 한때 프레임웍들의 상속구조가 깊고
복잡한것이 유행했었다. 하지만 그렇게 될경우 개발자들이 그 프레임웍을 이해하는데 오래 걸리고 쉽고 유
연하게 사용하기 힘들다. 상속이 너무 두꺼울 경우 수정 이슈가 있을때 수정하기 어렵고, 작은 기능을 하나
수정하기 위해서 많은 이해를 필요로 한다. 필요한 부분들만 간결하게 Class화하고 상속또한 가볍게 한것
이 멋진 OOP라고 할 수 있다.
안녕하세요
강용천입니다.
과장 밑으로 저와 같이 일했던.. 같은 부서원이었던 직원이 현재 12명이나 되군요.
정말 하나같이 모두 착하고 좋은 사람들인 거 같습니다. 저만 항상 모니터에 인상 쓰고 있으며 재미없는 못난 사람이지만..^^
제가 이씨오에서 얻은 게 있다면 당연 이분들일 겁니다….물론 회사에서 받는 금전적인건 빼고
지금까지 뻘소리였구요.. 그냥 보면 좋을 거 같은 영상이 있어 링크 걸어 드립니다.
내용이 리더의 리더십 이런 내용이라고 현재 저의 PM님들에게 이랬으면 좋겠다 뭐 그런 소리는 아닙니다..
전 PM님들을 사랑하고 특히 박책임님은 저의 리더라는걸 자랑스럽게 생각합니다. 아부인가요? 아부라고 생각하면 뭐 어쩔 수 없죠..ㅎㅎ
오래 전부터 알고 있던 사이트인데요. 정말 멋진 강연이 많습니다. 시간 나면 한번 보세요.
멋진 강연이 즐비한 TED에서 자막서비스와 함께 각국 언어 번역 프로젝트가 시작된 지 꽤 되었습니다.
이제 한글자막이 나오는 토크가 125개나 되니, 영어울렁증이 있는 분들도 이 멋진 강연들을 즐길 수 있겠네요.
TED 토크 중 'Itay Talgam: Lead like the great conductors | Video on TED.com ' 이라는 토크를 보고
감명을 받아서...... 생략
http://www.ted.com/talks/lang/kor/itay_talgam_lead_like_the_great_conductors.html 여기로
[출처] 처음해보는 TED 번역 리뷰|작성자 박형근
유명한 오케스트라 지휘자들의 지휘스타일을 비교하면서,
리더의 리더십에 대해 생각해 보게 해주는 명 강연입니다.
