개발자 팀은 소비자 앱의 성능 저하를 어떻게 방지 할 수 있습니까?

이전 에 느린 소프트웨어에 대한 책임이 무엇인지 물었을 때 내가 받은 몇 가지 답변은 그것이 사회 및 관리 문제라고 제안했습니다.

이것은 기술적 인 문제가 아니라 마케팅 및 관리 문제입니다 .... 궁극적으로 제품 관리자는 사용자가 얻는 것에 대한 사양을 작성해야합니다. 많은 일이 잘못 될 수 있습니다. 제품 관리자가 사양에 버튼 응답을 넣지 못합니다 ... 품질 보증 담당자는 사양에 대해 평범한 테스트를 수행합니다. 우리는 프로그래머가 그것을 보충 할 수 없습니다. — 밥 머피

사람들은 좋은 크기의 앱에서 일합니다. 작동하면서 버그와 마찬가지로 성능 문제가 발생합니다. 차이점은-버그는 "나쁜"- "나를 찾아서 고쳐줘"라는 외침입니다. 성능 문제는 단지 거기에 앉아 악화됩니다. 프로그래머들은 종종 "내 코드에는 성능 문제가 없을 것입니다. 오히려 경영진은 새로운 / 더 큰 / 빠른 기계를 구입해야합니다."라고 말합니다. 사실 개발자가 주기적으로 성능 문제 ( 실제로는 매우 쉬운 )를 찾기 만하면 문제를 간단히 해결할 수 있습니다. — 마이크 던 라비

따라서 이것이 사회적 문제라면 조직이 고객에게 느린 소프트웨어를 배송하는 것을 피하기 위해 어떤 사회적 메커니즘을 적용 할 수 있습니까?

올바르게 작성되고 완전한 요구 사항이 있으면 버그와 성능 저하가 구분되지 않습니다 . 비 기능적 요구 사항으로 성능을 지정하기 때문에 성능 저하는 다른 버그와 마찬가지로 버그가되며 QA에 의해 파악되어 릴리스 전에 개발자가 해결합니다.

사회적 문제가 있습니까? 나는 그렇게 생각하지 않습니다. 주요 문제는 요구 사항이 불완전하다는 것입니다. 몇 년 동안 프리랜서로 일하면서 특정 작업이 평균 최대 N 초 동안 수행되어야한다는 기능적 요구 사항을 본 적이 없습니다 . 관리자 / 고객 / 이해 관계자 또는 그 밖의 어떤 것이 성과 자산에 대해 신경 쓰지 않는다면, 내가 관심을 가져야하는 사람들이 전혀 신경 쓰지 않기 때문에 개발자로서 내가 왜 귀찮게합니까?

성능 저하에 영향을 미치는 또 다른 요소가 있습니다 . 개발자가 값 비싼 PC에서 잘 작동 한다는 사실입니다 . 8GB RAM, 고급 SSD, 최신 OS 등을 갖춘 쿼드 코어 PC에서 수년 동안 작업하는 경우 듀얼 코어 PC의 Windows XP에서 응용 프로그램이 어떻게 실행되는지 상상하기가 매우 어렵습니다. 512 Mo의 RAM과 오래된 하드 디스크를 90 %로 채우고 몇 년 동안 조각 모음을하지 않았습니다. 불행하게도, 일부 국가에서는 마지막 사례가 대부분의 앱 소비자에게 나타나는 사례입니다. 개발자 PC와 소비자 PC 사이의 간격이 클수록 개발자는 자신의 앱 성능을 관리하기가 더 복잡합니다.

문제 (?) :

• 고객 (또는 최종 사용자)이 이에 대해 불평하지 않습니다 (충분히)
• 따라서 프로젝트 (/ 제품) 관리자는 요구 사항을 고려하지 않습니다.
• 따라서 개발자는 그것을 고칠 시간이 없습니다.

