은행 세계에서 코드 설계 노력 또는 게으름을 선택하십시오

저는 훌륭한 투자 은행에서 2 년간 일했습니다.

적절한 디자인 패턴, SOLID 원리, 데 미터 법칙을 존중하고 모든 종류의 중복 코드를 피하면서 가장 최적화 된 코드를 만들고자하는 기술 프로젝트를 만들었습니다.

프로덕션에서 제공 => 버그가 0이면 모든 것이 예상대로 발생했습니다.

그러나 대다수의 개발자가 모든 코드가 이해하기에 너무 복잡하다는 것을 정확하게하기 위해 나에게 왔습니다. 예를 들어, "만약 ifif와 instanceof를 만들고, 다형성을 잊어 버리면 긴급 생산 버그를 수정하는 것이 매우 쉬워집니다"라고 들었습니다. 나는 대답하는 것을 선호하지 않았다 ...

좋은 개발자를 이해하려는 노력을 거부하면서이 개발자들에 대해 전혀 궁금하지 않습니다. 예를 들어, 개발자의 90 %는 전략 패턴이 무엇인지 알지 못하고 절차 코드를 작성하고 결코 설계하지 않기 때문에 설계를하지 않습니다. ), 프로젝트 관리자는 내가 실제로 잘못된 방식으로 은행계에 너무 이상적이라고 말했습니다.

나에게 무엇을 조언 하시겠습니까? 정말 좋은 코드를 원하거나 대부분의 개발자에게 저를 적응시켜야한다면, 개발자의 모든 아름다움에 따라 나에게 맞는 디자인 코드로 흥미롭지 않습니다.

또는 반대로, 그들은 내 코드에 적응하기 위해 기본적인 OO 원칙과 모범 사례를 배워야합니까?

저의 프로젝트 관리자들은 제가 실제로 잘못된 방식으로 은행계에 너무 이상적이라고 말했습니다.

GTFO!

떠날 시간과 동정. 왜 섹스를해야합니까? 무능한 직원과 장기적으로 비용이 많이 든다는 것을 알고 있습니다. 이것은 기술적 인 토론 게임이 아닙니다. 이것은 정치에 관한 것입니다. 다른 개발자 나 GTFO를 훈련 시키십시오! 정치적인 무게가 충분하지 않으면 GTFO! 모범 사례가있는 회사를 검색하십시오.

머무는 유일한 이유는 두통에 대한 적절한 보상입니다. 그래서 그들은 평균 또는 GTFO보다 더 나은 방법을 지불합니다! 소프트웨어 개발자로 성장할 수 있을지 의심됩니다. 우리 직업의 성장은 대부분 자신보다 나은 사람과 모범 사례를 장려하는 사람들과 함께 일함으로써 달성됩니다. 그리고 당신이 더 나은, 관심 회사에 대한 시장 가치가 높습니다.

그래, 나는 이것이 나의 일반적인 대답 중 하나가 아니라는 것을 알고 있지만 실제로이 회사 GTFO에서 정치 게임을 할 수 없다면.

나에게 무엇을 조언 하시겠습니까? 정말 좋은 코드를 원하거나 대부분의 개발자에게 저를 적응시켜야한다면, 개발자의 모든 아름다움에 따라 나에게 맞는 디자인 코드로 흥미롭지 않습니다.

차선책의 솔루션을 제공하려는 회사에서는 일하지 않을 것입니다. 소프트웨어에 내 이름을 새기고 싶습니다. 자랑스럽게 생각합니다. OO 패러다임을 기반으로 한 언어로 절차 적 응용 프로그램을 작성하지 않습니다. 나는 고품질의 소프트웨어를 믿고 회사가 그렇지 않다면 GTFO를 할 것이다! 당신이 "돈을 버는 것"을 충분히 얻었기를 바랍니다.

힘든 곳. 나는 당신이 두 가지 방법으로 동시에 갈 수 있다고 생각합니다.

• 이것은 돈에 관한 것입니다. 실제로 모든 개발 작업으로 은행 환경을 강조하기 때문에 더 잘 작동합니다.). 당신의 스타일이 돈을 절약한다는 것을 보여주십시오. 설계로 인해 요구 사항을 실제로 쉽게 변경하는 방법에 대한 예를 찾으십시오. 조만간 깨지기 쉬운 다른 코드를 찾아보십시오 (여기서는 너무 공격적이지 않아야하지만 코드 스타일을 비교하는 것과 관련이 있습니다). 코드의 품질이 더 좋기 때문에 이러한 문제에주의하십시오.

