개념없는 개발자들...(2)

현재 주소 복사
트랙백 주소 복사
방실이님의 글 (2/10/2007 11:09:12 PM) Viewing : 4999
개념없는 개발자들 두번째 이야기..

이번은 ㅇ아무개 업체의 이야기이다.
참으로 개념없는 개발자들..
경력도 나이도 많이 먹었으면서..신입보다도 못한(실력을 말하는게 아니다..기본 마인드가 문제지..) 이런 개발자들이 참 많다는건..
개발자로서의 존심이 졸라 허락하지 않는다..
가슴 아프다..ㅡ.ㅡ;;

그런데..그런 개발자들을 주위에서 쉽게 볼 수 있다는게..우리 나라 이 바닥의 문제다...
어느 누가 나를 그렇게 보고 있는지도 모르겠다..@.@

여튼 이야기를 풀어 보겠다..

ㅇ아무개 업체의 개발자.. 대략 30대 후반이다.
어떤 프로젝트 때문에 같이 일을 하게 되었다.


모든 프로세스는 인풋과 아웃풋이 있다.
단지 메서드에 입력되는 파라메터를 말하는게 아니라 좀 더 범용적인 표현을 한 것이니 태글 달지 말기 바란다..
어쨋건..
데이터를 보내면 어떤 행위를 하고 그 반환값을 받기 전에는 호출자는 상황을 알 수 없다.
그 반환값은 return 값일 수도 있고 ref나 out 으로 할당 받은 참조 값일 수도 있고, 어떤 행위의 결과물일수도 있다.
어쨋건 호출자는 그 결과를 알아야 한다.
물론 때에 따라서 호출만 하고 그 결과값을 받지 않는 경우도 허다하다. 안다..태클 걸지 말기 바란다.

프로시저를 사용할때는 일반적인 조회가 아니라면 항상 리턴값을 이용하는 편이다.
그렇다면 사용자 친화적인 메시지를 얻을 수 있는 잇점이 있다.
예를 들자면..회원 가입 폼을 생각해 보자.
회원 가입 실패의 이유는 허다하다.
유일키의 중복이라든지, 권한이 없다든지, 뭐 기타 등등의 여러 가지가 있을수 있다.
리턴을 받지 않는 다면 어떠한 이유때문에 실패 했는지..알수 없다.
성공했는지 실패 했는지 조차도 알수 없다. ㅡ.ㅡ;;;

남들은 어찌 생각하는지 모르지만..내가 보기엔 이건 기본이다...
던져 주는게 있으면 그게 잘 되었는지 확인을 해보는 코드가 뒤따라야 한다는것..

이 ㅇ아무개 회사의 개발자, 프로시저를 짜 본적이 없다고 하였다.
그래서 쪽팔리지 않으려고 엄청(?) 고민해서 자잘한 유효성 체크까지 모두 한 프로시저를 짜 주었다.
그런 유효성 체크에 걸리면 특정값들을 리턴한다. 그래야 사용자 친화적인 메시지를 보여 줄수 있을테니...
아..이런..리턴값을 받을 줄을 모른다...
그래서 결국은 그냥 호출만 했다..그 결과는 아무도 모른다...
이 문제는 실력문제가 조금은 비중이 있기에 개념과는 약간 먼 이야기 일 수 있으나..

이제 개발을 시작하는 초급자 분들은 꼭 알아 두기 바란다..아니면 잊어 버렸던 개발자들도..
호출을 하게 되면 그것을 꼭 확인하라~~~

이 정도까지는 뭐...약간 실력이 떨어지면 그럴수 있다고 본다..(그래도 30대 후반의 나이와 경력이 참 무색하기만 하다..ㅡ.ㅡ;)

이건 빙산의 일각일 뿐이다.

이런 저런 연유로 인해..
데이터 베이스 구조를 보게 되었다.

(mssql을 이용하는 ) 개발자라면 누구나 정원혁님의 mssql 책쯤은 보았으리라 생각된다.(꼭 그 책이 아니어도 뭐 무방하다..ㅡ.ㅡ;)
나도 데이터베이스에는 쥐약이라..
프로젝트 설계할때 작정했던 데이터베이스를 코딩시에 종종 바꾸기도 한다.
여러가지 상황을 감안하지 못했기 때문이다. 그러나 나름대로 정규화시켜보려고 시도를 하고 검색 인덱스를 고려 하려고 노력한다. 물론 전문 데이터베이스 설계자(혹은 데이터베이스 프로그래머)들은 더 많은 시도와 고민들을 하겠지만..

