paint-brush
소프트웨어 아키텍처 결정: 사실에 집중하고 추측하지 마세요.~에 의해@inovak
452 판독값
452 판독값

소프트웨어 아키텍처 결정: 사실에 집중하고 추측하지 마세요.

~에 의해 Ivan Novak4m2023/07/28
Read on Terminal Reader
Read this story w/o Javascript

너무 오래; 읽다

YAGNI는 익스트림 프로그래밍에서 탄생한 원리입니다. 이는 본질적으로 필요하다고 판단될 때까지 기능을 추가하지 말라는 친절한 알림입니다. 스미티처럼 되지 마세요. 필요할 때 필요한 것을 구축하세요. Slack처럼 되세요. 사용자의 요구에 따라 소프트웨어 아키텍처 결정을 내리세요.
featured image - 소프트웨어 아키텍처 결정: 사실에 집중하고 추측하지 마세요.
Ivan Novak HackerNoon profile picture
0-item

당신은 아마도 작동할 뿐만 아니라 사용자를 즐겁게 하는 소프트웨어를 만들고 싶기 때문에 이 게임에 참여했을 것입니다. 그렇죠?


좋은 소식! 이것은 추측 게임이 아닙니다. 깊은 이해를 바탕으로 현명한 결정을 내리는 것입니다. 추측보다는 사실에 관한 것입니다.


"소프트웨어 아키텍처에서는 사실이 신뢰할 수 있는 동맹이지만 추측은 디지털 카드 하우스를 구축할 수도 있습니다."


그 길은 어려운 선택으로 가득 차 있을 수 있지만, 올바른 지식을 갖추면 십여 가지(또는 그 이상)의 추측보다는 자신 있게 올바른 다음 일을 구축할 수 있습니다!

YAGNI의 힘

야그니? 당신 필요 하지 않을 것입니다. 익스트림 프로그래밍에서 탄생한 원리입니다. YAGNI는 기본적으로 필요하다고 판단될 때까지 기능을 추가하지 말라는 친근한 알림입니다. 그리고 저를 믿으십시오. 그것은 매우 필요합니다.


과도한 엔지니어링은 커피를 마시며 심야 코딩 세션을 진행하는 것만큼 흔합니다. 둘 다 일어나서는 안 되지만 어떻게 되는지 아실 겁니다...


이야기를 나누겠습니다. 예전에 한 남자와 일한 적이 있는데 그 사람을 스미티(Smitty)라고 부르자. 이제 Smitty는 매우 열정적인 개발자였습니다. 그는 고객이 자전거만 요청했는데 우주선 전체를 설계한 사람이었습니다. 그것은 경외심을 불러일으켰지만 종종 그것은 불필요했습니다.


어느 날 Smitty는 고객이 한 번도 사용한 적이 없는 복잡한 기능을 개발하는 데 몇 주를 보냈습니다. 그 모든 시간, 에너지, 커피가 낭비되었습니다.


이것이 YAGNI가 피하는 데 도움이 되는 함정입니다. 스미티처럼 되지 마세요. 필요할 때 필요한 것을 구축하세요.

당신을 안내하는 별: 사용자의 요구

하지만 무엇이 필요한지 어떻게 알 수 있나요? 귀하의 소프트웨어는 귀하의 기술력을 과시하기 위한 것이 아닙니다. 사용자의 문제를 해결하는 것입니다. 당신의 길잡이 별? 귀하 또는 팀의 변덕이나 욕구가 아닌 사용자의 요구 사항입니다.


마치 잃어버린 퍼즐 조각처럼 사용자의 삶에 딱 들어맞을 만큼 매끄럽게 솔루션을 만드는 것입니다.


소프트웨어 아키텍처는 일련의 프로젝트에서 우연히 상속된 것이 아니라 전체 제품을 염두에 두고 의도적으로 고려해야 합니다. "우연히 디자인하는 것"을 피합시다.


많은 사랑을 받는 메시징 플랫폼인 Slack을 생각해 보세요. Slack을 차별화하는 점은 고객의 욕구에 초점을 맞춘다는 점입니다. 단순히 또 다른 메시징 앱이 될 운명은 아니었습니다. 업무가 원활하게 진행되는 협업 허브로 설계되었습니다.