• 이것은 돈에 관한 것입니다. 코딩 스타일에 실제로 비용이 든다면 어떻게해야합니까? 다른 사람들이 적절한 디자인으로 저장되는 것보다 코드를 이해하는 데 더 많은 시간을 할애하는 것이 좋습니다. 기술적으로 올바른 일을하고 있지만 팀 노력에 긍정적으로 기여하지는 않을 것입니다. 또한 OOP 설계를 과도하게 수행 할 수 있습니다. 나는 "좋은 디자인은 아름답다"는 측면에서 당신과 함께 있습니다. 그러나 저는 여러분이 그들의 관점과 그들이 실제로 그들의 관점에서 어떻게 옳을 지 알고 자 노력하고 있습니다. 이전 지점과 병행하여이를 과장 한 지점을 찾으십시오. 그것은 당신에게 기동의 여지를 제공합니다 : 당신은 말할 수 있습니다. 여기저기서 좀 더 실용적이 될 수 있지만,이 코드가 더 나은 곳도 있습니다.

그러나 대다수의 개발자가 모든 코드가 이해하기에는 너무 복잡하다는 사실을 정확하게 이해하기 위해 나에게 왔습니다.

그들이 옳을 수도있는 일이 당신에게 일어 났습니까?

나는 그가 우아하다고 묘사 한 코드를 작성하는 데 많은 노력을 기울인 누군가와 함께 일했습니다. 그는 다른 사람들의 작품을 우아하지 않은 것으로 돌리는 데 많은 시간을 보냈습니다. 코드를 유지 관리해야 할 때 그의 코드는 수정하려고 선택한 코드가 아닙니다. 너무 정확하고 정확하여 변경하면 위험이 따릅니다.

여기서 언급 한 흥미로운 단어는 "복잡한"입니다. 복잡한 것으로 설명 될 수있는 코드 는 특히 좋은 것으로 설명 될 수 없습니다.

빅토리아 시대의 가구 제조업체 (적어도 오늘날 우리가 볼 일을하는 사람들)는 실제 장인이었고, 그들이 만든 것은 기능적이고 아름답고 잘 만들어졌으며 평생 동안 지속되도록 설계되었습니다. 그러나 지난 150 년 동안 세상은 바뀌 었습니다. 식당 테이블을 구입할 때 더 저렴한 대안이 상업적으로 실용적 일 때 그러한 장인 정신을 지불 할 사람이 많지 않습니다.

많은 프로그래머들이 불행히도 노예의 장인이되기를 원하며 이것이 항상 일어날 수는 없다고 말합니다. 선택, 적응 또는 탈퇴가 있습니다. 장인을 원하는 회사가 있지만 대부분 저렴하고 현재 작동하는 제품을 원하는 회사보다 훨씬 많습니다.

대부분의 상용 소프트웨어 개발에 적합하지 않다는 힌트는 "제작시 배달 => 제로 버그"입니다. Nasa조차도 우주 왕복선으로 달성하지 못했습니다.

세부 사항에주의를 기울여 초기 비용을 수용 할 수있는 유일한 장소는 항공 전자 / 항공 우주, 자동차, 군사 및 의료와 같은 수준 1의 생명에 중요한 시스템입니다.

문제는 당신이 잘못된 곳에서 일하고 있다는 것입니다. 학문적으로 기울어 진 프로그래머 인 것 같습니다. 당신은 당신이있는 환경에서 잘하지 않을 것이고 당신과 당신의 "너무 복잡한"코드를 제거하기위한 변명이 생길 것입니다. 정크 할당 및 / 또는 열악한 성능 검토가 제공 될 수도 있습니다.

학업 적 기대에 가치가있는 일할 곳을 찾는 것이 좋습니다. 저기 있어요 당신은 또한 실용적이고 학문적 인 사이에 울타리에있는 것을 찾을 수 있습니다. 이와 같은 직업은 다른 사람들이 자신의 문제를 해결하는 데 도움이 될 때 혼돈을 당신의 접근 방식으로 초대 할 수 있기 때문에 최선의 선택 일 수 있습니다.

