반대로, 저모양 소스를 리팩토링 하고 열심히 정리해 놓으면 자신이 익숙한 코드가 아니라고 화내는 개발자도 있습니다. 쓸데없이 변수를 여기저기 끌고가고, 네이밍 충돌나서 a_1 a_2 a_3 이딴식으로 쓰길래, 쓰는 부분만 영역지정자{ } 로 묶어줬더니 문법에도 없는 문구 쓰지 말라고 메일 돌리는 현업도 봤는데요 뭘.
문법에도 없는 문구가 왜 컴파일도 잘 되고, 잘 돌아가는건데 참나.
함수 정의부에만 영역지정자를 써오던 자신의 무지함을 탓할 걸 남탓하덥디다.
BlaCk
IP 220.♡.38.196
08-14
2019-08-14 12:11:16
·
@danny_님 현업 a1 a2 a3 실화입니까
역시 세상은 넓고 무서운 사람들은 많군요
조미운
IP 39.♡.172.76
08-14
2019-08-14 11:35:38
·
핑계가 너무 많네요. 전회사에서도 현회사에서도 코드 더럽게 짜는 사람이 개발자 본인이라는 이야기 같은데...
그런데, 프로그램 복잡성이라는게 담당자의 시야나 경험에 따라서도 다르고, 높은 정합성이 초급 개발자에겐
엉망으로 보일 수도 있고... 반대의 경우도 있을 수 있겠죠.
fivebird
IP 203.♡.147.42
08-14
2019-08-14 14:26:03
·
저 경우는 2가지 경우가 있죠..
1. 개발자가 더럽게 코딩을 하거나
2. 관리, 기획자가 기획이 자주 바뀌고 기간은 촉박하게 주거나.
우리나라의 경우는 2번이 경우가 많죠..
삭제 되었습니다.
삭제 되었습니다.
IP 183.♡.19.213
08-14
2019-08-14 16:14:03
·
그냥 새로 온 개발자가 문제라는 개그성 툰 같은데, 진지하게 외부 탓하는 댓글이 많네요.
LifeSimulator
IP 220.♡.166.196
08-14
2019-08-14 16:53:42
·
남의 일이 아니라서 ^^;;;
스탠리
IP 92.♡.63.240
08-14
2019-08-14 16:25:28
·
기획 바뀌는 건 모든 개발과제의 속성입니다. 심지어 혼자 뭘 만들어도 중간에 생각이 바뀌거나 새로운 사실을 알아서 refactoring해야 하는 경우가 얼마나 많은데요. 프로라면 감수해야 하는 거고, 그 와중에 깔끔한 코드를 뽑아내는 개발자가 프로 중의 프로인 거죠.
이제그만~
IP 61.♡.179.2
08-14
2019-08-14 16:28:44
·
과연 개발만 그럴까요? 기획자의 입장에서 기획도 마찬가지입니다.ㅎㅎㅎ
코딩이냥
IP 61.♡.54.79
08-14
2019-08-14 16:50:23
·
개발자가 고객 핑계 클라이언트 핑계를 대는 경우는 대부분 개발실력이 어중간하기 때문에 그렇습니다.
요구사항이 틀어진다고 코드 줄기가 틀어져야 한다면 그만큼 초기 설계가 잘못되었다는 반증이에요.
초기에 제대로 설계만 해둔다면 요구사항이 틀어져도 오히려 대처하기가 더 편합니다.
자하랑
IP 211.♡.70.77
08-14
2019-08-14 17:00:28
·
동의하기 어렵네요. 초기 설계를 제대로 하려면 그만큼 개발 기간이 늘어나게 되죠. 아무리 유연한 설계를 해도 수정 요구사항을 받기 힘든 요구도 태반입니다.
건물 다 지어가고 마무리 하려는데... 남향이 아니네요 5도만 틀어봅시다... 라는 요구를 어떻게 설계에 반영할 수 있을까요.
@자하랑님
설계에 투자를 많이 하면 초기 개발기간이 늘어난 만큼 후반부 개발기간이 줄어듭니다.
저희 회사에서도 자체 인력이 부족할때 종종 프리랜서를 고용해서 자주 일하는데 문제는 SI쪽으로 종사하는 개발자중 설계 제대로 하시는 분들은 보기가 힘들었어요.
그만큼 국내 SI쪽 개발자는 양산 개발자가 많다는 반증이기도 하구요.
약간의 요구사항 변경에도 그냥 copy&paste로 일관하시는 분들이 대부분이고요.
아주 거창한 패턴까지 가지 않더라도 MVC, MVVM를 제대로 이해를 하고 업무 클래스만 제대로 정리만 해둬도 왠간한 요구사항 추가나 변경은 시간이 문제이지 코드가 엉망으로 바뀌진 않습니다.
자하랑
IP 211.♡.70.77
08-14
2019-08-14 17:33:16
·
MVVM 같은 디자인패턴은 기본이라고 생각하는데요... 그것도 안 하는 것은 정말 심각한 상태인거고요.
대부분의 문제 되는 기획 변경은 UI 변경이나 이런 것들이 아니라 근본적인 원인이 태반입니다.설계 잘해서 건축 다 해봐야 5도 틀어주세요... 이런 건 대책이 안 되는데, 이걸 이해 못하는 클라이언트가 많은 것이 문제죠. 그래서 시스템이 클 수록 기획에 투자를 많이 해야하고, 변경은 정말 최소한이 되어야 합니다.
@자하랑님
MVC, MVVM쪽을 UI쪽 요소로만 생각하신다면 조금 더 생각의 범주를 넓혀 보시는게 좋을것 같습니다.
자꾸 언급하시는 건축에서 5도틀어달라는게 개발쪽에서는 어떤 범주에 속할지 잘 감은 안오는데 객체지향적인 개발방법이라는게 원래 그런 여러가지 변경되는 요구사항을 유연하게 대응하기 위해 사용되어 집니다.
실제 건축에서도 5도 틀어달라는 요구사항은 관철되지도 않고요.
그리고 개발에서 기획만 잘되면 변경을 최소화 시킬 수 있다는 관점 자체가 잘못된 방향입니다.
물론 지향해야할 방향인건 맞지만 기본적으로 요구사항은 바뀔 수 있다는걸 기준으로 진행이 되어야 하며, 그것때문에 익스트림이니 에자일이니 그런 개발방법론들이 발전되어 오고 있는것입니다.
SI현실 상 그런 개발방법론을 적용시킬 수 있는건 아니지만, 기본적으로 프로젝트 1차 설계가 결과물이라는 생각은 버려야 한다는것이죠.
그걸 최소화 시키는게 PM의 역할이지만, 요구사항이 바뀌었다고 코드가 엿가락처럼 꼬인다면 그건 개발자의 역량인거죠.
자하랑
IP 211.♡.70.77
08-14
2019-08-14 18:00:12
·
관점의 차이가 있는 것 같아서 길게 얘기할 이유는 없는 거 같네요.
다만 요구 변경에 따라서 스파게티가 된다는 건 개발작의 역량이다... 라는 말에 결코 동의할 수 없습니다.
어느 규모의 플젝을 하시는 지는 모르곘지만 규모가 클수록 기획의 중요성이 크고, 자그마한 변경으로 코드가 누더기 되는 것은 어떠한 설계 방법론을 가져온다고 해도 해결되지 않습니다.
물론 유연한 설계와 충분한 검토가 개발 방향을 틀었을 때 위기요소를 줄이는 좋은 방법이지만, 저는 그보다 잘 정리되고 변화가 없는 Spec. 이 100배는 더 중요하다고 생각합니다.
예를 들어 사용자 규모가 1억 단위의 개발이라고 하면, 반드시 이상한 케이스와 사용자가 나오기 때문에 이에 대한 걸 개발에서 책임질 수가 없습니다. 유연한 개발은 기본이지만, 그보다 더 중요한 것은 기획과 project PM의 역할이라는 말씀을 드리고 싶은 것 뿐이네요.
@자하랑님
기획과 project pm의 역할은 당연히 중요합니다.
말씀하시는 기획과 pm의 중요성을 부인하는건 아니구요.
이 글의 관점은 이걸 논하자는게 아니고 요구사항 변경에 따른 코드 일관성이 깨지는겁니다.
1명 사용자가 1억명으로 늘었다고 해도 해당 부분을 처리하는 부분이 더 복잡하게 구현이 되어야 하는거지 코드가 꼬이면 안되는겁니다.
대부분 코드가 꼬이는 경우는 각 모듈간의 독립성이 보장이 안되고(모듈이라는 개념 자체가 희박하거나) 서로가 연관되어 있어서 수정 및 테스트가 아주 힘든 경우이거든요.
한가지 이해하기 쉬운 예를 들면 복잡한 업무로직을 분할 시키지 않고 if else 중심으로 구현을 한다는 등입니다.
아직 여러 크고 작은 프로젝트를 수행하면서 복잡한 업무로직 개발 시 패턴을 적용시키는 개발자는 거의 본적이 없습니다. 업무 상세까지 자세히 패턴을 잡지 못한다고 하더라도 큰 범주에서만이라도 잡아둔다면 전체 구조는 유지시킬 수 있습니다.
그리고 업무의 단위 단위가 최대한 다른 모듈과 독립적으로 구성을 시킨다면 큰 구조가 바뀐다고 하더라도 이 모듈의 조립 순서가 바뀌는거나 모듈이 다른 모듈로 바뀌거나 모듈의 복잡성이 증가하는것이지 구조 자체가 꼬이지 않습니다.
다만 개발시간만 자꾸 늘어날 뿐입니다.
문제는 아직 국내 개발자 수준(SI)라인에서 이 정도로 각종 업무 플로우에 대한 객체 설계를 할 수 있는 능력을 가지신 분이 별로 없다는것입니다.
솔류션이나 포털쪽 업체 대비 SI쪽의 개발환경 및 기술수준이 떨어지는게 문제인것이죠.
새로운 댓글이 없습니다.
이미지 최대 업로드 용량 15 MB / 업로드 가능 확장자 jpg,gif,png,jpeg 지나치게 큰 이미지의 크기는 조정될 수 있습니다.
그리고 주석에서 발견되는 내 이름..
모두 "당신만 그렇게 한다고......."
헤헤....
난 도와 줄려구 그렇거.....마무리를 부탁한다....제군들...
이런느낌
코드가 저렇게 되는 이유는 최초 만든사람이 제대로 된 주석이나 문서를 안만들어놨을 경우, 혹은 만들어 놨는데 그 이후 관리가 제대로 안되서 그 내용과 현재 상태가 많이 다른 경우가 저렇게 되버리는 거죠.
시간을 주고 덧붙이면 모르겠는데 내일 오픈할걸 오늘 요구하면 그냥 가장 쉬운 방법으로 기능만 구현 ㅋㅋㅋ
클라이언트나 경영진이나 전임자 탓을 하는 분들이 많으신걸 보니... 역시 개발자가 많으신가봐요 ㅎㅎㅎ
아.. 코드나 마저 짜러 가야겠다...
클라이언트가 공짜로 이것저것 넣어달라고 하는 것도 큽니다
문법에도 없는 문구가 왜 컴파일도 잘 되고, 잘 돌아가는건데 참나.
함수 정의부에만 영역지정자를 써오던 자신의 무지함을 탓할 걸 남탓하덥디다.
역시 세상은 넓고 무서운 사람들은 많군요
저희도 외주 개발자가 손봐주고 간 영역은 한번씩 계속 다시 봐줘야 합니다.
오너쉽이 없는 체로 만들어진 프로그램의 운명인거죠.
그런데, 프로그램 복잡성이라는게 담당자의 시야나 경험에 따라서도 다르고, 높은 정합성이 초급 개발자에겐
엉망으로 보일 수도 있고... 반대의 경우도 있을 수 있겠죠.
1. 개발자가 더럽게 코딩을 하거나
2. 관리, 기획자가 기획이 자주 바뀌고 기간은 촉박하게 주거나.
우리나라의 경우는 2번이 경우가 많죠..
요구사항이 틀어진다고 코드 줄기가 틀어져야 한다면 그만큼 초기 설계가 잘못되었다는 반증이에요.
초기에 제대로 설계만 해둔다면 요구사항이 틀어져도 오히려 대처하기가 더 편합니다.
건물 다 지어가고 마무리 하려는데... 남향이 아니네요 5도만 틀어봅시다... 라는 요구를 어떻게 설계에 반영할 수 있을까요.
설계에 투자를 많이 하면 초기 개발기간이 늘어난 만큼 후반부 개발기간이 줄어듭니다.
저희 회사에서도 자체 인력이 부족할때 종종 프리랜서를 고용해서 자주 일하는데 문제는 SI쪽으로 종사하는 개발자중 설계 제대로 하시는 분들은 보기가 힘들었어요.
그만큼 국내 SI쪽 개발자는 양산 개발자가 많다는 반증이기도 하구요.
약간의 요구사항 변경에도 그냥 copy&paste로 일관하시는 분들이 대부분이고요.
아주 거창한 패턴까지 가지 않더라도 MVC, MVVM를 제대로 이해를 하고 업무 클래스만 제대로 정리만 해둬도 왠간한 요구사항 추가나 변경은 시간이 문제이지 코드가 엉망으로 바뀌진 않습니다.
대부분의 문제 되는 기획 변경은 UI 변경이나 이런 것들이 아니라 근본적인 원인이 태반입니다.설계 잘해서 건축 다 해봐야 5도 틀어주세요... 이런 건 대책이 안 되는데, 이걸 이해 못하는 클라이언트가 많은 것이 문제죠. 그래서 시스템이 클 수록 기획에 투자를 많이 해야하고, 변경은 정말 최소한이 되어야 합니다.
MVC, MVVM쪽을 UI쪽 요소로만 생각하신다면 조금 더 생각의 범주를 넓혀 보시는게 좋을것 같습니다.
자꾸 언급하시는 건축에서 5도틀어달라는게 개발쪽에서는 어떤 범주에 속할지 잘 감은 안오는데 객체지향적인 개발방법이라는게 원래 그런 여러가지 변경되는 요구사항을 유연하게 대응하기 위해 사용되어 집니다.
실제 건축에서도 5도 틀어달라는 요구사항은 관철되지도 않고요.
그리고 개발에서 기획만 잘되면 변경을 최소화 시킬 수 있다는 관점 자체가 잘못된 방향입니다.
물론 지향해야할 방향인건 맞지만 기본적으로 요구사항은 바뀔 수 있다는걸 기준으로 진행이 되어야 하며, 그것때문에 익스트림이니 에자일이니 그런 개발방법론들이 발전되어 오고 있는것입니다.
SI현실 상 그런 개발방법론을 적용시킬 수 있는건 아니지만, 기본적으로 프로젝트 1차 설계가 결과물이라는 생각은 버려야 한다는것이죠.
그걸 최소화 시키는게 PM의 역할이지만, 요구사항이 바뀌었다고 코드가 엿가락처럼 꼬인다면 그건 개발자의 역량인거죠.
다만 요구 변경에 따라서 스파게티가 된다는 건 개발작의 역량이다... 라는 말에 결코 동의할 수 없습니다.
어느 규모의 플젝을 하시는 지는 모르곘지만 규모가 클수록 기획의 중요성이 크고, 자그마한 변경으로 코드가 누더기 되는 것은 어떠한 설계 방법론을 가져온다고 해도 해결되지 않습니다.
물론 유연한 설계와 충분한 검토가 개발 방향을 틀었을 때 위기요소를 줄이는 좋은 방법이지만, 저는 그보다 잘 정리되고 변화가 없는 Spec. 이 100배는 더 중요하다고 생각합니다.
예를 들어 사용자 규모가 1억 단위의 개발이라고 하면, 반드시 이상한 케이스와 사용자가 나오기 때문에 이에 대한 걸 개발에서 책임질 수가 없습니다. 유연한 개발은 기본이지만, 그보다 더 중요한 것은 기획과 project PM의 역할이라는 말씀을 드리고 싶은 것 뿐이네요.
기획과 project pm의 역할은 당연히 중요합니다.
말씀하시는 기획과 pm의 중요성을 부인하는건 아니구요.
이 글의 관점은 이걸 논하자는게 아니고 요구사항 변경에 따른 코드 일관성이 깨지는겁니다.
1명 사용자가 1억명으로 늘었다고 해도 해당 부분을 처리하는 부분이 더 복잡하게 구현이 되어야 하는거지 코드가 꼬이면 안되는겁니다.
대부분 코드가 꼬이는 경우는 각 모듈간의 독립성이 보장이 안되고(모듈이라는 개념 자체가 희박하거나) 서로가 연관되어 있어서 수정 및 테스트가 아주 힘든 경우이거든요.
한가지 이해하기 쉬운 예를 들면 복잡한 업무로직을 분할 시키지 않고 if else 중심으로 구현을 한다는 등입니다.
아직 여러 크고 작은 프로젝트를 수행하면서 복잡한 업무로직 개발 시 패턴을 적용시키는 개발자는 거의 본적이 없습니다. 업무 상세까지 자세히 패턴을 잡지 못한다고 하더라도 큰 범주에서만이라도 잡아둔다면 전체 구조는 유지시킬 수 있습니다.
그리고 업무의 단위 단위가 최대한 다른 모듈과 독립적으로 구성을 시킨다면 큰 구조가 바뀐다고 하더라도 이 모듈의 조립 순서가 바뀌는거나 모듈이 다른 모듈로 바뀌거나 모듈의 복잡성이 증가하는것이지 구조 자체가 꼬이지 않습니다.
다만 개발시간만 자꾸 늘어날 뿐입니다.
문제는 아직 국내 개발자 수준(SI)라인에서 이 정도로 각종 업무 플로우에 대한 객체 설계를 할 수 있는 능력을 가지신 분이 별로 없다는것입니다.
솔류션이나 포털쪽 업체 대비 SI쪽의 개발환경 및 기술수준이 떨어지는게 문제인것이죠.