여러 환경이있는 좋은 이유 우리는 서서히 철학을 바꾸기 시작했으며

내 경력을 통해 나는 다른 목적을 위해 다른 환경을 가진 회사에서 일했습니다. 우리는 항상 데스크탑 환경, 테스트 환경, QA 환경, 준비 환경 및 프로덕션 환경을 가지고있었습니다. 이것은 서버 / 애플리케이션과 우리가 사용하고있는 모든 데이터 소스에 적용되었습니다.

현재 회사에서 시작했을 때 앱의 90 %가 프로덕션 데이터 소스를 바탕으로 데스크톱 환경에서 개발되었거나 플랫폼에 따라 프로덕션 서버에서 직접 개발 된 것으로 나타났습니다. 개발 팀의 기능을 향상시키기 위해 부분적으로 고용되어 인터뷰 과정에서 분명해 졌기 때문에 이것은 놀라운 일이 아닙니다. 우리는 서서히 철학을 바꾸기 시작했으며 곧 곧 대부분의 앱이 데스크톱, 테스트 또는 프로덕션 환경에서 실행될 수 있습니다. 그 준비가 끝나고 얼마 지나지 않아.

이제 대부분의 개발자는이 방법론의 이점을보고이를 신중하게 방어합니다. 그러나 이전 된 적이없는 수많은 레거시 앱이 있습니다. 우리는 이것을 시간 낭비라고 생각하는 많은 레거시 프로그래머도 있습니다. 불행하게도, 우리는 입술 서비스를 받았지만 경영진의 완전한 바이 인은 없었습니다. 우리는 약 1 년 전에 이것에 실질적으로 투자하겠다는 결심을 가지고 있었지만 상당한 계획에도 불구하고 실현 된 것은 없습니다. 이제 우리는 점점 더 많은 환경이 필요하다는 것을 알게되었습니다. 설정을 위해 서버 / 네트워크 관리 팀의 도움이 필요하며 릴리스주기를 지원하려면 비즈니스 이해 관계자의 참여가 필요합니다. 우리는 이제 합리적인 개발자들이 “정상적으로”고려할 수있는 기능을 프로젝트가 수행 할 수있는 곳에

나는 완전한 논증을 제시하고 싶지만, 중요한 문제가 생길 때까지 경영진은 시간과 관심이 없습니다. 나는 항상 그것이 단지 제 2의 본성 인 것처럼 단순히 혜택을 분명히 말할 수는 없습니다. 개발 경험이 부족한 관리자가이 아이디어를 뒷받침 할 수있는 환경을 분리해야하는 좋고 간단하며 반박 할만한 이유 가 있는지 궁금합니다 . . 주제에 관한 좋은 자료 / 문학이 있습니까?



답변

답 :

나는 실제 이유가 무엇인지 상관하지 않습니다. 특히 경영진을 다룰 때 돈은 모든 추론의 근본 원인이어야합니다.

둘 다 2 시간 동안 방에 앉아 있다면 여러 환경을 갖는 것이 더 좋은 이유 는 수십 가지 가 될 수 있습니다.

여기에 문제가 있습니다. 이유가 돈을 바탕으로하지 않는다면 아무 것도 중요하지 않습니다 .

프로그래머는 영리하지 않습니다. 그들은 창조적으로 고용되지 않았습니다. 그들은 돈을 벌거나 돈을 절약하여 수입 을 늘리기 위해 고용되었습니다 . 이 중 하나를 수행하지 않으면 이력서를 함께 사용하는 것이 좋습니다.

그 관점에서 볼 때 대답은 간단합니다.

하나의 환경 만 있으면 가동 중지 시간이 늘어나고 매출 손실이 발생합니다. 여러 환경을 통해 사용자는 회사만큼 신뢰할 수 있고 신뢰할 수있는 프런트 엔드를 제공하여 수익을 보호 할 수 있습니다.

매일 반복하십시오.


아래 에이 답변에 실제 가치를 더하는 몇 가지 훌륭한 의견이 있으므로 언급하겠습니다.

  • Karl Bielefeldt는 비용 / 혜택 분석이 중요한 요소라고 언급했을 때 큰 지적을했습니다. 경제학자는이를 여러 환경을 추구하는 기회 비용이라고 할 수 있습니다. 듣는 것이 놀랍지 만 여러 환경이 답이 아닌 시나리오가 있습니다! 회사의 웹 사이트가 아주 작은 추가 기능인 경우 예기치 않은 다운 타임이 실제로 비즈니스를 수행하는 데있어 가장 비용 효율적인 방법 일 수 있습니다. 이것은 당신이있는 위치처럼 들리지 않지만 언급 할 가치가 있습니다.

  • BlairHippo는 재앙처럼 보이게해야한다는 점에서 좋은 점이있었습니다 (데이터를 잃어버린 경우에도 마찬가지입니다). 책임은 관리자를 설득하기위한 훌륭한 도구이지만 여전히 같은 이유로 소송이 비싸다. 그것들을 피하면 돈이 절약됩니다.


