나는보고 있었다/고토에서 모듈 형 모노리스에 사이먼 브라운이 위대한 이야기를 듣고 2018.
이에서 그는 카고 컬트 프로그래밍이라는 용어를 언급하고 정말 나와 함께 화음을 쳤다.
나는 최근에 새로운 프로그래밍 언어,새로운 도구,새로운 프로세스 및 새로운 팀과 함께 새로운 회사에 합류했습니다. 사실,그것은 거의’새로운’모든 것입니다.
이로 인해 최근 몇 달 동안 많은 학습을하게되었습니다. 상대적으로 경험 되 고,나는’왜’보다는’괜 찮 아 요’새로운 것을 배울 때 보고 싶어요. 내가 깨달은 것은 이것이 가장 일반적인 접근 방식이 아니라는 것입니다.
사용자가 기존 코드베이스에 추가하고 현재 솔루션을 확장하는 임무를 맡을 때,그들은 아마도 이것이 이전에 어떻게 수행되었는지 확인하고 솔루션에 대한 접근 방식을 복사 할 것입니다. 그들은/맹목적으로 그것이 이전에 수행 된 방법으로이 패턴을 따를 수 있습니다. 추가 블록은 할 수있는 옳은 일인지 의문을 제기하지 않고,타워의 상단에 추가됩니다. 모두가 그렇게한다면,이것은 결국 일어날 것입니다.
이것은 용어’화물 컬트 프로그래밍’에서 오는 곳입니다.
위키백과는 다음과 같이 설명합니다:
화물 컬트 프로그래밍 스타일입니다 컴퓨터 프로그래밍 실제 목적을 제공하지 않는 코드 또는 프로그램 구조의 의식 포함을 특징으로합니다. 카고 컬트 프로그래밍은 일반적으로 해결하려고 시도한 버그 또는 명백한 솔루션(샷건 디버깅,딥 매직 비교)을 이해하지 못하는 프로그래머의 증상입니다. 용어 카고 컬트 프로그래머는 미숙 한 또는 초보자 컴퓨터 프로그래머(또는 문제의 경험이없는 사람)가 작동 방식 또는 새로운 위치에 필요한지 여부를 거의 또는 전혀 이해하지 못하고 일부 프로그램 코드를 한 곳에서 다른 곳으로 복사 할 때 적용될 수 있습니다.
카고 컬트 프로그래밍은 디자인 원칙의 이유를 이해하지 않고 맹목적으로 디자인 패턴이나 코딩 스타일을 적용하는 관행을 나타낼 수도 있습니다. 예를 들어 자명 코드에 불필요한 주석을 추가하거나,특정 프로그래밍 패러다임의 규칙을 지나치게 준수하거나,가비지 수집이 자동으로 수집했을 개체에 대한 삭제 코드를 추가하는 것입니다.
오류를 일으키는 코드를 찾는 버그를 작업하는 시나리오를 상상해보십시오. 당신은 무슨 일이 일어나고 있는지 대규모로 확실하지 않다,그래서 당신은;
- 구글 오류.
- 스택 오버 플로우 질문을 찾습니다.
- 가장 높은 답을 검색합니다.
- 솔루션을 복사하여 코드에 붙여 넣습니다.
- 디버깅을 시도하여 문제가 해결되었는지 확인합니다.
그것은,그래서 당신은 그것을 확인하고 이동합니다.
익숙한 소리?7074
왜 그럴까요? 왜 우리는 맹목적으로 이 스 니펫을 사용하여 구현에서 그대로 사용합니까?
사용 사례는 아마도 동일하지 않으므로 솔루션이 있다면 놀랄 것입니다. 간단한 예는 제쳐두고 솔루션 뒤에 숨겨진 추론을 이해하는 것이 솔루션 자체보다 더 중요합니다. 너가 너가 이해하지 않는 무언가에 할 많은 것 있는다. 수정,개선 또는 테스트 할 수 없습니다. 당신은 그것을 문서화 할 수 없으며 소유 할 수 없습니다.
우리 모두는 새로운 것을 좋아하고 경영진은 특히 기술 발전을 따라 가면서 인기있는 트렌드를 따르는 것을 좋아하는 것 같습니다.
대부분의 팀은 이제 민첩한 접근 방식을 따를 것입니다. 지속적인 통합은 인프라 팀에서 많은 오버헤드를 제거하고,빅 데이터와 인공지능은 사용자 만족도와 컨테이너화를 크게 개선할 수 있으며,최근 마이크로서비스는 기존 모노리스 아키텍처를 더 작은 독립형 서비스로 전환할 수 있습니다.
이러한 발전은 각각 그 자체로 훌륭하며,나는 그 중 어느 것도 용납하지 않습니다. 내 곤경은 우리가 우리의 모든 프로세스와 코드에 그들 모두를 채택 할 필요가 있는지 여부입니다? 우리는 넷플릭스,페이스 북,트위터의 블로그 게시물이 그들의 사용이 어떻게 작동하는지 어떻게 변화 시켰는지 보여줍니다.. 큰 회사가 그들을 필요하다고 판단하는 경우,우리는 너무해야? 화물 컬트 프로그래밍이 다시 추한 머리를 기르는 곳이다.
우리는 현재의 설계의 문제점,왜 발생했는지,미래에 어떻게 버려질 수 있는지 이해할 필요가 있다. 그렇습니다,이 새로운 과정은 우리의 문제에 저희를 도울지도 모르지만,감도불량한 희망에서 그(것)들을 맹목적으로 따르는 것은 방법 앞으로 이지 않으며,도 아니다 어떤 논리적인 이해되는가.
나는 마이크로 서비스를 특히 많은 회사들이 다음과 같은 이점을 인용하여 전환하고있는 것으로 언급한다:
- 빠른 개발 시간
- 높은 확장성
- 쉬운 강화
- 배포의 용이성
- 기술 선택의 자유를 가진 자율적 팀
이와 같은 목록을 통해 생각할 점은 무엇입니까? 시류에 모두 뛰어 보자!
잠깐…이 접근법에 단점이 있습니까?
- 아키텍처의 복잡성
모놀리식 아키텍처에서는 복잡성과 종속성의 수가 코드 기반 내에 있는 반면,마이크로서비스 아키텍처에서는 복잡성이 특정 도메인을 구현하는 개별 서비스의 상호 작용으로 이동
- 운영 복잡성
- 확장 가능하고 비용 효율적인 방식으로 리소스를 프로비저닝하는 방법
- 노력을 곱하지 않고 수십 또는 수백 개의 마이크로 서비스 구성 요소를 효과적으로 운영하는 방법
- 표준 부족 및 이기종을 처리하는 방법 다양한 기술과 서로 다른 기술 세트를 가진 사람들을 포함하는 환경
- 버전 관리 처리 방법
- 전체 시스템에서 상호 작용을 추적하고 디버깅하는 방법
- 수백 개의 코드 배포 파이프라인과 상호 의존성을 추적하는 방법
이는 아마존의”마이크로 서비스의 도전”백서에서 해제됩니다. 지금 나는 당신에 관하여 모른다,그러나 결점은 이득 보다는 저에게 많게 더 무섭게 본다. 다시 한번,나는 이것이 내려갈 적당한 접근이 아니다는 것을 말하고 있지 않다,그러나 이 이득이 결점을 중요하면 않는 한 당신은 이 접근을 따르기에서 얻고 있는 무엇?
‘공개’문제.
정말 간단합니다.공개 키워드 사용을 중단하고 공개 클래스를 자동으로 생성하지 마십시오. 우리는 왜 그것을 합니까?
공용 키워드를 사용하는 문제는 캡슐화와 관련된 이점을 놓치고 있다는 것입니다. 왜 우리는 그것을 그렇게 많이 사용합니까? 클래스를 만들 때 사용하는 기본 단어는 거의 모든 예제가 공용 클래스를 사용하고 마법사와 스 니펫은 공용 클래스를 구현합니다. 그것은 중지 할 시간이다. 얼마나 많은 사람들이 공개 페이스 북 계정을 가지고?? 이 세상의 대부분의 것들은 우리 수업이 그렇듯이 사적인 것입니다. 기본적으로 비공개로 설정 한 다음 공개해야 할 경우 변경하십시오.
좋은 경험을 가진 큰 불안이 온다.
필드에 오래 있을수록 새로운 도구나 프로세스가 가져올 개선을 인지하는 것이 덜 순진합니다. 오늘날의 아이디어의 대부분은 마침내 받아 들여지고있는 분야에 대한 수십 년의 오래된 연구에서 비롯된 것입니다. 일단 무언가가 대량 채택을 얻으면,그것을 완전히 포용하는 것에 편안함을 느끼는 것이 더 쉽습니다. 즉,그것이 옳은 일이라면.
“좋은 판단은 경험에서 비롯되며,경험은 나쁜 판단에서 비롯됩니다.”
-리타 메이 브라운
그들이 일하는 까 왜 다만 명심하십시요,오히려 간단하게 어떻게 있으십시요. 우리는 모두 우리의 자신의 경험 및 과오에서 배운다,그래서 기초를 이해함것은 동일한 경로의 아래 계속에서 너를 앞으로는 지킬 것이다.