고용주 변경과 같은 과감한 조치를 취하기 전에 경영진과 같은 프로그래머가 아닌 사람들에게 코딩 방식이 회사에 더 좋은 이유를 설명하고 시간과 돈을 절약하는 자신의 능력을 향상 시키려고 노력합니다. 또한 디자인 패턴을 위해서만 디자인 패턴을 적용하지 않았는지 확인하십시오. KISS 및 YAGNI의 규칙도 준수 했습니까? (오케이, 전략 패턴과 다형성은 로켓 과학이 아닙니다. 동료에게 왜 그 접근 방식을 선택 했는지 설명하고 설명 할 시간을주십시오 .)

우리 회사에서는 Clean Code Developer를 기반으로 일련의 워크샵을 진행했습니다 . 목적은 개발자가 소프트웨어 설계 원칙 (예 : 언급 한), 프로그래밍 기술 등에 대해 배우고 프로젝트 및 그들 자신의 일.

실제 프로젝트의 실제 사례도 논의되었습니다. 참가자들의 의견은 AFAIK 매우 긍정적이었습니다. 그러나 실제 혜택을 측정하기는 어렵습니다.

이 워크숍에 참석 한 것은 회사가 후원하는 시간, 참가자의 여가 시간에 일부있었습니다. 학습에 신경 쓰지 않고 단순히 일을하고 집에 가고 싶어하는 동료들에게 다가 가지 않을 것입니다. 그러나 자신의 일에 관심이있는 다른 사람들에게는 이것이 흥미로울 수 있습니다.

나는 우선 당신의 길이 정말로 더 낫다는 것을 확인합니다. 객체 지향 코드는 매우 훌륭하지만 숨겨진 부작용으로 인한 악몽이 될 수 있으며 모든 작업에는 여러 가지 클래스가 필요할 수 있습니다.

InfoQ로 이동하여 Rich Hickey의 "Simple Made Easy" 에 대한 이야기를 시청하십시오.

끊임없는 노력없이 계속 일하고 싶다면 조금만 주어야합니다. 모든 절차적인 개발자 그룹은 다형성을 즉시 받아들이지 않을 것입니다. OO 방식으로 디자인 할 수는 없지만 코드에서 배울 수 있습니다. 그들은 일부 코드를 유지 관리하기가 쉽다는 것을 이해할 수도 있습니다.

참고로, 취향에 맞는 것이 중요하다고 생각되면 인터뷰 프로세스 중에 질문을하여 어떤 개발 프로세스 및 코딩 방법이 사용되는지 확인해야합니다.

비상 사태가 발생합니다. 당신은 완벽하지 않으며 그들의 손 이 어느 시점에서 코드를 망칠 것입니다. GP가 확인 하듯이 시간을 절대로 쉬지 않으면 건강에 좋지 않습니다. 그리고 코드가 잘못 생성 될 가능성이 높아집니다.

코드의 품질이 더 높을 수도 있지만 (증명되지 않은) 정책이 있습니다. (지독한 사실)

정책을 준수하라는 경고를 받았으며 해당 정책을 따르지 않을 책임이 있습니다. 긴급 상황에서. 은행 응용 프로그램에서. 만약 내 말은, 당신의 목표는 가난한 사람들을 종료하고 감옥에 나는 같은 결과로 얻을 수있는 많은 더 재미보다 의미있는 방법을 알아낼 수 있습니다.

하지만 동료 직원 들은 이전 동료 의 호기심 이 부족하다는 사실 을 듣고 기뻐할 것 입니다.

(귀하의 회사는 아마도 OO 디자인에 대한 내부 정책이 없을 수도 있지만 코드를 수정하려고하는 서투른 코볼 훈련 엔지니어는 약간의 공기를 만들어 내고 최악의 경우 IMHO는 치명타 명중률이 40 %입니다.)

프로그래밍은 자신을 위해서가 아니라 목적을위한 수단으로 프로그래밍을 고려한다는 것을 기억하십시오. 사용하는 모든 제품과 서비스를 생각해보십시오. 아래 코드가 우아하게 작성되는지 고려하는 데 많은 시간을 소비하십니까? 아니면 그들이 일하는 것처럼 단순히 감사합니까? 열정을 갖고있는 산업이나 원인을 찾은 다음 해당 조직을 찾은 다음 프로그래밍뿐만 아니라 그 외에 다른 솔루션을 제공하십시오 . 여러 가지 방법으로 문제를 훌륭하게 해결할 수 있습니다.