처음부터 시작하여 고객을 교육해야합니다. 그러나 더 빠르고 덜 반짝이는 전화 대신 iPhone을 구입하면 개발자는 성능 대신 외모에 시간을 할애 할 수 있습니다. 조직은 문제가 아닙니다.

물론 어떤 것이 도움이 될 수 있습니다. 자동화 된 테스트를 기다리는 것은 성가신 일이므로, 자동화 된 테스트를 수행하면 개발자는 성능 문제에 대한 지속적인 피드백을받을 수 있으며 기능 문제가 아닌 기술적 문제로 해결할 가능성이 높습니다.

그러나 모든 것을 할 수는 없습니다. 기능을 최적화하거나 추가하며 돈을 쓰는 사람들이 결정합니다.

그러나 좋은 소식은 : SaaS / Cloud / Buzzword 애플리케이션이 여기에서 많은 도움이된다는 것을 알았습니다. 사람들이 몇 가지 유사한 웹 응용 프로그램을 선택하고 먼저 '필수'기능의 인공 목록을 작성하는 대신 실시간 테스트 를 수행하면 응답 속도에 더 빨리 영향을 받으므로 성능에 더 많은 관심이 집중됩니다.

슬프게도, 가장 큰 문제는 모든 것을 할 수 없다는 것입니다. 배송 날짜가 있으며 속도가 느리다는 것을 알고 있지만 X, Y, Z 기능을 시장에 출시해야합니다.

마음 속으로 느리게 고칠 수는 있지만 앱은 최소한 작동합니다.

따라서 기능과 미학에 대해 걱정합니다 (사용자가 미학에 자주 초점을 맞추기 때문). 다음 릴리스에서는 성능을 수정합니다.

그러나 PM은 단지 기능 목록을 제공하며 성능을 수정할 시간이 없습니다.

그리고 악순환이 계속됩니다.

다른 사람들도 동의합니다. 개발자가 느린 하드웨어에서 테스트하고 성능 목표를 세우는 것과 같이 개발자가 문제에 더 관심을 갖도록하는 방법을 찾아야합니다. 성능 튜닝과 관련해서는 괜찮습니다.

사람들은 방법을 알고 있어야합니다.

그들은 수 있습니다 생각 그들이, 그러나 다만 유래에이 포럼의 모든 성능 관련 질문과 답변을 통해 본다. 얼마나 많은 사람들이 성능에 대해 상식을 거의 나타내지 않는지 고통 스럽습니다.

사람들에 의해 배울 필요에 대해 그냥 이야기 뭔가 아니다 일 을. 그들이이 모드에있는 유일한 시간은 수업을 들거나 책이나 블로그에서 새로운 것을 배울 때입니다.

따라서이 문제를 해결하기 위해 생각할 수있는 유일한 방법은 프로그래밍 을 가르치는 사람들을 사로 잡고 그들이 하는 방법을 가르치는 것 입니다.

천국은 알고 있듯이이 포럼에서 시도했습니다-

• 기본적인 초간단 한 방법
• 43x 속도 향상은 - 할 것을 당신의 프로파일 러
• 이유를 자세히 설명하지 못하는 이유

누구나 할 수 있습니다. 그들은 실제로 해야 합니다.

성능을 요구 사항으로 만듭니다.

수행 코드 작성이 어렵습니다. 스레딩, 비동기 이벤트 처리, 캐싱 및 점근 적 복잡성과 같은 개념에 대한 확실한 이해가 필요합니다. 내가 함께 일한 프로그래머 그룹에 의해 판단하면, 주어진 그룹의 약 20-40 %는 물론 일상 업무에 성능 고려 사항을 포함시키기에 충분한 개념을 이해하지 못합니다.

그러나 이러한 프로그래머는 분명히 회사에 유용하지만 성능이 중요하지 않은 작업에 할당되므로 프레임을 삭제하지 않고 Netflix 스트림을 완벽하게 재생할 수있는 블루 레이 플레이어가 생겨나지 만 30-60 초가 걸립니다. 대기열을 표시하는 메뉴 항목을 엽니 다.

