Clojure를 다시 사용 하시겠습니까? 이 회사들은 그렇습니다. 그리고 여기에 이유가 있습니다

“Clojure in Product. 다시 할 수 있습니까?” 팟 캐스트, 우리는 성장의 현실, 진화 요구 사항 및 기술 선택의 장기적인 영향에 직면 한 팀을 만났습니다. HolidayPirates, Cycognito, Red Planet Labs, Mobot, Juston 및 Metabase의 리더들과의 대화는 Clojure가 신혼 여행 단계뿐만 아니라 시스템이 성숙하고 팀이 규모로 규모 될 때 어떻게 수행되는지를 보여줍니다.

스케일링 도전과 정직한 반성

대화가 진행됨에 따라 우리는 성공과 함께하는 복잡성을 다루는 팀을 만났습니다. 등장한 그림은 균일하게 장미 빛이 아니 었습니다. 이것은 진정한 업적과 함께 실제 도전에 대한 정직한 토론이었습니다.

성장이 다른 관점을 가져올 때

Cycognito에서 Yehonathan Sharvit의 팀은 Clojure에서 사이버 보안 플랫폼을 거의 전적으로 구축하여 주요 기업의 디지털 자산을 매핑하는 동안 초당 수백만 개의 이벤트를 처리했습니다. 그러나 성공은 예상치 못한 팀 역학을 가져 왔습니다.

“나는 대부분의 개발자들이 Clojure를 좋아하지 않는다고 생각한다”고 Sharvit은 솔직하게 인정한다. 이 문제는 기술적 인 능력이 아니 었습니다. 경력 불안이었습니다. 일부 개발자들은 시장성에 대해 걱정했습니다. “다른 회사에 가입하려면 최신 JavaScript, React, Webpack 모듈을 알지 못합니다.”

그것은 많은 Clojure 팀이 직면 한 현실을 강조합니다. 경험이 풍부한 개발자들에게 매력적으로 만드는 안정성은 주류 트렌드로 현재를 유지하는 것에 대한 불안을 일으킬 수 있습니다.

마이그레이션 질문

몇몇 팀은 Clojure에서 멀어지면서 그러한 결정이 언제, 왜 발생하는지에 대한 귀중한 통찰력을 제공하는 것을 고려한 것을 발견했습니다. Cycognito는 시스템의 일부를 기술적 한계로 인한 것이 아니라 채용 및 전문 지식 유지에 대한 조직의 우려 때문입니다.

Mobot의 Jereme Corrado는 시리즈 A 펀딩 라운드에서 비슷한 압력에 직면했습니다. “우리는 Clojurescript 기반 프론트 엔드를 끊고 TypeScript와보다 광범위하게 수용된 솔루션으로 이동해야합니까?” Clojure를 고수하기로 한 그들의 결정은 이론적 이점보다는 입증 된 결과를 기반으로했습니다.

패턴은 분명합니다. 이러한 압력은 기술 부적합이 아니라 팀 빌딩 및 장기 유지 보수를 둘러싼 비즈니스 고려 사항에서 비롯됩니다.

규모의 아키텍처

우리 시리즈에서 가장 야심 찬 프로젝트는 복잡한 장기 개발 노력을 지원하는 Clojure의 능력을 보여주었습니다.

새로운 패러다임 구축

Rama를 개발하는 Nathan Marz의 10 년 동안의 여정은 Clojure가 어떻게 기본 혁신을 가능하게하는지 보여줍니다. 2013 년 연구로 시작하여 Rama는 이벤트 소싱 및 구체화 된 견해를 일반화하는 플랫폼이되었습니다. Marz는 다른 언어에서 실용적이지 않았을 것입니다.

“나는 라마가 다른 어떤 언어로도 실용적이지 않았을 것이라고 생각한다”고 그는 설명했다. 불변성 징계와 결합 된 매크로를 사용하여 Clojure 내에서 새로운 프로그래밍 패러다임을 정의하는 능력은 소규모 팀과 10 년의 R & D 노력을 관리 할 수있게되었습니다.

