설계와 코드는 별개다..?
제 주위에는 SE(Software Engineering)을 하시는분들이 많습니다.
일단 저희학교에는 SE 교수님이 4분 계십니다. (국내 대학에서는 가장 많다고 들었습니다. 맞나..;; )
자연스럽게 그쪽 연구실 사람들도 많지요
그런데 하나같이 말씀하시길..아니 강조..(? 주장) 하시길
코딩은 하지 말아라 입니다.
그거 해봐야 평생 남 딱갈이 밖에 못한다는거죠.
그 위에 있어야 한다는 말인듯 싶습니다.
그럼 설계자(Architect?)는 프로그래밍을 못해도 된다는 말이냐고 반문했더니
필요없답니다.
실제로, 저희학교 컴퓨터 학부에서는 코딩을 거의 않해도 졸업및 학위가 가능합니다.
또한, SE Lab (그쪽 연구실 사람들의 말에 의하면)에서도 코딩을 전혀 않해도 된다는 겁니다
오히려 랩실에 들어가기전에 코딩을 잘했던 사람들은 너무 않해서 못하게 된다는군요.
저또한 프로젝트를 할때 여유있는 기간을 잡아놓고 요구 명세및 시스템 설계를 문서화 합니다.
디버깅도 이왕이면 코드레벨에서보다는 설계레벨에서 하려고 노력합니다.
하지만 제가 시스템 설계를 할때 어려운것은 What 과 How 입니다.
A라는 Component에 대해 What을 정의하기는 쉽지만
How를 정의하기에는 알아야 할것들이 많이 있습니다. (아니라면 근거있는 반론 부탁드립니다.)
혹은 설계자 입장에서 프로그래머(혹은 코더)에게 시킬때에도 What 과 How 를 잘 섞어서 알려줘야
원하는 결과물을 얻을수 있다고 생각합니다.
여기서 제가 말씀드리고 싶은것은 코드레벨을 생각하지 않는다면 How 를 말해주기 힘들다는 것이지요.
그럼 여기서 이런 반론이 나올수 있습니다.
"Abstraction에 의해 What만 알아도 Relationship을 만들수 있으며 설계가 가능하다."
그럼 어떻게(How) 돌아가는지는 상관없고 What을 만족하기만 하면 된다. 라는 것인지 궁금합니다.
누구나 어느정도 하면 돌아가는 프로그램은 만들수 있다고 생각합니다.
하지만 아웃풋이 정확하다고 "좋은" 프로그램은 아니라고 생각합니다.
설계자는 코딩할필요 없다는 선배(석사, 박사)들의 말을 듣는 저로써는 무섭습니다.
그런 사람 아래서는 일하기 싫을것 같습니다.
물론 설계하시는 분께서 엄청난 고수시라면 말이 달라지겠지요.
제 실력은 아직 Primer이지만 나름데로의 생각을 적어보았습니다.
빈약한 부분도 있을것입니다. 이글을 읽고 관심있으시면 채워주시기 바랍니다.^-^
제가 학부때 가장 많이 듣던 소리가, 많은 코딩경험과 아키덱트를 잡으려는
제가 학부때 가장 많이 듣던 소리가, 많은 코딩경험과 아키덱트를 잡으려는 노력을 해야, 나중에 제대로 된, 아키덱처가 될 수 있다는 소리였습니다. 저희과 교수님들 왈 "코딩을 제대로 많이 안해본 사람들은 결코, 제대로된 설계를 할 수 없다였는데" 음냐, 저도 저희 과 교수님 말씀에 찬성을 쿨럭, 고운 하루되세요.
=========================
CharSyam ^^ --- 고운 하루
=========================
내공이 없이 초식만 익히는 격이 되지 않을까요?
내공이 없이 초식만 익히는 격이 되지 않을까요?
설계만으로 힘든 부분이 있습니다.
설계와 코딩은 서로의 보충관계에 있다고 생각합니다.
실제 코딩을 해보지 않은사람은 인간적인 사고에 근접해서 설계를 하게 되고, 이는 시스템의 동작 측면에서는 상당히 비효율적인 동작이 예상 됩니다.
코딩만 잘한다는것도 문제가 되는것은 부분적으로는 아주 원할한 구성이 되지만 전체 시스템적인 관점에서는 이또한 부드럽지 못한 제작이 되어 필요없는 스펙이나 개념이 적용될수 있기 때문입니다.
설계의 방법론 또한 실제 코딩을 해보지 않은 사람이라면 기존에 명시된 표준적인 설계를 사용하겠지만, 둘을 같이 해본사람은 표준설계에서 응용되어 프로젝트에 적합한 설계의 방향으로 바꿀수 있습니다.
코딩을 안해본 사람이라면 설계를 아무리 잘 했다 하더라도 코딩하는 사람이 이러저러해서 못한다고 하면 두손두발 들고 설계를 바꿔야 합니다. 하지만 코딩을 해본 설계자라면 정확한 시스템의 방법까지 알고 있기때문에 어거지성 코드너의 이야기에 솔깃하지 않을수도 있습니다.
현실적인 얘기로 바꾸면,
우리나라에서는 대부분의 회사에서 설계자를 원하지 않습니다.
제작자가 코딩과 설계를 겸합니다.
특히 처음 입사를 하면 코딩이 되지 않으면 당장 저라도 이사람을 왜 뽑았는지 의구심이 생깁니다.
코딩은 기본입니다. 거기에 설계까지 잘하면 금상첨화입니다.
Re: 설계만으로 힘든 부분이 있습니다.
제 생각은 좀 다릅니다. 물론 신입의 경우라면 코딩을 할 줄 모른다면 왜 뽑을지 의구심이 들겠지만, 규모가 큰 회사일수록 코더보다는 설계가 가능한 인력을 더 원할 겁니다.
소림사 주방장은 원래 물긷기 삼년부터 시작하지 않던가요?
소림사 주방장은 원래 물긷기 삼년부터 시작하지 않던가요?
규모가 큰회사는....
규모가 큰회사는 MS 가 아닌 국내 회사에서는 아웃소싱을 합니다. :lol:
지금 회사를 옮긴지 만 4년이 넘었습니다.
그전 회사에서 설계 방법 및 나름대로의 기법을 정립하고 회사를 옮겼습니다. 옮긴 이유가 다른곳에는 어떤 문제를 어려워하고 어떻게 풀며 향후 내가 팀 리더가 되면 어떻게 하는게 가장 현명한지를 알고 싶어서였습니다.
그래서 그나마 생각컨데 조금 큰회사 ( 우스개로 대기업이라는 이야기도 하지만 ) 로 옮겼습니다. 그런데, 다른건 접어두고 설계라는걸 아예 하지를 않고 있다는 겁니다. 즉, 회사가 큰것과 설계를 확실히 한다는것은 전혀 관계가 없는것 같습니다.
주변에 여러 컴쟁이들에게 물어보아도 처음회사에서 하던 설계의 절반도 하지 않더군요.
신입을 뽑으면 설계를 시키지 않고 코딩을 먼저 시키는것은 현장 경험을 쌓게하여 설계서에 있는 내용과 현장감을 동시에 가지게 하기 위함입니다. 그런데, 코딩을 못한다면 어떻게 해야 할까요? 회사는 영리 추구 단체입니다.
설계에 대한 지식은 구현을 한 경험에서 나오는거라고 믿고 있습니다.
설계에 대한 지식은 구현을 한 경험에서 나오는거라고 믿고 있습니다.
구현을 고려하지 않은 설계는 의미가 없구요.
( 탁상공론 하는거 밖에 안되요 )
좋은 설계는 "구현이 쉬어야 한다" 조건도 포함된다고 생각합니다.
만약에 설계와 구현이 별개라고 하면
코딩은 한줄도 해보지 않았지만 설계를 잘하는 사람이 있어야 하는데
그런 사람이 있을지 의문입니다.
웬만큼 큰 어플리케이션 ( , 프레임웍 ) 이 아니면
구현과 설계는 동시에 이루어지는 것 같습니다.
..
코딩경험이 없어도 설계는 할 수 있습니다.
훈련만 쌓으면 얼마든지 할 수 있습니다.
20대의 나이에 설계 이력 화려한 사람들 많이 있잖습니까?
모두는 아니겠지만 이런 케이스라고 할 수 있겠죠.
근데 이것을 잘 할 수 있느냐는 의문입니다.
외국의 아키텍트들중에서 코딩못하는 사람을 본적이 없는것 같은데요..
어쨌든 설계만 할 줄 아는 사람하고는 일하기 싫구요.
다른 사람의 위에 서기위해 설계를 한다?
정말 엽기적인 발상입니다. 그 lab 문제가 있군요.
학원이 아닌 대학교가 그런 발상을 하다니 참으로 한심할 지경이군요.
How do you define Real?
[quote="sozu"]"Abstraction에 의해 What만 알아도
대부분 What은 알고 있지 않던가요?
물론 처음 시작은 What 이겠지만, 그것을 구성하기 위해선 How는 필수불가결해집니다.
How를 모르면 어떻게 Engineering이라고 할 수 있는지 모르겠습니다. -_-;
Science라면 이해가 되지만, Engineering에서 How를 모른다는 것은,
곧 공학을 포기하는 것과 같은 행위같습니다. -_-a
코딩처럼 재미있는거를 왜 안할까요..설계를 하다보면 코딩을 해서
코딩처럼 재미있는거를 왜 안할까요..
설계를 하다보면 코딩을 해서 돌려보고 싶은 마음이 마구마구 샘솟지 않을까요?
... 거대한 엔터프라이즈급 설계라면 모르겠지만요...
여하튼 요즘 커널에 들어갈 메모리 관리 부분을 고민하는데요
설계도 재밌고 또 설계한대로 만들어서 돌려보는 것도 재밌습니다.
헉.. oops 주제와는 전혀 딴 소리였습니다.
...
그런 사람들이 있으니, 그런 황당한 설계들이 프로젝트 할 때마다 나오는군요.
알만합니다.
Rapid Development 등의 명서로 PM 으로 유명한 Steve
Rapid Development 등의 명서로 PM 으로 유명한 Steve McConell 도 예전에는 Code Complete 같은 불후의 명서를 저술하였었습니다.
그리고 10년이 지난 지금 2d Edition 을 저술중입니다.
PM 으로 완전히 돌아서서 더이상 코딩따윈 하지 않을줄 알았던 Steve McConell 이 10년만에 코딩계의 명서를 재저술 하고 있다는사실에 적잖이 놀랐습니다.
뛰어난 설계자는 설계만 할줄 아는 사람이 아님이 분명합니다.
--
Sang-Kil Park
Re: 설계와 코드는 별개다..?
기본적으로는 프로그래밍을 못하는 경우라도 설계가 가능하다는데에는
동의합니다만,
프로그래머들이 말마따나, "딱갈이" (철자가 이게 맞나요?)고,
설계자가 그 위에 있는 것이라 생각하는 그 랩의 철부지같은 석박사들이라면,
단지 "설계는 가능하다"일 뿐이겠죠.
프로그래밍을 못하는 설계자라면, 프로그래머들과 교감하려 노력하고
모자른 부분에 대해 상호간 많은 대화가 필요할 겁니다. 위에 군림한다고
생각해서는 절대로 일 안될겁니다. 그래서 궁금한 것은 그런 석박사분들이
현업에서는 어떻게 일하고 있는지, 그 아랫사람들은 그런 분들을 어찌
생각하는지 입니다.
설계에 대한 식견이 비슷하다면 코딩을 할 줄 아는 사람이 훨씬 더
좋은 설계를 만들어낼 겁니다. 이건 너무 당연한 일이죠. 하지만, 개발에
능숙한 경우, 설계시 너무 개발 관점에 치우쳐버리는 경향도 무시할 수는
없다고 봅니다.
Orion Project : http://orionids.org
음, 코더의 입장에서 보자면...
뭐 이해가 안가는 바도 아닙니다.
흔히들 말하지 않나요? 코더와 프로그래머, 아키텍트 등등... 그 차이랄지...
진정한 의미의 아키텍트 보기 어렵다는 이야기도 합니다.
제 경험상 보면, 시스템이나 프로토콜을 설계하는 수준의 사람들은
정말 하늘의 별따기만큼이나 흔치 않습니다.
일례로, H.323을 구현하기 위해 국내 절대다수 회사는 스택을
그냥 사서 썼지요. 자체 개발한 회사는 단 한군데라고 들었습니다.
이건 implementation능력 이상의 것이 필요한 것이지요.
시스템이라는 측면을 놓고봐도, 어느 한쪽만 알고서는 도저히 설계가 안됩니다.
전체를 다 알고, 그 속성을 속속들이 이해하는 수준이 되지 않는다면 말이죠.
그 lab의 concept 나쁘지 않다고 봅니다.
모델링은 과제의 시작이자 끝이나 마찬가지입니다.
굳이 다른 사람의 위에 있고자 해서가 아니라, 그 포지션이 비어있는것이
작금의 우리나라 현실이구요.
사실 석박사로까지 degree가 올라가면서 코딩으로 학위따는건 아니지요.
업무에서 실제 코딩을 한다고 해서, 그것이 그사람이 하는 본업이고,
또 그것밖에 할줄 모르는 것은 아닌겁니다.
오히려, hierarchy의 밑에서 올려다보고, 위에서 내려다보고,
또 무에서 그 hierarchy를 만들어낼수 있도록 보간적 사고를 하는 노력은
비단 그 lab출신만이 아니라 모든 engineer들이 추구해야 하는바가
아닌가 합니다.
--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)
코딩이 필요없다 == 공돌이들 필요없다.SE만 있으면 된다 == 정책
코딩이 필요없다 == 공돌이들 필요없다.
SE만 있으면 된다 == 정책기획자들만 있으면 된다.
라고 생각합니다만...
SE만 해도 된다고 생각하는 그런 분들은 한치앞개그를 하신것으로 보입니다.
어느 학교인지가 그냥 궁금해지는군요. :wink:
어느 학교인지가 그냥 궁금해지는군요. :wink:
^^
많은분들이 답글을 달아주셔서
제 생각에 부족한 부분을 채워주신것 같습니다. 8)
-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com
흠.. 글쎄요..보통 전 engineer를 자처합니다만..
흠.. 글쎄요..
보통 전 engineer를 자처합니다만..
물론 저의 시작은 코더입니다.
하지만 약간은 이상론을 가지고 있는 편이라
무작적 코딩만 하지 않고 종이에 온갖 경우를 생각하며 설계를 하지요
틈틈히 내가 생각하는 how가 가능한가를 알아보기 위해 간단한 테스트용을 짜기도 하면서
보통 설계만 2~3달을 소요합니다.
그리고 코딩에 들어가고 뭔가 비효율이다 생각하면 다시 설계를 고치고..
특히 설계를 고칠 땐 여러사람의 의견을 듣는 편입니다.
"이 설계가 이런식인데 난 이렇게 할려고 한다. 근데 약간 맘에 안든다. 뭐 다른 좋은방법이 없을까.."하는 식으로요.
여러얘기를 듣다가 좋은 해법이 떠오르기도 하죠..
즉 요는 전 엔지니어입니다만 보통 업무를 할당하는 입장에선 설계도 해주지 않고 what을 해라고만 알려주기 마련입니다.
제가 설계도 하고 코딩도 약간 참여하고 하는식이지요..
그냥 가만히 앉아서 what만 논하고 흐름만 구성한다면..
문제를 활용해서 쓰기 편한 무언가를 생산하는 engineer가 아니라 문제의 근본을 분석하는 방법론을 논하는 scientist가 아닐까 하는 생각을 가지고 있습니다.
제가 가장 감명 깊었던 프로젝트는 저희과 작품발표회용 프로젝트였죠.
3D탱크 시뮬레이션을 만드는 거였는데.. (포트리스가 아닌 진짜 탱크..)
제가 설계를 맡았는데 설계를 하고 모양 잡으면서 테스트 프로그램 짜는 것만 4개월을 했습니다..
실제 코딩은 한줄도 하지 않았죠.
물론 팀 전원이 4개월동안 계속 만나서 과자 먹으며 설계에 관한 얘기만 했구요.
발표회를 앞두고 코딩한지 딱 5일만에 데모버전이 나온 놀라운 프로젝트였습니다.
모두가 설계에 참여해서 이해하고 있었고..
테스트 프로그램으로 기본 방법을 다 알고 있었기 때문에..
각자 맡은 부분만 완성하고 착! 붙이니 생각대로 딱! 돌아갔을 때.. 전부 감격했죠..
물론 제가 짠 부분을 빼곤 어떻게 구현되어 있는지 모르기 때문에..
나중에 한번 완성시켜볼까 하고 들여다 봤을 땐 난감해서 그만 뒀습니다만.. (다 취직해 버려서..)
그 이후론 저도 설계가 아름다우면(?) 코딩이 쉽다는 선입견(?)을 가지게 되었고..
지금 있는 회사도 사장님이 그런면을 이해해주고 계셔서 부담없이 회의실 탁자에 앉아서 종이나 끄적거리다 퇴근하기도 하죠.. ㅎㅎ
여하간 설계, 코딩, 그 어느것도 중요하지 않은 것이 없다고 봅니다.
설계자는 실제 코딩이 어떻게 구현되는지를 한번은 해 봐야 코딩에 도움이 되는 설계를 할 수 있고..
코더는 설계가 어떻게 이루어지는지를 알아야 적합한 코딩을 할 수 있다고 생각합니다.
ㅡ_ㅡ;
참 엽기적인 랩이군요.
위에서 이미 언급되었지만, 코딩능력없는 설계는 진짜 내공없는 초식입니다. 완전히 주접수준이 나오죠. 인간적으로는 가능한데 왜 안되냐를 반문하게 되죠.
뛰어난 아키텍트는 대부분 뛰어난 코딩능력을 가진 사람들이고, 그 과정에서의 경험과 문제해결 능력이 뛰어나집니다. 설계만 하는 사람은 완전히 반쪽, 아니 반에 반쪽도 안되죠...
재밌는 일례로, 예전에 자료처리때문에 만난 사람이 딱 그꼴이었습니다. 100만개의 자료중에 중복되는 데이터를 서로 다른 위치에 배치해야 되는 경우였습니다. 즉 같은 자료는 같은 그룹내에 있는 것을 찾아내서 서로 다른 그룹에 배치하는 것입니다.
인간적으로 봤을때는 별로 문제가 없죠. A, B, C, D그룹에서 A에 동일데이터가 있어서 B에 넣었다. 근데 B에 새로운 데이터가 들어오면서 중복이 또 발생되었는데 A는 이미 있으므로 C나 D에 넣어야 한다. 말로는 쉽습니다. 그런데 이런것들이 단순중복이 아닌 여러개의 튜플이 결합되어있고 필드가 3개이상 중복인 경우에 옮기고 5개 이상이면 서로 필드를 교환하여 한튜플로 합치고 뭐 이런식으로 나가면 머리 빠개집니다. 근데 그쪽에서 SE 디자인하면 한줄에 끝나더군요. 그러면서 간단한 잡이라는...
"중복 발생시 제거룰을 참조하여 위치이동한다" 라는 것과 박스한개...
========================================
* The truth will set you free.
음..
뭐, 코딩 없는 설계는 당연히 말도 안되는 것이죠.
코딩 없는 설계는, 물리학 없는 달나라용 로켓설계와 똑같습니다.
그런데, 물리학만 안다고 해서 로켓이 나오는 것도 아니죠.
코딩을 잘 한다고 하여, 당연하게도 설계를 잘 하는 것도 아닙니다.
둘 다 똑같이 중요합니다.
사실, 코딩과 설계는 분리해 낼 수 없습니다. 워낙 규모가 커지다 보니, "협업" 에 의한 생산성 증대의 효과를 보기 위하여 그런식으로 분리하려는 시도가 있는지는 모르겠지만, 말도 안되는 발상입니다.
하여간, 요새 세상이 너무 "이 것만 하면 된다" 는 "인스턴트" 적 발상으로 바뀌는 것만 같아 좀 그렇군요.
세상이 갑자기 "천재들만 나오는 세상" 으로 바뀌었나요? 겨우 대학 다니는 짧은 기간동안, 뭐 하나 제대로 목표를 이루어 보지도 않고, "남들이 이전에 해 두었던 것들" 만 거의 수박 겉핥기 식으로 배워놓고는, 과연 설계나 코딩이 될지..
설계만 하면 된다는 사람은, 코딩만 하면 된다는 사람과 동급입니다. 설계는 새로운 개념이 아니라, 예전부터 있어왔죠. 설계는 다름아닌, "목표" 를 세움 입니다. 코딩은 "목표에 접근" 이고요.
그러나, 목표는 언제나 필요에 따라 수정(확장/축소)되고, 목표에 접근하는 방식도 수정되기 마련입니다.
그리고, 이 두가지는 언제나 "한가지" 처럼 유기적으로 연결되어 있어야 합니다.
무조건 분리를 한다고 하여 다 되는게 아닐텐데 말이죠.
L-System
이상하군요.....[b]정상적인 프로그래머는 .......
이상하군요.....
정상적인 프로그래머는 .......
코딩하기전에 항상 설계를 합니다
그리고 설계대로 코딩을 하죠
그러면서 ... 설계에 대해 공부할수 있고
코딩으로 설계에 대한 구현을 공부할수 있죠
또한 코딩하면서 설계의 잘못된점을 절실히 알수 있으며
이러한 설계가 구현이 어려운지 , 쉬운지에 대한 판단또한 할수 있습니다
코딩을 하지 말라는 사람은 제대로 된 설계가 무언인지도 모를 확률이 높으며... 어떻게 구현되는지도 모르기 때문에 .... 프로그래머와 대화 하기 힘들 확률이 높습니다
따라서.... 구현에 문제가 발생할 확률이 높겠죠
----------
참고로 말씀드리자면 저의 학교 모 알고리즘 교수님이 있고 알고리즘 수업에
검색을 배우고 있었습니다
책에 이런 내용이 나왔습니다
분할정복에 관한것인데.....
내부에 어떤값이 들어가있는지 모르는 배열속에 특정값을
검색을 하는것이었습니다
검색 방법으로는 분할정복을 이용하는것이었죠
그래서 제가 물었습니다 , "배열이 정렬이 되어 있어야 분할정복으로 2진 검색을 할수 있을텐데..... 무슨 값이 들어가 있는지 모르는 상태에서 검색은 순차 검색만 하지 못하지 않나요?" 라고 물었습니다 [물론 검색하는 상황은 특정 PC의 상태를 고려한것은 아니고 이론적인 상황입니다]
그러니.... 인정안하시더군요 , 증명을 해야 알겠다고 하더랍니다
그래서 증명해 보이겠다고 하니까 나중에 수업 끝나고 교수 실로 오라는군요
그리고는 순차검색이 더 좋 이유를 보고서로 제출하라는 말만 들었지요
검색 프로그램을 한번이라도 짜보고 , 생각을 해보았다면
정렬되어 있지 않은 요소의 배열을 분할에서 검색하는것은 아무런
의미가 없다는것을 알수 있을텐데 [CPU가 여러개인 멀티 쓰레드 환경을 고려한 사항이 전혀 아닙니다]
교수님은 학문으로만 , 대충 학위를 받기 위해 공부한분인것을 알수 있더군요
그리고 이런 수업을 받을 필요가 없다는 생각 마저 들었습니다
API 정복 책 후기에 이런 내용이 나오지요
API 정복이 없으시면 빌려서라도 API 정복의 집필 후기를 읽어 보시기 바랍니다
C# 이나 XML 등 최신 기술이나 , 설계에 대한 환상을 어느정도 깨실수 있으리라 봅니다
참고적으로 설계자로 진짜 대우를 받고 있는 스티브의 코드 컴플리트나
마틴 마울러의 리팩토링이라는 책을 봐도....... 설계와 구현은 별개의 것임이 아닌것을 알수 있습니다
그리고 설계자는 항상 프로그래머와 대화를 하고 인터페이스에 대한 설계도 해야 하는데 ,... 코딩조차 못하는 설계자을 어떻게 믿고 프로젝트를 진행할수 있을까요?
가끔 교수님들중에 .... 말은 그럴듯하게 하는분이 있지만 , 코딩을 해본분이라는 생각이 전혀 안드는 분이 있습니다
그런분 밑에서 과연 재대로 된 프로젝트를 할수 있을지 의문이더군요
마찬가지라 생각이 듭니다 , 혼자 설계만 하실거면 모르돼
질문자님이 설계한것으로 코딩을 시킬 생각이라면 코딩의 도를 넘어선후에
설계자가 되십시오 [다시 말씀 드리지만 코딩하기전에 항상 설계를 하기 마련입니다,코딩의 도를 넘었다면 설계를 그만큼 많이 했다는 의미기도 합니다]
아니면..... 쪽박 찰거라는 생각이 듭니다
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
[quote="mastercho"][b]분할정복에 관한것인데.....
태클 들어갑니당 ^^
한번만 검색하는거면 갯수가 n개일때 n번
하지만 m개를 검색해야 한다면 n*m번
그러면 m이 많다구 보고 이진검색을 한다고 보면
음ㅁㅁㅁ
정렬에 n*logn
검색에 logn
이진 검색을 한다면 n*logn + m*logn 이 걸립니당.
그니까 m번 검색의 횟수에 따라서 순차와 이진검색의 차가 생길수 있습니다.
m의 갯수가 많아진다면 이 차이는 더 날것이구 ~~
태클 끝
[quote="su2014"][quote="mastercho"][b]
특정값 하나를 찾는것입니다 ^^
그리고 정렬에 대한 고려는 없습니다
하나값만 찾는데 , 정렬해서 찾는다면 그게 더 문제가 되겠죠?
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
[quote]코딩은 하지 말아라 입니다. 그거 해봐야 평생 남 딱갈이
이상은 이상일뿐.......
설계자(Architect?)는 프로그래밍을 못해도 된다는 말
이런 사람이 RFC만들면 엄청난 피드백이 발생합니다.
순수 설계자와 코더의 공존지대는 없습니다.
왜냐구요... 제대로된 설계자와 코더는 마주치지 않습니다.
RFC를 보면 알겠죠. 전 RFC를 봤지만 설계자를 보지 못했습니다.
RFC를 보는 코더를 딱가리라고 생각한다면
설계자 역시 실수요자의 딱가리요, 사장의 딱까리일 뿐입니다.
그 아래 레벨의 설계는 프로그래머가 다합니다. --;
그나저나 백수 언제 탈출하냐... ㅡㅡ; 배고파라.
왜 이런 말을 했을까요?
API 정복저자는 왜 이런 말을 했을까요?
C언어를 반드시 공부해야 한다는 것인지....
무슨 의도 였을까요 궁금....
세포분열중......
Re: 설계와 코드는 별개다..?
제가볼때..거기 교수는 학생보다 못하군요..
최소한 자기 일에대한 어떤 철학도 없어보입니다.
그저뜬구름잡아가며 입으로만 떠벌리는 전형적인스타일로보이는군요..
바로 그러한것이 현제 우리나라의 수준을 이모양으로 만들지 않았나 싶습니다.
저는 프로그램언어하나 재대로 해본적없는사람이 설계한답시고 하는인간들보면 정말한심합니다.
설계의 앞뒤가 맞아야 해먹지요 프로그램구조의 근본을 뒤흔드는 변경사항하며
예를들자면 구조체나 테이블 타입 하나를 잘못정하는바람에
같은프로그램이라도 그런아주사소한것하나에 부분적으로 개발기간이 2배3배로 늘어날수 있습니다. 심지어 10배이상 늘어날수 있으며 시스템블안정성은 수천% 불안해질수 있습니다.
실제로 그런 예가 있었습니다. 아주사소한것 하나때문에 그여파는 연관된프로그램들의 파장이 급수적으로 증가되어 감당이 불감당지경에 이르렀는데도 문제의 핵심을 파악하지 못하고 있더군요.. 말해주지 그랬냐고요? 말해도 소용없었습니다. 이해를못하거든요..
그런 사람들은 그런건 생각할 능력자체가 없는상태입니다. 고려대상도아니며 고려하려해도 할수도 없는사람입니다.
설계를 배워설계를 하는것보다 직접해보고 설계를 느끼는것이 훨씬설계를 잘할수 있다고 봅니다.
코딩을 직접해보면 설계를 따로배우지 않아도 생각은 흘러넘칩니다.ㅎㅎ 다만 손발이 못따라갈뿐이죠..
제가볼때는 진정한설계자가 되기위해서는 상당기간코딩해봐야한다고 봅니다..
그런뒤 다양한 지식을 섭득해도 늦지 않을겁니다.오히려 더빠를겁니다.
그러헌경험은 절대 얕은 지식과는 틀리며 언제나 효율적이며 새로운 방식을 도출해내는 샘터가 되니까요..
----------------------------------------------------------------------------
^^
ㅡ,.ㅡ;; 님 이궁 오해를 하셨네요^^
교수님이 하신 말씀이 아니라 그냥 학생들 사이에서 나온말들이에요
물론 교수님은 그렇게 말씀 않하시죠.
-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com
Re: ^^
랩실에 학생?들 생각이 완전 저런식으로 판을 치고 있다면
교수님도 그런 생각을 하는거와 별반 다를 봐가 없다고 봐지네요
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
[quote="alsong"][b]설계자(Architect?)는 프로그래
공감이 가는 말이네요,,
--
이 아이디는 이제 쓰이지 않습니다.
Re: ^^
제가 글쓰는 능력이 부족한것 같습니다^^
일단 저런 말이 나오는건 SE 연구실에서 일부 학생들입니다.
물론 전체 분위기도 코딩을 않하는 분위기 입니다.
그건 학생들이 그러고 싶어서 그러는게 아니라, SE 연구실에서 하는
대부분의 프로젝트가 코딩이 필요없습니다.
그러다 보니 코딩을 않하게 되고, 분위기가 그렇게 되가고 있다는 것이죠
물론 설계가 SE의 전부는 아니지만,
코딩을 경시 (흔히 이렇게 말합니다. 돈만 있으면 아무에게나 시켜도 결과물은
나온다.)하는 분위기 속에서의 설계자의 문제점을 말한겁니다.
여타 다른 연구실은 전혀 그런 분위기가 아니죠.
-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com
Re: ^^
코딩을 많이 하다보면 ......자연스레 설계를 많이 하게 되고
그러면 머리속에 설계한 내용의 코딩이 머리속에 그려지게 마련이거든이요
한마디로 이미 머리속에서 코딩이 끝날때가 있는겁니다 [물론 많이 해본거에만 해당]
거기서.....전 이런 생각이 들더라고요 , 여기서 부터는 노가다..... -_-; 라는 생각이요
하지만 코딩한번 안해보고 설계자가 된분의 설계는 믿을수가 없다고 생각됩니다
또한 코딩이 노가다라고 말할 자격도 없다고 생각이 드네요
마치 달리기 한번 안해본 사람이 마라톤 감독이 되는거와 마찬가지가 아닐런지
워낙 위에 분들이 좋은 말씀하신 내용들[빛좋은 개살구같은] 말해 주셨으니 글은 이만 줄이겠습니다
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스