직원의 20 %를 해고하고 더 숙련 된 (그리고 더 비싼) 개발자로 교체 할 수있는 핫샷 소프트웨어 회사가 아니라면이를 해결하는 유일한 방법은 개발자 교육 및 버그 신고입니다. 다른 회사가 어떻게 진행되고 있는지 모르겠지만 여기서 개발자가 해결해야 할 시간이나 비즈니스 우선 순위가없는 성능 문제가 발견되면 자체 버그 보고서를 제출할 수 있습니다. 백 로그 맨 위로 이동하려면 몇 가지 릴리스가 필요할 수 있지만 일반적으로 최종적으로 해결됩니다.

성능이 필요한 경우 테스트하십시오.

그렇지 않으면 Wally는 무한 루프를 작성하고 "시간이 오래 걸립니다"를 일찍 떠날 수 있습니다. 그는 주장 할 수 있습니다.

소프트웨어 승인 테스트에는 다양한 운영 성능 특성에 대한 자세한 승인 테스트가 있어야합니다.

이렇게하지 않으면 당신은 엔지니어링하지 않는 모든 제품에 성능을.

자원 소비와 같은 성능은 하위 시스템에 예산을 책정해야합니다. 그런 다음 하위 시스템 승인 테스트에서이를 확인할 수 있습니다.

그런 다음 성능을 조기에 자주 테스트 할 수 있습니다. 그런 다음 단위 테스트조차도 확인할 수 있습니다.

따라서 이제 개발자는이를 수용 기준으로 삼고 있으며 이에 적합한 접근 방식을 구성 할 수 있습니다.

현재 작업중인 곳에서 성능 스트레스 테스트는 우리가 알고있는 고객 데이터 세트보다 2 배 더 큽니다. 정기적으로 새 버전의 제품이 중단됩니다. 좋은 테스트.

나는 90 년대 중반에 한 번 기억하고 무언가를 최적화하기 위해 시간을 보냈는데, 동료가 "이것은 펜티엄에서 실행되고 있습니다. .... 그것은 눈을 뜨는 사람이었습니다. 슬프게도, 그것은 빙산의 일각 일뿐입니다. "펜티엄"부분이 시간이 지남에 따라 바뀌었지만 내 경력 전반에 걸친 태도를 들었습니다.

일반적인 개발자가 관심을 가질 수있는 유일한 방법은 성능이 부족하여 고객이 버그로 간주하는 것입니다. 응용 프로그램과 대상에 따라 이것은 쉽지 않거나 어려운 작업 일 수 있습니다 (두 가지를 모두 보았습니다). 청중이 열악한 성능에 신경 쓰지 않는다면 개발자는 결코 (빠르고, 좋고, 빠르며, 두 가지를 선택하지) 않을 것입니다.

그러나 프로그래머가 키 누르기와 응답 사이의 3 초 지연이 허용되지 않는다는 것을 깨닫기 위해 QA의 서한을 가져 와서는 안됩니다.

해서는 안된다고 동의하십시오. 지연을 얻은 증거는 최종 사용자와 관련 이 있다는 증거 이상이 필요 합니다 .

컨텍스트를 제공하지 않으면 dev / QA 환경의 지연이 로컬 디스크 / 메모리 / 네트워크 액세스의 로컬 문제로 인해 발생할 수 있습니다. 이 경우 QA와 개발자는 최종 사용자에게 중요하지 않은 사항을 수정하기 위해 노력을 낭비하게됩니다.

성능 테스트에서 개발자에게 의존하는 것은 속도를 내기 위해 기능을 선택하기 위해 주사위를 굴리는 것만큼이나 생산적입니다. "개발자는 일반적으로 응용 프로그램의 성능 문제가 실제로 어디에 있는지에 대한 끔찍한 직관을 가지고 있습니다"( Brian Goetz ).