그들의 구현은 궁극적으로 200,000 줄의 Clojure 소스 코드와 250,000 줄의 테스트로 구성되었지만 5 인 팀은 유지 관리 가능하고 이해할 수있었습니다.

복잡성과 자유 관리

Juston의 Alexander Johannes는 Salesforce 전용 회사에서 자체 Clojure 플랫폼을 구축하는 것에 이르기까지 자신의 진화를 설명합니다. 전환은 Clojure의 힘과 잠재적 인 함정을 모두 보여 주었다.

요하네스는“당신은 열린 분야에있다. 당신은 경계가 없지만 의미있는 일을하기 위해서는 다시 한계가 필요하다”고 말했다. 적절한 구조가 없으면 팀은 자신이 “혼란”이라고 부르는 것으로 끝날 수 있습니다.

그들의 솔루션은 Clojure의 유연성을 위해 명시 적으로 설계된 명확한 건축 지침과 엄격한 코드 검토 프로세스를 개발하는 것이 포함되었습니다. 자유가 징계를 요구한다는 주요 통찰력입니다.

가르침과 학습

모든 대화에서 가장 고무적인 패턴 중 하나는 팀이 종종 0부터 시작하여 팀이 Clojure 전문 지식을 성공적으로 성장시키는 방법이었습니다.

실용적인 온 보딩

Juston에서 그들은 체계적인 접근 방식을 개발했습니다. “Clojure를 배우는 가장 중요한 것은 Clojure 코드를 읽는 것입니다.” 긴 교육 프로그램보다는 새로운 개발자를 숙련 된 팀원과 짝을 이루고 즉시 실제 문제를 해결하게합니다.

결과는 스스로 말합니다. 학생으로 일하면서 Clojure를 첫 번째 전문 언어로 배운 한 개발자가 있었으며 몇 년 후 회사와 함께 있습니다.

공동 학습

Mobot의 Jereme Corrado 팀은이를 더욱 차지하여 전체 분대 전체가 언어를 함께 탐구 한 “Clojure Learning”회의를 만들었습니다. 이 협업 접근법은 학습 과정을 정규화하고 조직 전체의 공유 이해를 창출했습니다.

“우리는 한 번에 두 명의 개발자를 고용했습니다. 40 명의 지원자가 많았습니다.

실제로 생태계

우리의 대화는 팀이 Clojure의 생태계를 탐색하는 방법과 언어 안정성 대 혁신에 대한 광범위한 질문을 공개했습니다.

기능으로서의 안정성

“정체 된”도서관에 대한 일반적인 불만은 성공적인 팀의 작동 방식을 이해할 때 다른 의미를 갖습니다. 대사에서 캠 사울은 완벽하게 말합니다.

“Clojure에서, 당신은 갈 것이고 2 년 동안 아무도 만지지 않은 것을 찾을 수 있습니다. 그리고 당신은 정말 잘 작동한다고 생각합니다.”

이 안정성은 개별 라이브러리를 넘어 확장됩니다. 대사는 수년간 링 및 컴포지트를 성공적으로 사용해 왔으며, 과거에 갇혀 있었기 때문이 아니라 이러한 도구가 문제를 계속해서 해결하기 때문입니다.

견고한 기초를 기반으로합니다

Alexander Johannes는 비즈니스 관점에서 이러한 안정성을 높이 평가합니다. “안정성이 항상 좋은 것을 알고 있기 때문에 안정성이 항상 좋습니다.” 수년에 걸쳐 소프트웨어를 유지하는 회사의 경우이 예측 가능성은 실제 가치가 있습니다.

JavaScript의 생태계와 대조적입니다. Cam Saul은 다음과 같이 지적합니다.

오픈 소스와 커뮤니티

주요 오픈 소스 Clojure 프로젝트로서의 Metabase의 여정은 언어가 공개적, 공동 작업 개발에서 수행하는 방식에 대한 독특한 통찰력을 제공합니다.

가시성을 통한 품질