부록으로, 나는 이 기사 가 꽤 좋다는 것을 알았습니다 . 귀하의 질문에 직접 대답하지는 않지만 프로그래머가 경영진에게 어떻게 보이는지 인식 할 수있게하여 결과적으로이 답변으로 이어집니다. 잘 읽었습니다.


답변

단일 실패 지점

개발 또는 준비 환경이 없기 때문에 이러한 레거시 응용 프로그램에 대한 단일 실패 지점이 있습니다. 이러한 용어로 레거시 응용 프로그램을 설명하면 경영진이 귀하를 듣게됩니다.

메시지를 이해할 수있는 사운드 바이트로 메시지를 표시 할 수 있어야합니다. 토론 에서 ” 프로그래머 말하기 “를 꺼내고 ” 관리자 말하기 “로 바꾸 십시오 . 또한 포인트를 얻기 위해 엘리베이터를 30 초 동안 타고 가십시오.

상사가 보병 해병 인 상황이있었습니다. 생산성을 높이려면 해병대를위한 소프트웨어 도구와 컴퓨터 교육이 필요하다고 계속 말했습니다. 그는 그것을 얻지 못했습니다. 나는 마침내 어느 날 그의 사무실로 들어가서 일이 끝났다고 말했습니다.

“전쟁과 싸우면 지팡이, 바위, 나뭇 가지를 사용할 것입니다. 수류탄, 바주카포 및 기관총이 필요합니다.” 그는 메시지를 받았습니다.


답변

실제로 중요합니까?

별도의 환경을 사용하려는 욕구를 이해할 수 있습니다. 명백한 질문은 다음과 같습니다.

레거시 시스템 을 마이그레이션하는 것이 실제로 중요 합니까?

나는 기술적으로 가장 마음에 드는 사람들이 학계에서 어떤 방법이 더 나은지에 대한 학문적 질문에 집중하는 경향이 있다고 생각합니다. 사업 상 최고가 항상 승리하는 것은 아닙니다. 나는 이것이 부정적이라고 말하거나 화염 전쟁을 시작하지 않습니다. 나는 몇 년 동안 소프트웨어 사업종사 해온 사람들에게 분명하거나 분명한 것을 진술하고 있습니다 .

모든 사업 결정은 일반적으로 인식 된 비용 / 혜택을 바탕으로 이루어집니다. 따라서 비즈니스가 묻는 질문은 다음과 같습니다.

레거시 애플리케이션에 대한 추가 시스템 및 개발 투자 비용이 동일한 프로젝트에 다른 프로젝트 / 제품에 투자하는 것보다 이점이 있습니까?

소프트웨어 마이그레이션 / 재 작성뿐만 아니라 일상적인 의사 결정에서 일반적으로 관여하는 결정을 내리기 위해 정기적 인 비용 편익 분석을 수행하고 있습니다. 따라서 가치.

환경 분리

비즈니스 이유는 환경을 분리합니다.

  • 릴리스 및 버그 수정의 위험이 적습니다. 숫자로 증명하십시오. 릴리스 / 버그가 잘못되어 제품이 실패한 횟수와 고객 수익이 발생하는 횟수입니다.
  • 개발 위험이 적습니다. 실수로 dev DB를 날려 버리는 것은 실수로 프로덕션 DB를 날려 버리는 것과 다릅니다.
  • 역할과 액세스를 명확하게 분리하는 기능. 더 나은 보안. 생산 파이의 손가락 수를 제한하는 것이 좋습니다
  • 환경을 분리 할 수있는 기능과 이러한 스타일의 개발에 따른 관행 및 절차를 통해 클라우드 시스템에 향후 구축 할 수 있습니다.
  • 환경을 분리하면 동적 스케일링뿐만 아니라 스케줄에 유용 할 수있는 복제 환경의 효율성을 강제해야합니다.

답변

모든 “올바른”주장이 이미있는 것 같습니다. 대신, 당신은 “빨간 청어”를 경험하고 있습니다. 또는 “당근 쫓기”

경영진은 중대한 문제가 생길 때까지 저를 들어주는 데 시간과 관심이 없습니다

그것이 내가 진짜 문제라고 생각하는 것입니다. 내 경험상, 회사가 당신이 묘사 한 것보다 하위 수준의 개발 관행을 가지고 있다면. 단순히 “우리는 더 잘 몰랐다”는 문제가 아닙니다. 오히려, 경영진이 야기한 문제에 대해 알지 못하는 (관리?) 기술 부채를 모은 것입니다.