• 나는 절름발이 경영진이 한때 그들의 밝은 마케팅 담당자와 똑똑한 프로그래머가 고객의 성능 문제를 처리하기에 충분하다고 결정한 프로젝트에 참여했습니다. 정말 대단한 교훈이었습니다. 거부 된 석방, 반년의 노력은 쓰레기통에 갔고 회사는 전략적 파트너를 거의 잃었습니다. 결국 그들은 전문가 (벤치마킹, 통계, UX, 저수준 최적화 전문가 등)를 초청 했고 전문가들은 그 혼란을 해결했습니다.

모든 프로그래머가 자체 QA를 수행하여 그러한 문제를 즉시 볼 수 있어야합니까?

그것이 가능하다는 사실이 그것이 갈 길이라는 의미는 아닙니다. 오히려 내 경험에서 이것은 프로그래머의 생산성 을 잃는 가장 신뢰할 수있는 방법 중 하나였습니다 . 끝없는 회의만큼이나 우수하고 인터뷰 후보보다 훨씬 좋습니다.

• 전 테스터로서 한 번은 개발과 QA 활동을 결합하는 것이 문제가되지 않아야한다고 생각했습니다. 일상적인 개발자 테스트와 체계적인 QA의 차이는별로 중요하지 않은 것으로 보입니다. dev / QA 분리는 소프트웨어 산업의 전통 일 뿐이라고 생각했습니다. 이것이 그렇게 어려운 방법을 배웠습니다. 분리는 초점과 생산성의 문제이며 매우 심각한 문제였습니다.

성능 문제가있는 경우 벤치 마크를 제공 하고 목표 성능을 설정 하기 만하면 최선을 다할 것입니다. 성능 테스트는 그다지 좋지는 않지만 최적화에 대해 조금 알고 있습니다.

문제의 99 %가 스코프 크립이라는 것을 알게 될 것입니다. 예를 들어 dvr을 사용하십시오. 이것이 쉽다고 생각하지만 TIVO 또는 경쟁 업체는 잘 받아 들여진 새로운 기능을 소개합니다. 다음으로 새로운 기능을 알고 있습니다. 기존 제품과 호환되지 않을 수 있으며 오래 걸리는 기존 제품을 다시 실행하지 않습니다. 따라서 기능이 중단되어 성능이 저하됩니다. 데이터가 정보를 얻기 위해 존재하지만 정보를 얻을 생각이 없다면 쉽게 얻을 수 없을 것입니다. 따라서 이제는 프로그램 목록 근처에 갈 때마다 해당 정보를 작성하는 복잡한 프로세스가 있습니다.

신경 쓰지 않는 개발자를 무시하고 ...

필자는 종종 코드를 개발하는 개발자에게 지속적으로 성능을 측정 할 수있는 도구가 없다고 생각합니다.

예 : 앱의 응답 시간을 측정 할 수있는 경우 (예 : 웹 기반 애플리케이션 또는 데이터베이스 쿼리 등)-현재 "최고 10"이라는 최악의 알림 (이메일, SMS 등)을 받고 있습니까? 응답을 수행하거나 결정된 임계 값을 초과합니까?

대부분의 경우 개발자는 "실제"배포에서이 정보를 얻지 못하므로 보이지 않는 정보를 무시하기가 매우 쉽습니다.

그러나 매일 / 몇 시간마다 화면 "x"를로드하는 데 13 초가 걸리고 다음 SQL 쿼리 SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...를 실행한다는 이메일이 표시되면 개발자가 완전히 고칠 수 있다고 생각하는 것이 좋습니다. 그것.

따라서 모든 프로그래머 가 성능을 심각하게 생각한다고 생각하지만 문제에 대한 가시성이 부족한 경우가 종종 범인이라고 생각합니다.

참고 : 개발자가 액세스를 요청하거나 이러한 기능을 개발해야하며 관리자가 이러한 도구를 제공 / 자금 지원해야한다고 생각합니다.

