-
[기본] 프로그램 개발하는 분들 질문좀2015.06.04 AM 01:28
회사에서 물류관련 프로그램을 쓰고 있습니다.
그저깨 워크샵가서 프로그램 사용 중에 사소한거 하나 하나 때문에 계속 업무처리가
딜레이 되서 건의 드렸는데 대부분 검토해보겠다고 하는게 많았습니다.
예를 들자면 하나하나 선택하는 불편함이 있어서 일괄선택버튼하나 만들어주세요.
라던가 작업지시 10개 처리 할 수 있는거에서 15개나 20까지 가능하게 늘려주세요.
또는 편의상 그리드 저장해놓은게 엑셀로 다운받으면 다시 원복된다. 수정해주세요.
정도인데 개발자 입장에서는 어려운 과정인가요?
수정이 안되는 이유가 제 생각으로는
1. 생각보다 절차가 복잡하다.(상사결제, 개발과정 등)
2. 사소한거 하나 바꾸더라고 생각보다 서버에 많이 부담이 된다.
3. 돈이 많든다.
정도인데 잘 몰라서 질문드립니다.
죄수번호한분이 갑질한다고 해서 댓글하나 삭제했는데 오해의 소지가 있어서 수정합니다.
1. 저는 갑이 아니라 을입니다. 하청업체입니다.
(요구가 아니라 읍소해야되는 위치입니다.)
2. LG하이로지스틱스에서 개발한 프로그램 사용하고 있습니다.
댓글 : 19 개
- 마이클쪼다
- 2015/06/04 AM 01:31
https://twitter.com/iamkimtree/status/603137031842111488
- OverMars[SpEed]
- 2015/06/04 AM 01:38
ㅋㅋㅋㅋ 생각보다 절차나 과정이 복잡한가 보군요
- 스틸2
- 2015/06/04 AM 01:42
아니 저내용이 무조건 맞는것도 아니구요. 일단 원하시는 부분에 대해서 명확하게 정리하셔서 개발쪽에 요청하시면 그후에 피드백이 올텐데요. 회사에서 저 트위터 글처럼 피드백이 온다면 그땐 문제가 있는겁니다. 최소한 왜 안되는지에 대해서는 명확하게 요청한쪽에서 이해가 갈수 있는 답변이 와야 되죠
- 스틸2
- 2015/06/04 AM 01:34
단순히 화면에서 일괄선택이나 처리갯수늘리는게 문제가 아니라 실제로 백단에서 돌아가는 작업지시 처리 작업이 어떤 프로세스로 도느냐가 더 문제일것 같은데요
- OverMars[SpEed]
- 2015/06/04 AM 01:47
백단이 무엇인가요 ^^
- 스틸2
- 2015/06/04 AM 03:18
실제로 작업할때 쓰시는 프로그램 화면을 프론트라고 보시면 되고 프론트에서 작업을 선택해서 처리 버튼을 눌렀을때 프론트에서는 단순하게 처리중이라고 나오겠지만 실제로 그 뒤에서는 물류처리에 대한 프로세스가 돌아가고 있겠죠. 실제로 그부분이 복잡하냐 아니냐의 문제이지 그부분을 빼고 그냥 프론트 화면 수정요청은 어렵지도 않을뿐더러.. 할 의미도 없죠..
- 오쟈마녀 카깃코
- 2015/06/04 AM 01:35
이 글만 보고 판단하긴 어렵다고 생각합니다.
- V1046
- 2015/06/04 AM 01:43
아...음...어.... 얼마전까지 일하던곳에서 '항상'있었던일입니다. 바람직한 개발자라면 진짜 일정 검토해보고 수정해주실것입니다. 대신 기간이 오래걸릴수도있어요.
근데 해줄맘이 없어보인다면(안되겠다는듯이 곤란한 느낌) 날로먹는 개발자거나, 아니면 분명 이 사태에 대해 예견했으나, 개발을 모르시는 위에서 이해못하고 강행돌파시켜서 열받은것 정도로 예상이 되네요
최종적으로는 첫댓의 트윗과 같은 느낌을 받는게 사실이긴하나... 난이도가 높거나 이렇진 않아요; 대게 귀찮은수준이지요;
근데 해줄맘이 없어보인다면(안되겠다는듯이 곤란한 느낌) 날로먹는 개발자거나, 아니면 분명 이 사태에 대해 예견했으나, 개발을 모르시는 위에서 이해못하고 강행돌파시켜서 열받은것 정도로 예상이 되네요
최종적으로는 첫댓의 트윗과 같은 느낌을 받는게 사실이긴하나... 난이도가 높거나 이렇진 않아요; 대게 귀찮은수준이지요;
- 다산교주
- 2015/06/04 AM 01:45
이것저것 생각해볼게 많죠... 백단 프로세스 신경 안쓰고 단순히 코딩으로만 보더라도... 기존의 코딩이 반영하기 그지 같이 되어 있으면... 힘든거고 아니면 좀 더 쉬울수도 있구요... 문제는 스틸2 님이 말씀하신것 처럼 백단에서 어떻게 굴러가느냐가 문제죠..
물론 쉽게 되는 부분들도 있긴 합니다. 예를 들어 일괄 선택이라던가... 등등... 이미 목록중 하나를 선택할 수 있게 해놨으면.. 일괄선택이야 머...
물론 쉽게 되는 부분들도 있긴 합니다. 예를 들어 일괄 선택이라던가... 등등... 이미 목록중 하나를 선택할 수 있게 해놨으면.. 일괄선택이야 머...
- joreg
- 2015/06/04 AM 01:45
저도 이 글만보고 판단하기는 뭐하지만... 클라이언트에서만 동작하고(혹은 그에 준하는 인프라가 갖추어진 전용서버) 제가 그 프로그램 제작자라면... 아마 하루도 안걸릴 작업이라고 생각합니다.
일관선택 버튼 -> 어떤 그리드나 다른 걸 사용한다고 하더라도 무슨 선사시대때 라이브러리 아니라면 10분도 안걸릴 작업입니다.
작업지시 처리 10개 처리할거 15개나 20개까지 가능하게.
어떤 작업 지시인지는 모르겠지만 결국 for문 돌리는거 최대치 늘리는 작업일텐데 10분도 안걸릴 작업입니다.
그리드 저장해놓는게 엑셀로 다운받으면 원복된다? 뭔말인지 모르겠습니다. 하지만 파일 입출력이고 이미 엑셀파일로 저장하는 기능이 있다면 역시나 10분도 안걸릴 작업 같습니다.
뭔가 처리하는데 엄청난 보안이 필요한 직장이시라던가 그러면 변수가 있을수 있겟지만 그다지 오래걸릴 작업은 아닌거 같습니다. 1시간만에 완성하고 7시간동안 테스트(+ 농땡이)해서 오류 없으면 하루면 끝나겠네요.
일관선택 버튼 -> 어떤 그리드나 다른 걸 사용한다고 하더라도 무슨 선사시대때 라이브러리 아니라면 10분도 안걸릴 작업입니다.
작업지시 처리 10개 처리할거 15개나 20개까지 가능하게.
어떤 작업 지시인지는 모르겠지만 결국 for문 돌리는거 최대치 늘리는 작업일텐데 10분도 안걸릴 작업입니다.
그리드 저장해놓는게 엑셀로 다운받으면 원복된다? 뭔말인지 모르겠습니다. 하지만 파일 입출력이고 이미 엑셀파일로 저장하는 기능이 있다면 역시나 10분도 안걸릴 작업 같습니다.
뭔가 처리하는데 엄청난 보안이 필요한 직장이시라던가 그러면 변수가 있을수 있겟지만 그다지 오래걸릴 작업은 아닌거 같습니다. 1시간만에 완성하고 7시간동안 테스트(+ 농땡이)해서 오류 없으면 하루면 끝나겠네요.
- V1046
- 2015/06/04 AM 01:45
아 그리고 그런 간단해보이는 기능이 저만큼 힘들거나 할 일의 양이 많은 이유는
1. 개발자 실력부족(극히 적음)
2. 회사의 지옥같은 스케줄맞추기로 퀄 하락
정도가 있겠습니다.
결국 쉽게 yes가 나오지 않는건 날로먹는사람만 아니면 결과적으로 진짜 쉽지 않아서 입니다;
1. 개발자 실력부족(극히 적음)
2. 회사의 지옥같은 스케줄맞추기로 퀄 하락
정도가 있겠습니다.
결국 쉽게 yes가 나오지 않는건 날로먹는사람만 아니면 결과적으로 진짜 쉽지 않아서 입니다;
- 건
- 2015/06/04 AM 01:46
첫재 돈, 둘째 시간, 셋째, 수정가능한 능력이 있는 개발자 입니다. 수정을 원하는대로 가능할수 있게 업체와 유지보수 계약이 되어있나 ? 둘재는 그 개발기간의 난이도를 통함 시간이 얼마나 되는가? 셋째는 그 수정을 빠르게 정확하고 깔끔하게 처리할수 있는 능숙한 개발자가 있나 이겁니다.
그런데 보통 능숙한 개발자는 유지보수파트쪽은 빠지고 신입같은 경우가 들어와있기때문에 고쳐달라고 하면 젤 위에 트위터처럼 되는경우가 많죠 ㅎㅎ
그런데 보통 능숙한 개발자는 유지보수파트쪽은 빠지고 신입같은 경우가 들어와있기때문에 고쳐달라고 하면 젤 위에 트위터처럼 되는경우가 많죠 ㅎㅎ
- 초지 경
- 2015/06/04 AM 01:46
일단 얘기 하신거만 이라면 어렵지 않을수 있으나 다른 어려운 요구 사항은 빼고 말씀 하신거라면 얘기는 다를 수 있죠.
프로그래머 입장에선 번거롭고 복잡한 작업인데 다른 사람이 볼땐 쉬워 보이는 거일수도 있구요. 물론 반대일수도 있구요..
그리고 오래된 프로그램일수록 코드가 많이 꼬여 있기 때문에 정말 간단한거 수정 했는데 다른곳이 다 에러나는 경우도 많습니다.
또 하나는 관리 프로그램이니 대충 어떤 언어로 만들었을지는 짐작이 가지만 언어마다 툴마다 개발방법같은게 많이 차이 나기 때문에 딱 집어서 얘기 하기는 애매 하네요,,
그리고 노파심에서 얘기 하는데 외국은 엔지니어 대접이 좋습니다. (상대적으로 한국보다. ) 프로그램이 그렇게 간단하고 쉬운게 아니라는거죠.. 물론 천재 플머 빼고요..ㅎㅎ
여튼 전문가 입장이 아닌 사람이 요구사항 난이도 대해서 이렇다 저렇다 평가하는건 무리가 있겠죠..
이상 10년차 게임 프로그래머의 넋두리 였습니다.^^;;;
프로그래머 입장에선 번거롭고 복잡한 작업인데 다른 사람이 볼땐 쉬워 보이는 거일수도 있구요. 물론 반대일수도 있구요..
그리고 오래된 프로그램일수록 코드가 많이 꼬여 있기 때문에 정말 간단한거 수정 했는데 다른곳이 다 에러나는 경우도 많습니다.
또 하나는 관리 프로그램이니 대충 어떤 언어로 만들었을지는 짐작이 가지만 언어마다 툴마다 개발방법같은게 많이 차이 나기 때문에 딱 집어서 얘기 하기는 애매 하네요,,
그리고 노파심에서 얘기 하는데 외국은 엔지니어 대접이 좋습니다. (상대적으로 한국보다. ) 프로그램이 그렇게 간단하고 쉬운게 아니라는거죠.. 물론 천재 플머 빼고요..ㅎㅎ
여튼 전문가 입장이 아닌 사람이 요구사항 난이도 대해서 이렇다 저렇다 평가하는건 무리가 있겠죠..
이상 10년차 게임 프로그래머의 넋두리 였습니다.^^;;;
- joreg
- 2015/06/04 AM 02:07
다시한번 쓰지만 솔직히 프로그래머 입장에서 말도안돼는 요청아니면 안되는거 없다고 생각합니다.
저도 게임 프로그래머지만 지금당장 언리얼4보다 뛰어난 그래픽과 최적화된 게임엔진 만들어내라. 같은요청을 받아도 5년 정도 주시면 할수 있을거 같습니다. 라고 대답할거 같습니다. 하지만 5년후에는 언리얼은 더 나가있겠죠 더 최신의 그래픽기술로 무장하고. 결국 그런 문제인 겁니다.
솔직히 진짜 프로그래밍 배우고 어느정도 깨우친 이후에는 실력적으로 안될만한 요청을 받아본 기억이 없습니다.
결국 시간문제일 뿐이고 월급쟁이라면 돈도 그닥 관련 없습니다. 그리고 프로라면 요청에 대해서는 시간으로 대답할수 있어야 한다고 봅니다. 저는 프리랜서는 뛰어본적 없어서 모르겠지만.
요청 -> xx정도 걸릴거 같습니다.
다른대답은 그닥 필요없다고 생각하고, 시간이 맘에 안들면 짜르려면 짤라라 식으로 살아와서. 결국 제 생각에는 프로그래머로서 못한다는 말은 진짜 엄청나게 실력이 없거나. 그냥 핑계라고 생각합니다. 전혀 관심없던 분야도 구글링해서 결국에는 다 해내게 됩니다. 시간없다는 말은 이해해도.
저도 게임 프로그래머지만 지금당장 언리얼4보다 뛰어난 그래픽과 최적화된 게임엔진 만들어내라. 같은요청을 받아도 5년 정도 주시면 할수 있을거 같습니다. 라고 대답할거 같습니다. 하지만 5년후에는 언리얼은 더 나가있겠죠 더 최신의 그래픽기술로 무장하고. 결국 그런 문제인 겁니다.
솔직히 진짜 프로그래밍 배우고 어느정도 깨우친 이후에는 실력적으로 안될만한 요청을 받아본 기억이 없습니다.
결국 시간문제일 뿐이고 월급쟁이라면 돈도 그닥 관련 없습니다. 그리고 프로라면 요청에 대해서는 시간으로 대답할수 있어야 한다고 봅니다. 저는 프리랜서는 뛰어본적 없어서 모르겠지만.
요청 -> xx정도 걸릴거 같습니다.
다른대답은 그닥 필요없다고 생각하고, 시간이 맘에 안들면 짜르려면 짤라라 식으로 살아와서. 결국 제 생각에는 프로그래머로서 못한다는 말은 진짜 엄청나게 실력이 없거나. 그냥 핑계라고 생각합니다. 전혀 관심없던 분야도 구글링해서 결국에는 다 해내게 됩니다. 시간없다는 말은 이해해도.
- 해적K
- 2015/06/04 AM 02:10
저걸 간단히 만들어 준다고 답한다면 그 프로그래머는 정말 슈퍼프로그래머 거나 경험이 적은 프로그래머일겁니다
- 스틸2
- 2015/06/04 AM 03:29
저걸 간단히 만들어 준다고 바로 말한다면 성실하게 본인이 맡은 시스템에 대해서 이해도가 높은 평범한 개발자일 확률도 큽니다. 개인적으로 저런 오더에 대해서는 제일 좋아하는 대답은 아마 바로 대답하는것보다 최대한 빨리 확인해보고 답변 드리겠습니다. 라고 한후 한번더 확인후 답변메일 보내는거죠.. 참고로 큰사고는 슈퍼프로그래머가 더 많이 치더군요
- LoveToBe
- 2015/06/04 AM 02:13
위에 분과 비슷한 생각입니다. 안되는게 어디있어. 안해서 그렇지 할려고 하면 거의 다 됩니다.
다만 해야 하는 합당한 이유가 있어야겠죠. 금전적인 이득이나 기타 등등.
개발자가 금방 수정할수 있는 일도 영업의 이득에 따라 못한다고 배째라 하는 경우도 많습니다.
다만 해야 하는 합당한 이유가 있어야겠죠. 금전적인 이득이나 기타 등등.
개발자가 금방 수정할수 있는 일도 영업의 이득에 따라 못한다고 배째라 하는 경우도 많습니다.
- KirinRush
- 2015/06/04 AM 02:21
9년차 프로그래머 입장에서 이야기 드리면 프로그램 만든 사람이 프로그램 사후 관리를 해준다면 그리 어려운 문제는 아닙니다. 그런데 보통은 그렇게 잘 안됩니다. 인건비가 상대적으로 싼 신입이나 하청으로 넘기기 때문입니다.
더 큰 문제는 프로그램의 규모에 따른 검수입니다. 님이 사용하시는 프로그램이 업데이트 이후 물류 추가가 안된다던가 기존에 있던게 지워진다던가 하는 식의 오류가 나면 업무가 무너집니다. 프로그램이라는건 그래서 사소한 부분이 수정되었다고 해도 고객에 보내지기 전에는 언제는 제품 확인절차를 꼭 거칩니다. 이때 수정된것만 하는게 아닌 전반적인 확인을 다합니다. [재대로 일하는 회사라면]
그렇기 때문에 사소한거 하나 하나를 매번 들을때 마다 업데이트 하다간 검사하는 시간이 너무 오래걸려서 프로그램 관리쪽 입장에서는 시간적인 손실이 상당히 심합니다. 그래서 보통은 정기 또는 모아서 한번에 업데이트 하는쪽을 선호합니다. 묶어서 한번에 전채적인 테스트를 끝내고 보내주는 쪽이 안전하기 때문이죠.
정리하자만 왠만해서는 수정 자체는 어려운게 아니지만 프로그램이 오류나 자료 손실같은 심각한 문제가 없는지 검수하는 부분이 필요하기 때문에 묶어서 처리하는 방향으로 선호합니다. 아니면 시간적 부담이 크고 이는 돈으로 연결되죠.
더 큰 문제는 프로그램의 규모에 따른 검수입니다. 님이 사용하시는 프로그램이 업데이트 이후 물류 추가가 안된다던가 기존에 있던게 지워진다던가 하는 식의 오류가 나면 업무가 무너집니다. 프로그램이라는건 그래서 사소한 부분이 수정되었다고 해도 고객에 보내지기 전에는 언제는 제품 확인절차를 꼭 거칩니다. 이때 수정된것만 하는게 아닌 전반적인 확인을 다합니다. [재대로 일하는 회사라면]
그렇기 때문에 사소한거 하나 하나를 매번 들을때 마다 업데이트 하다간 검사하는 시간이 너무 오래걸려서 프로그램 관리쪽 입장에서는 시간적인 손실이 상당히 심합니다. 그래서 보통은 정기 또는 모아서 한번에 업데이트 하는쪽을 선호합니다. 묶어서 한번에 전채적인 테스트를 끝내고 보내주는 쪽이 안전하기 때문이죠.
정리하자만 왠만해서는 수정 자체는 어려운게 아니지만 프로그램이 오류나 자료 손실같은 심각한 문제가 없는지 검수하는 부분이 필요하기 때문에 묶어서 처리하는 방향으로 선호합니다. 아니면 시간적 부담이 크고 이는 돈으로 연결되죠.
- 몬스터.[
- 2015/06/04 AM 03:35
잘쓰고있는 업무용프로그램은 버그가 있어도 잘 수정하지 않죠
이유는 잘쓰고 있는데 손대면서 지연되거나 문제가 생기면
입는 리스크보다는 직원 더 굴리면 잘쓰고 있으니 상관없다는 마인드죠
사실 편의 사항은 크게 어려운문제는 아니지만
서버 데이터가 바뀌는 문제는 민감하죠
자체에 프로그램 전담 개발자가있지않은 이상 발생하는 비용도 기능에 비해
적지않구요
그냥 그러려니 할수밖에없죠 가끔 답답한나머지 직접 공부해서
회사에서 사용하는 프로그램을 새로 만들어서 제안하는 경우도 본적있는데
그래도 회사에선 받아드리지않을 가능성이 높죠
이유는 잘쓰고 있는데 손대면서 지연되거나 문제가 생기면
입는 리스크보다는 직원 더 굴리면 잘쓰고 있으니 상관없다는 마인드죠
사실 편의 사항은 크게 어려운문제는 아니지만
서버 데이터가 바뀌는 문제는 민감하죠
자체에 프로그램 전담 개발자가있지않은 이상 발생하는 비용도 기능에 비해
적지않구요
그냥 그러려니 할수밖에없죠 가끔 답답한나머지 직접 공부해서
회사에서 사용하는 프로그램을 새로 만들어서 제안하는 경우도 본적있는데
그래도 회사에선 받아드리지않을 가능성이 높죠
user error : Error. B.