어쨋든 까탈스런 제약조건과 정규화는 데이터의 무결성을 보장하는 기본중에 기본이다.
물론 상황에 따라 이 부분을 임의로 어긋나게 하는 경우도 있으나 이는 상황에 따라서이다.
위에 잠깐 언급했던 정원혁님의 책에 의하면..아득한 기억속에 남아 있는 그 문구들..
비정규화는 정규화를 한 후에 성능이나 기타의 문제에 따라서 상황판단으로 비정규화가 더 이득이라고...생각이 명확해 질때 해야 한다는 그 문구가 기억난다.

좋다..일단 이게 기본이다.

이제 데이터베이스 스키마을 보면..놀라웠다
ERD를 보았는데..30여개의 테이블에 제약조건이 단 1개도 없다..
단 1개도..
내가 전산밥 먹은지 수년 만에 이런 스키마는 처음 보았다..ㅡ.ㅡ;
있을수도..있어서도 안되는 스키마..
(이 글을 보는 독자는 그런 구조를 본적이 있는가?? )

이 데이터들의 무결성을 어떻게 보장 할 것인가??
그런데..이건 빙산의 일각일 뿐이다.
나를 쓰러지게 한 사건은 따로 있었다.

작업했던 프로젝트는 윈도우즈 응용 프로그램이었다.
특정 폼에 텍스트 박스가 몇개 있었다.
좌우에 각각 몇개씩 있는 대략 그런 폼이었다.

우리 팀 신입이 테스트를 하는데..하루는 왼쪽에서 값을 입력하고 바로 오른쪽에 값을 입력하였다.
일반적으로 같은 카테고리로 묶여 있으면 같이 진행하는게 일반적이긴 하다.
예를 들자면 주소 검색을 하고 전화번호 적고 상세 주소를 입력하지는 않는다..주소 검색하고 상세주소를 적지..일반적으로 말이다...
그런데..왼쪽 텍스트박스에 입력을 하고 바로 아래 텍스트박스에 값을 입력을 하지 않고 오른쪽에 있는 텍스트박스에 값을 입력하니 오류가 뜨는것이다.
물론 왼쪽 텍스트박스에 값을 입력하고 그 아래 것들을 모두 입력하고 오른쪽으로 포커스를 이용하면 오류가 나지 않는다..
이 광경을 우리 신입이 말 하기를 어 에러 나는데요?? 했더니
그 ㅇ아무개 회사의 자칭개발자님 하는 말..
"개발자가 그것도 몰라요? 위에서 아래로 순서대로 입력을 해야지..왜 왼쪽꺼 입력한다음에 바로 오른쪽으로 이동해요.."
라고 하더라..

허허허..
우리 신입...5초간 정적 후에..아..네...라고 했더랜다.

좋다..
이런 경우를 어떻게 해석해야 할지..대략 난감하다.
이 경우는 어떤 기본이 안되어 있을까??
1차적인 문제는 클라이언트는 바보(상징적인 의미일 뿐이다.)다..라는 기본 개념이 없는 문제다.
뭐 이거야 수정하면 되니. 그냥 저냥 넘어 갈 수는 있다.
그러나 큰 문제는 이 사람이 가지고 있는 그 마인드이다.
내 생각에는 어 그러네?? 하면서 바로 수정작업에 들어 가거나 기록(추후 수정을 하겠다는 )을 해야 한다..
그런데 이 분(?)께서는..어떻게 말씀을 하셨나..

이게..기본이 안되어 있는 것이다.

다른 개발자를 위하여 빨리 키보드를 놓기를 권한다.
다른 길을 알아 보셔요..제발제발...
같이 개발자라고 불리우는게 쪽팔리니깐.

------------------

나이나 경력이 차게 되면 사실 한계를 많이 느끼게 된다..ㅡ.ㅡ;
원래 전공자도 아니어서 인지 기본지식과 학습(대학때 배우는것들)이 부족해서인지 힘들때가 많다.
물론 학습(지금 공부하는 것들)으로 충족시키려고 노력은 하지만..그게 예전처럼 쉽지만은 않다.체력적인 문제도 있고..ㅡ.ㅡ;
어쨋건 사람은 제 구실을 적당히 라도 해야 한다고 생각이 든다.

다음에는 이와 관련된 글을 써볼까 한다.
반박이나 동조나..뭐 어쨋거나 리플을 달아 주시면 감사하게 생각하겠다..^^

마지막 업데이트 : (2/10/2007 11:09:12 PM)