실제로 프로그래머에게 책임을 물을 수있는 더 좋은 예를 생각해 낼 수 있습니까? Eclipse를 제외하고 한 의견자는 이미 플러그인을 수행한다고 지적했습니다 (새 Eclipse 버전을 처음 설치할 때 번개처럼 실행되지만 다른 도구를 추가하면 속도가 느려집니다). 코드 관련이지만 환경 관련.

컴퓨터에서 프로그램을 분리하여 실행하고 '빠른'또는 '느린'여부를 결정하는 시대는 지났습니다. 다른 예는 환경에 따라 다릅니다. 현재 네트워크 혼잡, 백엔드 서버 과부하, 네트워크 카드 불량, 케이블 결함, 근처에서 다른 사람의 수 또는 수백 가지의 다른 변수. 예. 호스팅 제공 업체는 서버 기가비트 연결에 대해 추가 요금을 청구했지만 결국 10Mb 포트가있는 고대 방화벽 장치를 통과 한 것으로 확인되었습니다. 이러한 문제는 바뀌고 찾기가 어렵습니다.

프로그래머가 할 수있는 일이 많이 있습니다 (대역폭 최소화, 응답 성을 개선하고 진행률을 보여주는 UI 트릭으로 빠른 인상을 줄 수 있습니다). 그러나 현실 세계로 진출 할 때 경험으로 만 배울 수있는 모든 종류의 상황이 있습니다 (그리고 당신의 가정이 당신 앞에서 사라지는 것을 보게됩니다).

더 나은 소프트웨어에 대해 얼마를 지불 하시겠습니까? 시장은 더 나은 소프트웨어를 얼마나 기다리는가? 다음 릴리스에 얼마나 작은 부스러기가 추가됩니까?

많은 절충안이 존재하는 시장입니다. 그것이 실제로 쓰레기라면 시장은 제품을 망칠 것입니다. 현 상태로 살 수있는 고객이 충분할까요?

이 문제에 대한 가장 일반적인 대답은 관리하기가 가장 어렵다고 생각합니다. 즉, 모든 프로그래머는 수행하는 모든 작업에 대해 성능을 염두에 두어야합니다. 나는 또한 그것이 약간의 경찰 아웃이라는 것을 알고 있습니다.

프로젝트의 규모와 해당 팀에 따라 전담 퍼포먼스 프로그래머를 보유하는 데 많은 가치가 있다고 생각합니다.

예를 들어, 프로젝트 팀 (약 30 명 포함)에 2 명 이상의 성능 최적화 전담 팀이있는 팀에서 근무했습니다. 이 특정 응용 프로그램은 또한 웹 서비스뿐만 아니라 다양한 데이터 매핑 및 어댑터 구성 요소가있는 레거시 계층 측면에서도 많은 상호 운용성 구성 요소가 있기 때문에 성능 문제가 발생하기 쉽습니다.

직접적인 경험이 중요합니다. 개발자에게 빠른 컴퓨터 컴파일 및 빌드를 제공하지만 실제로는 일부 사용자의 경우와 같이 너무 느리게 오버로드 된 컴퓨터에서 앱을 실행할 수있게하십시오. (이 기능은 VM / 서버를 기능별로 분할하여 클라우드 / 서버 기반 개발 환경에서 수행 할 수 있습니다.) 반 배터리가 방전 된 휴대폰을 제공하고 초기 모바일 앱 테스트 기간 동안 만 사용해야합니다.

개발자가 성능 및 배터리 수명과 관련하여 고객과 공감하는 경우 성능을 우선 순위 목록의 맨 아래에 두는 반 가짜 관리 사양으로 간주하지 않습니다. (그래서 : "이봐, 너무 늦을 때까지 조기 최적화라고 생각했다.")

물건 구매를 중단하고 온라인 리뷰에서 열악한 성능에 대해 언급하십시오.

장치가 여전히 판매되고 있다면 소프트웨어는 더 많은 시간과 돈을 투자 할 수없는 "충분히 좋은"것입니다. 성능에 대한 나쁜 리뷰가 판매를 크게 줄이면 소프트웨어는 "충분하지 않습니다"고 수정이 필요합니다.

