복잡한 개발이 거창하고 멋질까 과연? 정보
복잡한 개발이 거창하고 멋질까 과연?
본문
프로그래머가 자신의 능력을 과시하기 위하여 엄청나게 무겁고 꼬아서 만들어놓은 결과물이라면.
과연 어떻게 봐야할까요.
그것이 엄청난 모습이라 혀를 내두르며 경배해야할까요.
가장 쉽고 편하게 접근할 수 있게 해주는 것이 실력자인 듯 합니다.
물론 기획되는 단계부터 잘 되어줘야하고 그것이 개발자와 잘 협업될 때 가장 멋진 결과물이 나온다고 생각합니다.
개발자들은 기술적 우위에 있기에 개발물을 자랑하기 위한 도구 삼으면 안된다고 봅니다.
결과물은 소비 주체들이 너무 쉽게 접근할 수 있게 해주는 것이 더욱 감동스럽고 훌륭한 작업이라 생각해봅니다.
개발자 입장에서도 소비자들에게 "니들이 뭘 아냐"란 식은 참 위험하다고 생각합니다.
중요한건 소비자들이 잘 모르고 이해 못하는 것을 PM와 영업선에서 잘 납득시키고 설명하며..
적절한 평가와 가격을 유도할 수 있어야하고.
그것을 근거로 개발자들은 가장 쉽고 간결하게 결과물을 뽑아주면 된다고 생각합니다.
원론적인 말이지만 참 중요한 듯 합니다.
키포인트.
1. 개발자에게 턱 없는 것만 요구하진 말아야한다. 개발자는 개발자다.
2. 오만한 개발자의 오만은 위험하다. 가장 효과적이고 간결하게 개발을 할 줄 아는 것도 실력이다.
추천
0
0
댓글 9개
제새악인데요... 가장 쉽고 간결하게 뽑아주는 것 보다는 ... 상황에 맞게 ㅎㅎ

새악.. 이게 뭘까 한참 생각했습니다. 생각이었죠?
새악 제새악은 뭘까.. 제새악.. ㅜㅜ 이러고 있었습니다.
정확히 조합하면 상황에 맞게 간결하게 뽑으면 되겠죠.
새악 제새악은 뭘까.. 제새악.. ㅜㅜ 이러고 있었습니다.
정확히 조합하면 상황에 맞게 간결하게 뽑으면 되겠죠.

복잡하게 꼬아둔 개발도 필요악 일때가 있습니다 ^^;;

일반적인 경우를 말하는거죠.
복잡하게 꼬은 것이 의도성이 있을 수 있지만.
일반적으로 볼 때..
결과물은 베베 꼬아선 안된다고 봅니다.
소스 자체를 베베 꼬을 필요성 등은 가끔 있을 수 있겠지요.
복잡하게 꼬은 것이 의도성이 있을 수 있지만.
일반적으로 볼 때..
결과물은 베베 꼬아선 안된다고 봅니다.
소스 자체를 베베 꼬을 필요성 등은 가끔 있을 수 있겠지요.

프로그래밍 책 서문에 항상 나오는 말 아닌가요?^^

어랏 어찌 아셨죠. ㅎㅎ

제가 서문만 읽고 책 덮는 것으로 세계 일등이거든요. ㅋ

전 표지 보고 나서 후루루루룩 그림 위주로 책 넘겨보고 나서 제자리에 꽂습니다. ㅎ

본문 내용과 상관없이 개발이란 말에는 여러가지 의미가 포함되어져 있는데 의뢰인들은 그걸 모르는듯 합니다. 제작과 개발은 정말 다른 영역이고 창작의 영역이라 개발이 되지 못할 가능성도 배제할 수는 없는 일인데 개발에 들어가면 100%라는 공식이 언제부터 성립되어졌는지 모르겠더군요.
같은 php개발자라고 해도 각기 다른 패턴을 고수하고 부가적으로 필요한 다른 내용의 영역들도 개인기와 같이 천차만별인데 "의뢰=개발성공"이란 공식으로 덤비면 개발자 당사자들에게 경우에 따라서 너무 가혹한 공식이 되어버리기도 하죠.
기다릴 시간 없고 여유자금이 없으면 개발이란 영역을 탐해서 업계최초가 되는 욕심을 버리고 이미 개발되어져 있는 솔루션이나 빌더로 제작의 수순을 밟아야 하는 의뢰자들이 차고 넘치더라구요. 개발자가 마치 어지간한 팀을 합쳐놓은 신적인 존재처럼 알기전에 1인 개발이면 1인 개발에 맞는 욕심만 챙겼으면 좋겠네요.
같은 php개발자라고 해도 각기 다른 패턴을 고수하고 부가적으로 필요한 다른 내용의 영역들도 개인기와 같이 천차만별인데 "의뢰=개발성공"이란 공식으로 덤비면 개발자 당사자들에게 경우에 따라서 너무 가혹한 공식이 되어버리기도 하죠.
기다릴 시간 없고 여유자금이 없으면 개발이란 영역을 탐해서 업계최초가 되는 욕심을 버리고 이미 개발되어져 있는 솔루션이나 빌더로 제작의 수순을 밟아야 하는 의뢰자들이 차고 넘치더라구요. 개발자가 마치 어지간한 팀을 합쳐놓은 신적인 존재처럼 알기전에 1인 개발이면 1인 개발에 맞는 욕심만 챙겼으면 좋겠네요.