사울은“우리 코드를 바라 보는 것이 아니라 세상의 모든 사람이 그것을보고있는 모든 사람이다. 이 가시성은 코드 품질과 문서에 대한 양압을 만듭니다.

Clojure 기고자들의 자체 선택 특성은 분명해졌습니다. “우리는 Clojure에서 그 정도를 다룰 필요가 없습니다. 어떤 사람들은 Python 프로젝트를 가지고있는 것처럼 Python 코드를 작성하려고하지만 많은 사람들은 그렇지 않습니다.”

기고자로부터 동료까지

Metabase는 풀 요청을 제출하여 시작한 여러 기고자를 성공적으로 고용했습니다. 이것은 Clojure를 이해할뿐만 아니라 특정 코드베이스와 함께 일할 수있는 능력을 보여준 개발자를 찾기위한 자연스러운 파이프 라인을 만듭니다.

장기 지속 가능성

가장 설득력있는 통찰력은 Clojure에서 수년간의 경험을 가진 팀에서 비롯되며, 초기 결정이 시간이 지남에 따라 어떻게 결합되는지를 보여줍니다.

경쟁력있는 이점

Juston에서 Alexander Johannes는 예상치 못한 혜택을 발견했습니다. “회사로서 Clojure를 테이블에 가져 오면 개발자의 특정 부분에 다시 매력적입니다.” Clojure는 채용 풀을 제한하기보다는 동기 부여 된 개발자를 유치하는 데 경쟁력있는 우위가되었습니다.

이것은 다른 회사의 특성을 반영하는 것 같습니다. Clojure는 자신의 작업에 관심이 있고 새로운 방법을 배우는 가격을 기꺼이 지불하려는 개발자들을 끌어들이는 필터입니다.

생산성 보상

Metabase의 성장 이야기는 Clojure의 생산성이 어떻게 복합 적인지를 보여줍니다.

그들은 4 명으로 시작하여 훨씬 더 큰 팀이 구축 한 엔터프라이즈 솔루션과 경쟁하는 제품을 구축하면서 소규모 팀을 유지했습니다.

“Clojure는 우리가 작은 팀과 함께 많은 일을 할 수있게 해줍니다.”라고 사울은 말합니다. “우리는 일찍 500 명으로 확장해야한다는 압력이 없었습니다. 우리는 작은 팀과 함께 많은 물건을 배송 할 수있었습니다.”

기대합니다

우리 시리즈의 마지막 대화는 Clojure의 궤적에 대한 현실적이고 낙관적 인 그림을 그렸습니다. 우리는 폭발적인 성장보다는 가치 제안을 이해하는 팀의 꾸준한 채택을 본다.

무엇이 성공 사례의 모음 일뿐 만 아니라, 사려 깊은 기술 선택이 지속 가능한 경쟁력있는 이점을 만드는 방법의 패턴입니다. Clojure를 선택하는 팀은 프로그래밍 언어를 얻는 것이 아니라 단순성, 합성 가능성 및 장기 유지 가능성을 강조하는 개발 철학을 얻습니다.

“다시 하시겠습니까?”라는 질문이 있습니다. 우리의 모든 손님에서 일관된 답변을받습니다. Cam Saul이 다음과 같이 요약 한 바와 같이, “소수의 사람들이 얼마나 빨리 일을 할 수 있고 그것이 당신에게 어떤 힘을 줄 수 있는지 … 그것은 작은 팀이 정말로 일을 빨리 끝낼 수있게 해줍니다.”

이 10 가지 대화는 Clojure의 진정한 가치가 단일 기능에있는 것이 아니라 팀이 더 적은 사람, 복잡성이 적고 실제 문제를 해결하는 데 더 집중할 수있는 지속 가능하고 확장 가능한 시스템을 구축 할 수있게하는 방법에 있습니다. 업계에서 종종 최신 트렌드에 집착하는이 팀은 훌륭한 소프트웨어를 구축하기위한 안정적인 기초 인 더 가치있는 것을 발견했습니다.