소비재 생산자에게 관심이있는 유일한 지표는 단위당 판매 및 이익입니다.

나는 프로그래머가 퍼포먼스 최대화 등에 대해 더 잘 가르쳐야한다는 것에 동의합니다.

그러나 솔루션이 프로그래머에게 거의 매일 사용되는 하드웨어를 제공하지는 않는다고 생각합니다. 비주얼 스튜디오가 하루에 두 번 충돌하면 물건을 만드는 데 x 초, 솔루션을 여는 데 y 초, 창을 변경하는 데 z 초가 걸리는 것은 얼마나 스트레스가 될까요. 나는 하드웨어가 싸고 프로그래머 시간이 비싸기 때문에 회사에게 매우 비용 효율적이라고 생각하지 않습니다.

다음으로 코드를 처리 할 QA (테스트) 팀이므로 성능의 중요성에 대해 가르치고 수용 가능한 성능 표준에 대한 표준을 엔터프라이즈 표준으로 사용하는 것이 좋습니다 (완벽한 세계에서) 성능 표준은 사양에 맞아야하지만 자주 발생하지는 않습니다)? (즉, 중요한 엔터프라이즈 응용 프로그램 인 경우 정기적 인 엔터프라이즈 ee 변경 페이지 / 탭은 "x 초 안에 업데이트 저장"과 같이 즉시 발생해야합니다.) 품질 보증팀이 운영하는 컴퓨터는 일반적인 사용자 컴퓨터 여야합니다. (우리는 그들에게 386을 제공함으로써 그들을 화나게하고 싶지 않지만 8GB의 램으로 쿼드 코어를주지 마십시오). 그들이 성능에 충분히 화가 나면 프로그래머에게 환기를 제공하지 않습니까?

클라이언트 / 프로젝트 관리자는 프로그래머 / qa 팀 / 개발자 / 회사 담당자가 가장 낮은 하드웨어로 프리젠 테이션을하도록 강요해야한다고 생각합니다. (예를 들어 회사에서 가장 약한 컴퓨터). 다시 작성하는 경우 이전 소프트웨어에서 x 프로세스를 수행하는 속도에 대한 데이터를 수집하고 새 소프트웨어의 속도와 비교해야합니다 (새 소프트웨어에는 추가 비즈니스 프로세스가 필요할 수 있으므로 속도가 느릴 수 있음). 허용되는 창이 있어야합니다).

이전에 말했지만 다시 말할 것입니다. 이것을 처리하는 가장 좋은 방법 중 하나는 개발자가 (상대적으로) 후진 하드웨어에서 작업하도록하는 것입니다.

일반적인 프로그래머에게는 대부분의 공식적인 성능 고려 사항은 단순히 "실행하려고 할 때 성가신가?" 그들이 성가신 것을 발견하면 (적어도 시도하려고 노력할 것입니다). 그들이 실행하는 방식에 만족한다면, 당신이 얻는 최선의 방법은 마음을 고치려고 노력하는 것입니다. 또한 문제를 해결하는 데 훨씬 많은 비용이 들기 전에 조기에 문제를 찾는 데 도움이됩니다.

QA가 성능이 적절하다고 생각하기 때문에 개발자가 실제로 믿지 않는 규칙을 시행해야한다는 점에 도달하면 대부분의 "수정"이 규칙을 해결할 수있는 창의적인 방법을 얻을 가능성이 매우 높습니다. 최종 사용자의 수명을 연장시키는 실제 수정 사항이 아닙니다.

동시에, 나는 이것을 거의 문제로 보지 않았다고 덧붙여 야합니다. 어쨌든 개발자가 실제로 귀찮게하기에 충분하지 않은 성능을 향상시키기 위해 너무 많은 시간을 소비하는 것을 보았습니다 (죄는 종종 죄책감입니다).