OOP, 디자인 패턴 등을 사용하지 않는 팀과 팀원들을 어떻게 설득해야 할까요
3개의 좋아요
좋게 풀게있나요? FA라고 하심은 잠깐 들렸다 떠나는 손님이란 말씀인데, 박힌돌들 입장에선 들을필요가 없죠. 그냥 할당받은 일만큼만 하고 손털면 끝이죠
3개의 좋아요
뭐…사실 오지랖인건데요 이건…
OOP를 비롯한 코딩의 일반적인 이론을 배우는 이유는 유지보수를 하기 위함인 것은 아실 것 같습니다.
그리고 그 유지보수 기법들은 미래의 나, 또는 동료의 시간을 아끼기 위해서 현업을 기반으로 탄생된 것입니다. 뜬구름 잡는 소리도 아니고, 탁상공론이 아닌 현업에서 실제 사용가능한 일반적인패턴이라는 것입니다.
소프트웨어 코딩이라는 것은 자유도가 매우 높습니다. 이렇게도 저렇게 짜서 비즈니스가 굴러가기만 하면 됩니다.
저는 주니어 개발자들이 저에게 멘토링을 원하거나 어떤 대답을 할 때 제가 대학시절 멘토님께 배운 것을 그대로 알려줍니다.
- 돼?
- 얼마나 잘 돼?
라고 말해줍니다.
1번의 돼? 라고 물어보는 것은 그저 소프트웨어가 내 의도대로 동작을 합니까? 를 물어보는 것입니다. 그래서 이 부분은 솔직히 말해서 코딩 기술자체가 쉬워지고 전문화된만큼 요즘은 코드를 치지 않는 다른 직군의 사람들도 ChatGPT를 쓴다던지 장벽이 낮은 파이썬을 이용해서 구조없이 그냥 내가 아는 이론 그냥 그 수준대로 개발해서 일단 되게할 수 있습니다.
즉, 전문 소프트웨어 개발자, 10년차 특급개발자 라는 타이틀이 있으려면 이 1번에서 머물러서는 안되며, 2번까지 충족시켜야하는 것입니다.
2번의 얼마나 잘돼? 는 이 소프트웨어가 다양한 변화무쌍한 환경에 대해 얼마나 잘 대비가 되어있는지를 물어보는 것입니다.
지구상에는 많은 만들어내는 직업들이 있습니다.
오프라인 공장에서 실제로 물건을 생산하는 일들, 옷을 만들거나 키보드를 만들거나, 메인보드 기판을 만들거나 하는 일이 있습니다.
이런 직업들은 공장에서 설계도에 의해서 한번 생산이 되고 나면 양산작업을 시작합니다.
그래서 설계도라는 것이 확실해야하고 이 설계도에서 벗어나게 생산하거나, 설계도가 잘못만들어진다면 제품이 제대로 동작하지 않아서 큰 손실을 보게 됩니다.
반면 IT소프트웨어 개발자가 생산하는 제품은 코드 그 자체입니다.
코드는 필기구도 아니고 타이핑으로 쉽게 쓰고, 쉽게 수정할 수 있습니다.
따라서 공장에서 제품을 생산하듯 딱딱하고 변화에 대해 유연하지 않도록 설계하지 않을 수 있다는 굉장한 장점이 있고, 이것이 개발자가 하드코딩을 꺼리는 이유입니다.
그런 부분이 하드코딩만 있냐하면 그런 것은 아닙니다.
OOP를 공부해보셨다면 아시겠지만 절차지향 개발시절에는 Interface라는 것이 없었기에 컴파일 타임과 런타임이 거의 동일하게 구성되었습니다.
하지만 OOP를 지원하는 언어는 Interface라는 개념을 도입하여 절차지향처럼 코딩하지 않고 OOP 방식으로 코딩할 수 있게 되었습니다.
예를 들어 if-else로 되어있는 수많은 절차지향식 코드를 Interface를 이용해서 변하는 부분과 변하지 않는 부분을 분리하여 개발할 수 있게 되고 지금 말한 이 Interface를 도입한 방식이 바로 OOP를 절차지향 개발과 구분짓는 가장 큰 특장점입니다.
디자인 패턴이라고 불리는 일반적인 개발 방식은 이 Interface를 근간으로 한 패턴들이 상당히 많이 있습니다.
C에서 넘어오면서 C#의 BCL적인 부분 (C++라면 STL)에만 의존하여 생산성이 좋다고 하시는 분들은 C#을 100%활용하시지는 못하는 것이죠.
그러면 이 Interface를 활용한 OOP의 일반적인 개발 방식이 왜 중요하냐면, 앞서 말한 미래의 나, 또는 동료의 시간을 절약해주기 위한 하나의 배려의 개념이기 때문입니다.
우리는 학교에서, 또는 개발지식을 쌓을 때, 면접준비를 할 때, 정보처리기사 필기를 공부할 때 GoF라는 4명의 컴퓨터 과학자들이 집대성한 디자인패턴이라는 것을 들어볼수밖에 없고 이 디자인패턴은 기본적으로 OOP를 근간으로 하고 있습니다.
일반적인 지식이라고 할 만큼 시중에서 흔하게 구할 수 있고 즐비한, 빅테크기업에서 검증된 이론이라는 것입니다. 그것을 기본적으로 탑재해서 오는데 현업에서, 회사는 연구개발하는 곳이 아니고 일을 하러 오는 곳이라는 둥 내가 모르는 거 하지마 라는 둥 OOP언어를 OOP처럼 쓰는 것을 두려워합니다.
개발자 뿐 만아니라 모든 회사 직무는 대체인력을 사용할 수 있게끔 업무 파이프라인을 만들어놔야합니다.
사람이라는 것이 사고를 당할 수도 있고 불시에 어떤 일이 생겨 이직할 수 있으며 이것은 개발자만 그런 것이 아닙니다.
따라서 모든 직원이 공통된 하나의 개념을 공유하는 기반에서 대화를 시작해야만 내가 휴가를 썼을 때 내 동료가 내 코드를 커버할 수 있고, 내 동료가 휴가를 냈을 때 내가 동료의 코드를 커버할 수 있습니다.
그런데 그 공통의 개념에서 출발할 수 있는 것이 바로 아까 말한 일반적인 개발 이론들입니다.
물론 그 회사 수준에 맞는 회사 자체에 공통적인 베이스를 만들 수 있겠지요.
그런데 회사가 발전해서 신입이 들어오기 시작하고, 더 유능한 경력직을 모셔오게 되었는데, 신입은 학교에서 디자인패턴을 배워서 오고 유능한 경력직은 역시 디자인 패턴같은 일반적인 개발론을 익혀서 왔는데 이직한, 취업한 회사에서 그것을 사용하지 못한다면 아마 감당이 안되서 도망갈 것입니다.
이처럼 일반적인 개발이론은 다양한 사람의 가치관, 경력, 코드 스타일을 하나의 이론으로 일관화시켜줄 수 있는 최소한의 컨셉입니다.
모든 사람이 이것은 지켜서 개발할 때 하나의 개발문화라는 것도 챙겨질 수 있으며 회사는 회사대로 대체인력을 쓸 수 있어서 유용하고 직원은 직원대로 커리어패스가 챙겨지는 양질의 코드를 만들 수 있어서 도움이 됩니다.
나아가 이렇게 절약된 시간과 마인드는 반드시 좋은 선행의 형태로 회사의 이미지나, 동료들의 여유로운 회사생활에 좋은 이점을 가져다 줄 것입니다.
아래는 제가 OOP에 관하여 뇌절을 하면서 썼던 링크드인 업데이트 들인데 와닿으시는 문장이 있으시면 인용하셔도 좋을 거 같습니다.
7개의 좋아요
근데 개발자가 그걸 안쓸정도라면 그냥 포기해버리는 편이 좋거나
그냥 독재해야죠 그냥 저는 포기했어요 뭐 네 회사도 아니고 마음대로 해라
3개의 좋아요
사실 누구나 다 알고 있는 내용일텐데, 그러지 않는 이유를 확인해보심이 어떠신지요?
저도 FA분야에 있지만, 이 분야가 워낙 변화를 두려워하기 떄문이지 않을까 생각합니다.
만약 단순히 귀찮다는 이유로라면, 본인이 만들어서 보여주세요.
그리고 개선을 하면 더 좋지 않을까라고 보여주면서 설득하면 더 쉽지 않을까요?
3개의 좋아요
FA 분야는 아니지만 프리로 돌아다니다 보면
굉장히 고지식한 사이트 들이 있습니다.
일단 돌아가는건 안건드립니다.
새로운 패턴 도입 안합니다.
해당 부분 고도화도 안합니다.
이유를 나중에 알았어요…
현업 에서 사소한 문제라도 생기면
잘 돌아가는거 건드려서 이러는거 아니냐 부터 시작 해서
아주 난리가 나고 클레임 들어 오고 하루에 얼마씩 패널티 부과도 합니다.
그래서 아예 안건드리는 곳이 태반 입니다.
건드리지 않으면 문제도 안생긴다는게 그들의 시각 입니다.
6개의 좋아요
설득 안됩니다.
설득 시도하는 순간부터 힘들어집니다.
5개의 좋아요
설득 안 되는 사람한테 시간을 허비하지 마세요.
하고자 하는 사람들한테 시간과 투자를 하시면 됩니다.
2개의 좋아요
되면 그만이라고 생각하는 경우가 흔해서
1개의 좋아요