그들은 데이터를 관찰하고, 조사하고, 대조하고, 이러한 통찰력을 우리가 없이는 할 수 없는 앱에 적용했습니다. Slack처럼 되세요. 사용자의 요구에 따라 소프트웨어 아키텍처 결정을 내리세요.

데이터 기반 의사결정의 본질

이제 정보에 입각한 결정을 내리려면 냉정하고 확실한 사실인 데이터가 필요합니다. 추측은 인생에서 필요하지 않은 적입니다. 이는 눈을 가린 채 과녁을 맞추려고 하는 것과 같습니다. 대부분은 놓치게 됩니다.


직감에 의한 결정은 동전을 던지는 것만큼이나 훌륭하지만, 성공적인 소프트웨어가 구축되는 방법은 아닙니다.


실질적으로 데이터를 숭배하는 회사인 Amazon을 생각해 보십시오. 모든 아키텍처 결정, 추가된 모든 기능, 모든 변경 사항은 고객 데이터에 대한 철저한 분석을 기반으로 합니다. 결과? 고객이 계속해서 돌아오게 만드는 초개인화된 쇼핑 경험입니다.

데이터 수집을 위한 메커니즘 구축

"이 데이터는 어디서 구할 수 있나요?" 좋은 질문! 그것을 수집하는 메커니즘을 구축하세요! 이는 직접적인 사용자 피드백만큼 간단할 수도 있고 자동화된 데이터 분석 파이프라인만큼 복잡할 수도 있습니다. 통찰력을 얻기 위해 함정을 놓는 것과 같다고 생각하십시오. 더 많이 설정할수록 더 많은 것을 잡을 수 있습니다.


즉, 데이터를 수집하기 위해 데이터를 수집하는 것이 아니라는 점을 기억하는 것이 중요합니다. 이는 사용자에게 더 좋고 유용한 기능을 제공하는 데 도움이 되는 실행 가능한 통찰력을 수집하는 것입니다. 내면의 데이터 과학자를 포용하세요!

데이터 중심, 사용자 중심 접근 방식을 향한 여정

데이터 기반, 사용자 중심 접근 방식으로 전환하는 것은 거칠게 보일 수 있지만 결과는 절대적으로 가치가 있습니다. 새로운 방법론 채택, 데이터 활용 능력 배양, 사용자 우선 문화 육성은 팀 전체의 변화입니다.


예, 어려워 보일 수도 있지만 그 결과는 더 간결하고 효율적이며 가치 중심적인 소프트웨어 개발 프로세스입니다. 올바른 일에 더 자주 집중하면 더 적은 비용으로 더 많은 것을 성취할 수 있습니다!

변화에 앞장서다

보세요, 저항이 있을 수도 있어요. 낡은 방식, 편안한 방식을 고수하는 사람들이 있을 수도 있습니다. 그러나 이것은 새로운 시대를 옹호할 수 있는 기회입니다. 추측이 아닌 사실에 따라 결정이 내려지는 미래로 팀을 이끌 수 있는 기회입니다.


개발자의 가려움을 만족시키기 위한 것이 아니라 실제 문제를 해결하기 위해 소프트웨어가 구축되는 곳입니다.

행동 촉구

첫 번째 단계는 다음과 같습니다. 작게 시작하십시오. 다음에 기능을 추가하거나 아키텍처 결정을 내릴 때 "이 결정을 뒷받침할 데이터가 있습니까? 그것이 사용자에게 도움이 됩니까, 아니면 단지 반짝이는 새로운 것입니까?"라고 질문하십시오.


훌륭한 소프트웨어는 변덕이나 직감으로 만들어지지 않습니다. 이는 정보에 입각한 결정을 바탕으로 구축되었습니다.


궁극적으로 이는 사용자에게 막대한 가치를 제공하는 것, 즉 사람들이 사용하고 사랑하며 없는 삶을 상상할 수 없는 소프트웨어를 만드는 것입니다. 그리고 당신은 그것을 할 수 있는 능력 그 이상입니다.


그러니 밖으로 나가서 사실을 수집하고, 사용자를 최우선으로 생각하고, 놀라운 소프트웨어 구축을 시작해 보세요. 사용자가 기다리고 있습니다.