|
:: 게시판
:: 이전 게시판
|
- PGR21 관련된 질문 및 건의는 [건의 게시판]을 이용바랍니다.
- (2013년 3월 이전) 오래된 질문글은 [이전 질문 게시판]에 있습니다. 통합 규정을 준수해 주십시오. (2015.12.25.)
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
22/07/14 07:56
어떤 언어 어떤 코드냐에 따라 다르겠지만,
남이 코딩한거 분석할 수 있을 정도가 되려면 결국 본인이 그 정도 구현할 줄 알아야 합니다. 개발자 출신 직원을 영입하는게 더 효율적일 것 같습니다.
22/07/14 10:50
저도 공감... 개발부서의 '개발 모르면 코딩 모르면 입 닫고 우리말 들어'에 휘둘리지 말아야겠다는 좋은 대처자세인 것 같아보이나 쓰니님 부서 인원 중 아무도 html의 h도 모르는 상황에서 어느정도 입문단계 정도는 떼우고 공부 하는 방향은 비효율적인 것 같습니다..
실제로 개발 실무나 개발자와 긴밀하게 협업을 오래해본 경험 있는 기획자 및 PM경험이 좀 있는 분을 쓰니님 측으로 영입하고 그 분이 개발측과 다리역할 해야 휘둘리지 않고 효과적으로 잘 될 것 같습니다~
22/07/14 08:51
코드 읽는거야 금방 되는데, 설계를 이해하는건 시간이 좀 걸릴거예요.
뭔가를 수정했을때 어떤 문제가 생길지는 경험이 좀 있어야 각이 나오기도 하구요. 사실 난이도와 기간은 개발센스가 있냐 없냐에 따라 하늘과 땅 차이라서 확답은 어렵습니다만 재미삼아 공부해보세요. 흐흐
22/07/14 08:55
저도 개발자입니다만 소스코드 읽는 정도로 노련한 개발자들한테 대응 안됩니다. 쓸데없는데 헛힘 쓰지 않는것을 권합니다. 그건 마치 갓 입사한 신입이 어설프게 과장 업무 훑어보고 훈수두는거랑 똑같은겁니다. 소프트웨어 복잡도는 단순히 소스코드 레벨이 아니라 설계와 DB 등등 여러 부문이 복잡하게 얽혀있어서 단순히 코드만 본다고 파악될 문제가 아니예요. 아 물론 화면 문구하나 수정하는 업무? 이정도는 알 수 있겠지만 개발자가 왠만큼 양심없지 않는 이상 문구 수정에 몇일 몇주 이렇게 일정 산정할 리는 없다고 봅니다. 차라리 부서장급에 정식으로 이의를 제기해서 일정 산정 기준과 근거를 명확하게 알려달라고 하고 회의 소집해서 한판 붙는게 더 빠른 해결책
22/07/14 08:55
말씀하신 수준은 초짜가 배워서 안 될거고, 개발자로 경력자 뽑으세요
연구개발쪽에서 입장에서 우리 모른다고 눈탱이 치는거 아니야? 라는 멘트가 그냥 요식적으로 쪼으려고 하는 말이라고 생각했는데 진짜로 저쪽에서는 그렇게 생각하는거였군요... 진짜 눈탱이라고쳐도 그런 검토 프로세스 거쳐서 누구는 하루면 된다는데 왜 오래 걸리냐는 식으로 하면 싸우자는거라 서로 불편해질겁니다 실무자가 개발을 배운다는 얘기가 나올게 아니라 부서장급에서 협조 관련해서 잘 협의해주셔야죠 그러라고 있는게 관리잔데
22/07/14 09:01
소스코드 읽는거 어렵습니다..
소스코드가 10% 노출되있으면 프레임워크 or 오픈소스 라는 이름으로 90% 숨겨져 있고, 그 프레임워크를 공부하는 것도 어렵습니다. 그러므로 쉬운 일은 아닙니다. 개발 경력 5년차들도... 다른 사람이 작성한 코드는 해석이 잘 안되는 경우가 태반입니다.
22/07/14 09:05
(수정됨) 제 코드를 제가 봐도 가끔 이해 안됩니다?
그리고 개발자들이 일정을 잡을 때.. 생각보다 빡빡하게 잡을 겁니다. 연구팀은 기약 없는 일을 하는 경우가 많아서 마진을 많이 두는 편이지만, 개발팀은 내부에서 서로 얼마만큼의 시간이 필요할 지 사이즈가 나오기 때문에 일정을 부풀릴 수가 없을 거에요.. 일반적으로는.
22/07/14 09:09
그냥 혼자 작업하는 정도라면 1년 정도면 충분하다고 생각합니다만
직접 작업하는게 아니라 다른 사람이 만든 코드 분석하는거는 더 어렵습니다. 코드를 짤 때 어떤 식으로 짜는지에 따라서 분석 난이도는 더 올라가고요.(망할 람다식...아직도 이해를 잘 못하고 있습니다.) 공부를 하기 위함이 아닌 상대방과 논쟁하기 위한 코드 분석은 사실상 코드를 작성한 사람 수준이 되야 합니다. 거기다 어설프게 공부한 다음에 지적하려고 하면 더 털립니다. 예를 들면 화면에 문구 바꾸는 정도라고 할 때 바꿔야 되는 문구의 양과 설계를 어떤 식으로 했는지에 따라서 하루면 될 수도 있고, 일주일은 걸릴 수도 있고, 한달이 걸릴 수도 있습니다.(한달은 좀 오버긴 합니다.) 만약 2주정도 걸린다고 했을 때 왜 설계를 이렇게 했냐고 해도 일정상 어쩔 수 없이 이렇게 할 수 밖에 없었다고 하면 불똥이 다른 쪽으로 튀게 되는거죠.
22/07/14 09:37
공수 파악 하는 건 같은 개발자여도 남의 작업이 얼마나 걸릴지 파악하는 건 어렵습니다. 복잡한 작업은 그 시스템 돌아가는 거까지 다 알아야되요. 심지어 자기 것도 공수 빡빡하게 잡았다가 뭐 하나 틀어지면 길어지는 거 일도 아니에요.
22/07/14 09:46
(수정됨) 어.... 길게 적었는데 댓글이 날아가버렸다.. ㅠㅠ
멘붕해서 짧게만 적겠습니다. 1. 남의 코드가 왜 그렇게 도는지 이해를 하려면 결국 그 코드를 작성하게 한 지시서, 구현의 근거 자료가 있을때와 없을때 이해도가 달라질 수 밖에 없음. - 내가 일을 하는데 사용하는 프로그램의 동작원리와 내가 일을 하는 프로세스가 같다면 해당 부분에 대한 코드 이해도는 꽤 올라갈 수 있음. - 심지어 Database Table만 봐도 자료들이 눈에 익기 때문에 컬럼명이 대충 있어도 그게 보임 2. 그게 아닌 상태에서 만들어진 코드를 이해하는데는 굉장한 스트레스가 발생함 - 코드로는 문법오류가 없지만, 프로세스상의 논리오류가 발생하는 지점에서 이 부분이 꽤 문제가 되는데, 업무 담당자조차 그게 이 프로세스가 맞는지 갈팡질팡하면 지옥으로 가버림. ex) 노임을 처리하는 과정에서 4대보험을 먼저 처리해서 4대보험 공제액 계산을 해야 하는데, 이 과정에서 선행작업 안해두고 노임에 공제가 안돼요 같은 소리를 하는데 어느게 맞는지 답 못내려주면, 이하 생략합니다. 3. 일반적인 업무영역에서의 프로그램이 코드 하나만 본다고 해결되는것이 아니라는 것을 고려 - 데이터가 저장되어야 하니 Database에도 오고가야 하고, 오라클처럼 그 안에서의 별도의 프로그램형태인 프로시저들이 돌기도 하고, 그걸 읽고 쓰는 프레임워크도 있고, 실제 화면을 보여주는 코드도 있고 여러가지가 유기적으로 엮인다면 초보의 영역에서 된다는 말도 쉽지는 않습니다. - 디버그라는 개념이 이해가 되어야 그나마 좀 해결이 되는데, 여러가지 시스템으로 만들어졌다면 디버그도 쉽지가 않아집니다. 4. 선천적으로 성향이나 성격에 좌우됨 - 추리소설 좋아하고, 가설을 세워서 결론을 도출하는걸 잘하신다면 가능성이 높음. - 그게 아닌상태에선 쉽지 않은 길입니다. 영향성 이야기를 한페이지쯤 썼는데 이거도 짧게 요약하면 자재를 청구해서 정산하는 과정까지가 한개의 중대형 시스템인데, 발주쯤에서 추가적으로 입력란을 기입해야 한다고 하면 발주부터 그 뒤에 나올 입고와 정산쯤의 시스템에서 해당 입력란을 계속 끌어와야할 수 있습니다. 그렇게 된다는 이야기는 요청자쯤에선 발주에 이거 하나 추가요지만, 개발쪽에선 발주와 입고 정산까지 뒤집어야 하니까 영향이 올라가기 때문에 난색을 표하게 되겠죠. 근데 만약 그게 발주와 관련한 부분에서만 사용할 입력란이다. 입고와 정산에선 해당 입력란 안쓰니까 발주에서만 할 수 있도록 하면 됨. 나 이말 나중에 무르지 않을거임. 필요하다면 추후에 입고와 정산에 추가해달라고 요청할거고 우선순위는 그때 가서 정하겠다. 형태로 한다고 치면 개발쪽에선 우선순위를 앞세워 둘 수도 있을겁니다. 남의 코드 뒤집어까고, 이거저거 하면서 먹고살고 있습니다만, 재미도 있고 가끔 탐정이 된 느낌인데 열받는 일도 꽤 많습니다 ㅠㅠ
22/07/14 09:53
개발PM들이 작업하거나 외주줄때 느끼는 문제들이죠. 크크
이전에 흑화된(?) 개발PM 한분은 개발자들에대한 불신감이 커서, 기본적으로 2~3정도 소모되는 작업을 최대량으로 늘려서 한달 일정잡는 사람들이 많다고, 이분이 강철비 보고나서 북한 개발자 닥달하는 김갑수 배우님 팬이 되었죠. 그때부터 자주 쓰는 말이 "하루주갔어." 입니다.
22/07/14 10:10
(수정됨) 코드 읽는건 쉽습니다. 단 거기에 추상화되어 녹아든 숨겨진 부분들 모두 이해하는 게 어렵습니다.
여기를 바꿨을 때 영향 받는 부분들을 전부 파악하는게 어렵습니다. 프로그래머마다 스타일이 다른 부분도 있어서 영향범위 산정이 케바케인 경우가 너무 많습니다.
22/07/14 10:24
남이 짠 소스 보는건 어렵습니다
그래도 최종 반영전 코드리뷰에 참여시켜달라고 해서 앉아계시고 형상관리툴에 보기권한 달라고하셔서 뭘 수정했는지 볼수는 있게해두세요 작정하고 하면 모르겠지만 저정도만해도 경각심은 생길겁니다
22/07/14 10:36
괜히 건드렸다가.............사이드 이펙트 터지면 몇 배로 터질 수도 있습니다 그냥 맡기시되 좀 세게 나가 보심이 크크크
22/07/14 11:00
(수정됨) 개발자들이 하는 일을 비개발자가 공부해서 파악한다면 개발자가 필요없겠죠. 단순히 코드하나보는건 공부하면 이해할 수 도 있겠지만, 왜 그렇게 했는지 그게 최선인지 등등은 개발자 각각이 온갖 시행착오를 겪으면서 나온 결과물일 가능성이 높습니다. 경험이 쌓이다 보면, 나중에 문제가 발생시 어떻게 해놔야 수정이 쉬울까 까지 고려하게 됩니다.
그리고 눈탱이 맞는 느낌이 드는건...개발자들 입장에서 보자면 프로젝트가 시작되고 나면 처음에 정한 제안들이 계속 바뀌는 경우가 많습니다. 이거 조금 바꾸는게 오래걸려? 네...오래걸립니다. 그런 경우가 항상 있다보니, 그걸 감안한 일정에 버퍼를 가져가게 되죠. 제가 일하는 곳도 기한은 정해져 있는데, 한두달을 사양변경에, 높으신분들의 입김으로 방향수정하며 날려 먹는게 다반사입니다. 처음에 협의할 때, 절대 처음 요청한 부분에서 변경사항 없을거다라고 못박아주면 개발자도 일정을 줄일 수 있습니다. 그런데 그렇게 100%확신하기 어렵죠. 그러면 일정이나 비용등의 회신도 똑같습니다. 서로 서로 속으로 버퍼 잡고가는 거죠.
22/07/14 11:21
(수정됨) 금융 IT가 답답하게 돌아가는면이 있긴 하더라구요. 도메인 자체가 보수적으로 다뤄야하고 땜빵식 레거시 코드들이 산재해있어서... 아무도 안쓰는 옛날 버전의 언어로 개발되어있다거나.. 그런 함정들이 곳곳에 있다보니 그래서 점점 일정 산정도 따라서 보수적이 되는 경향이 있는것같습니다.
코드 자체를 이해해보고 싶다면 천천히 길게 가야합니다. 그 언어의 기초 문법을 먼저 배우고, 그다음 실제 코드를 하나하나 다 검색하고 물어가면서 조금씩 읽기 시작하면 될거에요
22/07/14 11:41
(수정됨) 간단해보이는 거 바꿔도 사이드 이펙트 어떤 게 일어날지 모릅니다.
간단한 소스 코드 수정해도 이후 배포를 해야 실반영 되는데 간단해보이는 부분을 직접 처리하시려고 하면 이 부분도 문제구요.
22/07/14 11:44
업무프로세스와 코딩되어있는 소스를 이해하실 정도면 개발팀 쥐고 흔드실수 있을겁니다
하지만, 행정부서의 업무프로세스 이해도가 오히려 개발팀보다 못한 경우가 꽤 많아서...
22/07/14 12:13
내가 짠 코드도 문서와 주석없이 6개월 뒤에 다시보면 남이 짠거보는거랑 다를바가 없습니다...
대략적인 기능과 대략적인 흐름을 보는 거 자체는 접근 가능할지 몰라도 세밀한분석과 버그수정같은건 어렵다고 봅니다.
22/07/14 13:41
읽는게 쓰는것보다 훨씬 더 어렵습니다... 개발팀에 더 자세히 물어보는게 최선입니다.
개발팀을 대신해서 이야기 하자면 - 어느 부분을 바꿔야 그 문구 수정이 가능한지 알 아야 하는데 그 바꿔야 하는 부분이 현재 다른 사람이 작업중인 부분일 수 있습니다. - 또한 그 부분을 작성한 사람이 그대로 있으면 그 사람에게 부탁하면 꽤 빨리 되는데 금융쪽 이야기를 들어보면 유지보수랑 신규개발이 인력이 다른 경우가 많아서 (다들 뛰쳐나가기때문에) 누군가 그걸/그사람을 찾는데 고생이 필요합니다. - 문서화가 잘 되어있으면 그나마 빨리 찾아볼 수 있는데 맨날 일정이 빡빡하니까 문서 업데이트가 개발 업데이트랑 같이 진행되어있지 않은 경우가 많아서 문서를 찾아도 결국 소스를 다시 찾아야 하는 경우가 부지기수입니다. - 배포 주기에 맞춰서 보통 여러 요청사항을 한꺼번에 묶어서 프로그램을 새로 생성 & 배포합니다. 수정사항이 반영되었을때 배포주기 운이 안좋으면 1주일이나 혹은 해당 배포주기 만큼 추가입니다. - 위의 이유들로 오래되고 큰 프로그램/서비스 일수록 같은 수정사항 이더라도 수정이 보통 더 오래 걸립니다. 이걸 최대한 적게 늘어나게 만드는 것이 훌륭한 아키텍트의 덕목 중 하나입니다. - 결국 소스를 이해하게되어도 개발기간 단축이 어렵습니다. 눈탱이 맞는 느낌이 강하면 전문성있는 감사를 도입해야 합니다... 개발팀 바꿔도 또 반복이거든요 (다른 사람이 만든걸 해야하기 때문에 더 어려워짐) 감사를 한다고 하면 서로 졸라게 피곤해지자고 하는 건데 이것도 쉽지 않습니다 (감사준비하느라 개발을 못함). 이래서 좋은 개발자/개발팀을 뽑는것이 중요합니다.
22/07/14 13:59
쌓아 올린 젠가의 중간에 또다른 무언가를 우겨 넣는데 간단할리가 있겠습니까.
여기 고쳤더니 엉뚱한 곳에서 누수가 발생 할 수도 있는겁니다. 쉬운것도 쉬운게 아니죠
22/07/14 14:26
비합리적입니다. 읽어봐야 개발자와 척만 지게 될테고요.
일정이 길게 느껴진다면 보통 아래 이유중에 하나죠. 담당자가 수동적이거나, 프로젝트가 복잡하거나, 요청자들이 너무 쉽게 생각하거나.. 1번은 좋은 사람으로 담당자 교체 하는법이 있고 2.3번은 답 없는 문제죠
22/07/14 18:49
그냥 개발 경력자를 뽑으셔서 업무 프로세스 가르치고 나서 PM을 맡기시던가...
그게 안된다면 그냥 개발팀 믿으세요. 답 없어요... - 남의 코드 뜯어보는거 진짜 쉬운일 아니라서요.
22/07/15 04:50
업무상 여러 전문가들과 같이 일하지만, 그들의 시뮬레이션 과정이나 로직을 보여 달라고는 안합니다. 그냥 정리된 결과만!!
어차피 봐도 이해안되어, 서로 시간 낭비니까요. 그러나 수치화된 결과는 비록 그 과정을 몰라도 합리적이지 않다면 충분히 챌린지 할수 있습니다. (요것도 케이스바이 케이스입니다) (개인적인 생각입니다) 현 시점에서 할수 있는 최선은 기존 유사했던 건들을 어느 정도의 시간으로 어떻게 처리했는지 이력을 좀 확인해 보시고 일정 협의하실때에 기존의 사례를 이야기하며, 합리적인 선에서 일을 해 주길 요청하시는게 좋을거 같습니다.
|
||||||||||