그러한 경우에, 좋은 pep-talk는 당신의 방향을 갑자기 흔들지 않을 것입니다. 아마도 심각한 외상 (고객이 볼 수있는 제품 고장과 열악한 관행에 직접 연결되어 있음) 일 수도 있지만, 대화를 시도하기 전에 정통한 정통한 기술자 일 것입니다.

내 제안은 그것을 빨아 들여서 그들이 무엇인지 생각하거나 새로운 위치를 찾는 것입니다.


답변

한 번에 몇 명의 사람들이 앱을 개발할 계획입니까? Usuaslly 나는 각 사람들 그룹에 대해 하나의 환경을 보았습니다. 이것은 개발자입니다 (DEV 환경과 DEV 통합 환경을 얻습니다-일부는 100 % 필요하지 않다고 말하고 프로젝트에 따라 다릅니다), 두 가지 테스트 환경 (한 테스터 그룹은 매우 자세한 테스트를 수행하고 다른 하나는 고급 QA 테스터-일반적으로 숙련 된 테스터가 아닌 실제 비즈니스 사용자입니다). 일반적으로 격리 된 성능 테스트 환경도 있습니다 (따라서 방대한 양의 데이터를 테스트하고 방대한 양의 사용자 등을 시뮬레이션 할 수 있습니다).

왜이 모든 환경이 필요한가? 따라서 서로 다른 그룹이 서로의 발끝을 밟지 않고도 다른 기능을 테스트 할 수 있습니다. 개발자와 테스터가 동일한 환경에서 작업하는 경우 악몽입니다. ​​테스터는 개발자가 1 분마다 적극적으로 변경하는 기능에 결함을 열 수 있습니다. 두 가지 수준의 테스트가 있으면 서로 다른 활동에 집중할 수 있으며 서로의 데이터를 엉망으로 만들지 않아도됩니다. 격리 된 성능 환경이 있으면 시스템을 정지시킬 수있는 테스트를 실행할 수 있지만 격리 된 경우 다른 테스터는 영향을받지 않습니다.

동일한 환경에서 너무 많은 사람들이 너무 많은 다른 일을하려고하면 한 그룹이 다른 그룹의 테스트가 끝날 때까지 기다리면 많은 시간을 낭비하게됩니다. Stargazer712는 시간을 낭비하고 시간을 낭비하면 돈 낭비를 초래할 수 있다고 강조했습니다.

응용 프로그램에 민감한 개인 데이터 나 신용 카드 데이터가있는 경우 일반적으로 그렇지 않은 또 다른 이유는 일반적으로 데이터를 테스트 환경에 넣을 수 없으며 일반적으로 QA 및 프로덕션 환경을 제외한 모든 것에 대한 마스킹 요구 사항이 있습니다.


답변

직장에서 문화적 변화를 가져 오려고 많은 노력을 기울인 것 같습니다. 문화 변화는 사람들의 마음을 바꾸는 것만이 아니라 습관을 바꾸고, 편견을 어 기고, 궁극적으로 닫힌 마음을 더 큰 가능성으로 여는 것에 관한 것입니다. 따라서이 시점에서 스스로에게 물어보아야 할 질문은 “무엇을 놓쳤습니까?”입니다. 쉬운 답변은 경영진과 완전히 관계가 없을 수도 있다는 것입니다.

경영진으로부터 구매를 얻는 것은 쉽지만 더 어려워지고 있습니다. 돈 등에 관한 논쟁에 관계없이, 현실은 경영진의 우선 순위에 영향을 줄 수 있어야한다는 것입니다. 관리자에게는 예산이 있으며 예산이 현명하게 적용되고 회사의 가치와 우선 순위에 부합한다는 것을 보여주고 싶을 것입니다. 이러한 우선 순위 중 일부는 재정적이지만 다른 요구 사항은 다른 요구에 부응하는 것입니다. 어떤 경우에는 상사가 항상 원했던 승진을 얻기 위해 다른 관리자의 손바닥에 기름을 바르는 것을 의미 할 수 있습니다. 그러나 대부분의 경우 더 많은 비즈니스를 얻거나 파트너 및 고객과의 관계를 개선 할 수있는 방법을 찾는 것입니다. 이러한 조건으로 소송을 제기 할 수없는 경우, 임박한 상황에 처하기 전에는 지금까지만 갈 수 있습니다.

다른 사람들이 제안한 것처럼 생산성과 예산에 어떤 영향을 미치는지에 대한 사례를 만들려고 노력하지만 회사의 우선 순위 및 생산성이 회사와 다른 회사와의 관계에 직접적인 영향을 미치는 방식으로 사례를 제시하는 것이 좋습니다.


답변

여기 하나가 있습니다 : 테스트 가능성.

테스트 환경이 있으면 프로덕션 환경에서 수행 할 수없는 데이터베이스에 대한 테스트를 자유롭게 수행 할 수 있습니다.