Trackback 보기 (0)
댓글 보기 (9)
정성태님의 글 (2/12/2007 8:40:37 AM)
구체적인 프로젝트는 밝힐 수 없지만.
(참고로, 저도 데이터베이스는 CRUD 만 알고 그 외는 거의 모릅니다.)

하지만, "field1", "field2", "field3", "field4" ... (그들 말로는) 확장을 위해서 이런 식으로 필드를 정의한 테이블을 당연하게 쓰고 있더군요. 그런데... 문제는, 세월이 지나고 그 중의 특정 필드를 어떤 용법으로 개발했는지 아는 사람이 없다는 것이엇습니다. (자신들도 ... 특정 필드가 현재는 사용중인지 아닌지 확신할 수 없다고. ^^;)

정규화가 고려된 테이블이라면 (실수로 또는 몰라서)제약조건을 안 달았다고 하겠건만.
그 테이블은 도저히 정규화가 불가능한.... ^^; 상태였습니다.

근데요... 그 기업체가 (이름만 들으면 알 수있는) 꽤나 큰 기업이었답니다. 그리고, 그 DB 는 그들의 Main DB 에 해당하는 것이었고. (갑자기 또 그 때가 생각나니 가슴이 답답해지넹... ^^;)



이방은님의 글 (2/12/2007 9:33:36 AM)
ㅋㅋ
그런 경우 저도 본적이 있습니다.
모든 테이블이 그런것은 아니었지만.
특정 테이블의 컬럼이 그런 경우는 본적이 있네요..
XXX1, XXX2, XXX3, XXX4 ~~~~
아주..당황 스럽죠..ㅡ.ㅡ;



이정일님의 글 (2/12/2007 11:37:55 AM)
헉.. 컬럼을 그렇게 짜면 우째 알아보고 코딩을 하는지.. 신기하네요 @.@



최지훈님의 글 (2/14/2007 5:15:25 PM)
ㅎㅎ. 재미있네요.
저도 위에 사항처럼 그런 것은 아니지만...
가끔씩 고객 편의가 아닌 제 편의에 맞추어서 Validation 체크를 할 때가 가끔 있죠.
ㅎㅎ. 찔리네용 ^^;;



민성욱님의 글 (2/22/2007 3:13:41 PM)
왠지 저 신입이 저였던거 같습니다 -0-;;;;

저 제약조건없는 테이블의 모든 컬럼이 varchar로 되어있었지요...허허



김현동님의 글 (2/23/2007 10:21:39 AM)
^^ 종종 보아왔던... 또는 저의 얘기 같기도 하고... ㅜㅜ;
첫번째 낙서... 주로 SI쪽에 있다보니 제한적인 사용자에게만 노출하는 웹기반 프로젝에서 인젝션 공격을 막기위한 고위험 문자열을 필터링 하지 않는 경우가 많이 있었네요.
글을 읽어보니 SI쪽 인트라 기반의 검색쪽 부분에도 필터링 처리하는 메서드를 미리 하나 만들어 두어야 겠다는 생각이 듭니다. 흐미...

두번째 얘기에서는 개념이 없다기 보다는 경험부족인 것 같아 보이는 군요. 저도 그런쪽에 가까워서 코멘트달기 뭐하지만 ㅜㅜ ...
"경력은 많은데 경험이 부족한 사람" 이 PM,PL,DBA 등에 위치해 있는 사람이 있으면 그 프로젝은 꼭 이상한 쪽으로 가곤 하더군요.

그리고 성태님과 방실님이 말씀하신 그 회사... 치약 만들다가 냉장고 만드는 회사 계열쪽이 그렇더군요.
그쪽 5년간 운영하는 DB 구조 정확히 아는 사람 딱 3명이더군요. 그중 한분이 그만둔다고 했다가 난리가 난적이 있었습니다. ㅎㅎ



임혁님의 글 (2/26/2007 2:50:39 PM)
재밌다.. 또 없냐?



이방은님의 글 (2/26/2007 6:56:57 PM)
기댕겨라...ㅡ.ㅡ 요즘 정신없다.



똥개발자님의 글 (2/15/2017 8:24:29 PM)
ㅎㅎ..맞는말씀입니다. 주로 그누보드,영카트 개발자(개발자라하기도 뭐한..그냥 제작자들)들은 거의 100%다 그런 마인드더군요.
관계형 DB라는 거에 대한 기본이 하나도 없어요..그냥 프로그램하다가 필요할때, 디스크에 저장하는 프로그램으로 알고있더군요.
db에 관심도 없고..db설계가 뭔지? 거기에 대해 아예 아무런 느낌도 못가지고 있더군요. 그냥 깡통이예요ㅕ..ㅎㅎ




댓글 쓰기