Java의 IRC 채널 , SO 및 기타 장소와 같은 장소에서 가장 오랜 기간 동안 "코드의 모양과 가독성 / 이해성에 대한 걱정, 그리고 꼭 필요한 경우 나중에 성능에 관한 걱정"이라는 문구를 들었습니다. 그래서 오랫동안 작은 데스크탑이나 웹 앱의 성능에 대해 OCD가 아니었고 비효율적이었습니다.
대부분의 응답은 "확장 성이란 무엇입니까?"입니다. 합법적 인 요점이지만 내 앱이 10,000 줄 길이의 파일을 구문 분석하기 위해 빌드 된 경우 1,000,000 줄 파일로 밀어 넣을 작은 사람들의 코드를 엉망으로 만들어야합니까?
내 주된 질문은 매우 빨리 일을하지만 업그레이드 방법을 파괴하고 코드를 지나치게 어렵게 만들고 다음 개발자가 코드를 다시 작성하는 경향이있는 거대하고 복잡한 짐승을 위해 쉽고 비효율적 인 방법으로 거래 해야하는 시점은 언제입니까?
답변:
문제가 될 때 성능이 걱정됩니다.
10,000 개의 라인 파일을 처리하기 위해 작은 앱을 작성하고 100 번째 파일마다 1,000,000 개의 라인 파일을 얻는다면 해당 파일을 처리하는 데 시간이 더 걸리는 것은 중요하지 않습니다. 그러나 처음보다 5-10 배 큰 파일을 정기적으로 가져오고 응용 프로그램이 작업을 수행하는 데 너무 오래 걸리면 프로파일 링 및 최적화를 시작합니다.
이제 나는 "일을 너무 오래한다"고 말했다. 결정하는 것은 사용자 또는 후원 조직에 달려 있습니다. 소프트웨어를 사용하지 않거나 다른 도구를 사용하여 3을 가져 갔을 때 작업을 수행하는 데 5 분이 걸리는 경우 버그 보고서 나 유지 관리 요청을 제출하여 개선 할 수 있습니다.
사용자 인 경우 소프트웨어가 작업을 수행하는 데 걸리는 시간은 사용자에게 달려 있습니다. 소프트웨어를 더 빨리 수행 할 것인지 또는 더 읽기 쉬운 코드를 얻기 위해 더 오래 기다릴 것인지 만 결정할 수 있습니다.
내 주된 질문은 매우 빨리 일을하지만 업그레이드 방법을 파괴하고 코드를 지나치게 어렵게 만들고 다음 개발자가 코드를 다시 작성하는 경향이있는 거대하고 복잡한 짐승을 위해 쉽고 비효율적 인 방법으로 거래 해야하는 시점은 언제입니까?
이것은 일반적으로 잘못된 이분법 입니다. 매우 효율적이고 읽기 쉽고 유지 관리 가능한 코드를 작성할 수 있습니다. 놀랍도록 비효율적이며 유지하기 어려운 엉망 더미를 쓸 수 있습니다.
성능 문제를 다룰 때, 나는 보통 해결하려는 비즈니스 문제에 대해 생각하려고합니다. 고객이 소프트웨어를 사용할 때 소프트웨어가 어떻게 작동합니까? 응용 프로그램 성능이 Jacob Nielsen을 행복하게 해줍 니까?
내 주된 질문은 매우 빨리 일을하지만 업그레이드 방법을 파괴하고 코드를 지나치게 어렵게 만들고 다음 개발자가 코드를 다시 작성하는 경향이있는 거대하고 복잡한 짐승을 위해 쉽고 비효율적 인 방법으로 거래 해야하는 시점은 언제입니까?
"코드가 어떻게 보이는지, 현재 가독성 / 이해성, 그리고 꼭 필요한 경우 나중에 성능에 대한 걱정"은 해결하기 쉽고 일반적으로 도움이되지 않습니다. 좋은 디자인은 유지 관리가 쉽고 읽기 쉽고 효율적입니다.
성능은 좋은 디자인의 일반적인 구성 요소 중 하나입니다. 프로그램이 느리고 낭비되는 경우 실제로 재사용 할 수 없습니다. 이 혼란 을 해결해야 할 때 업데이트하기에 너무 시간이 걸리지 않는 한 클라이언트에서 강제로 업데이트합니다. 이 느린 프로그램은 개선하기에는 너무 많은 비용이 든다. 그들은 그들의 요구에 맞지 않기 때문에 대안을 선택합니다. 나쁜 디자인에 대한 개선의 진단, 업데이트 및 부작용 처리는 종종 효율적으로 작성하고 올바르게 작동하며 일반적으로 좋은 디자인을 갖도록 초기 개발 시간을 능가합니다. 이 프로그램은 재사용 성이 높고 유지 관리 비용이 적게 듭니다 (승리).
따라서 귀하의 질문에 대한 짧은 대답은 "낭비하지 마십시오. 재사용을 위해 작성하십시오. 개념 증명을 프로토 타이핑 / 개발할 때는 게으르지 만 생산 코드에는 프로토 타입을 사용하지 마십시오."
재사용하려는 프로덕션 프로그램 및 프로그램을 작성할 때 낭비되는 디자인을 알고 피하십시오. 구현하는 동안 프로그램을 낭비하지 않기에 이상적인 시간입니다. 세부 사항과 작업에 대한 명확한 아이디어가 있으며 작성 후 수정하는 것이 실제로 고통스럽고 비효율적입니다. 많은 사람들이 마지막에 약간의 프로파일 링 (아마도)을 믿거 나 문제가있는 경우 일반적으로 재 설계 / 변경에 너무 많은 시간이 걸리고 비 효율성이 너무 많아서 프로그램을 이해하지 못하는 경우 프로필의 결과를 기반으로합니다. 이 접근 방식은 구현하는 동안 시간이 거의 걸리지 않으며 (이를 충분히 수행했다고 가정하면) 일반적으로 몇 배 더 빠르며 더 많은 컨텍스트에서 재사용 할 수있는 디자인이됩니다. 낭비하지 않고 좋은 알고리즘을 선택하고 구현에 대해 생각하며 올바른 구현을 재사용하는 것은 모두 좋은 디자인의 구성 요소입니다. 모두가독성보다 유지 관리 성 및 재사용 성을 향상시킵니다 .
음-절대?
진지하게, 코드는 쉽게 이해하고 유지하기 위해 항상 작성되어야합니다.
성능 문제를 다루는시기와 관련하여 문제를 식별 한 후에는 문제를 해결하고 코드를 사전 최적화하지 마십시오. 성능 문제의 위치를 추측하기 때문입니다.
코드가 명확하고 간결하고 이해 가능하며 유지 보수가 가능하도록 작성 되었다면, 코드를 리팩토링하는 데 문제가 없어야합니다.
나는 일반적으로 가장 먼저 읽을 수 있도록 코드를 작성합니다. 프로그램이 작업을 수행하기에 너무 느리게 실행되는 경우에만 프로파일 링하고 최적화하십시오. 즉, 코드의 가독성에 영향을 미치지 않는 일반적인 최적화를 수행하는 습관을들이는 데 아무런 문제가 없습니다. 즉, 코드 조각을 두 개 (또는 거의 동일하게) 읽을 수있는 방식으로 작성할 수있는 경우 일반적으로 더 빠른 코드를 선택하십시오.
예를 들어 Python에서 목록 이해 (또는 생성자 표현식)는 동등한 for루프 보다 빠르기 때문에 가독성에 영향을 미치지 않는 경우 목록 이해를 사용합니다 (예 : 목록 이해는 중첩되지 않습니다) 중첩 된 목록 이해가 정신적으로 파싱하기 어려울 수 있으므로 피할 수 있고 대신 for 루프를 사용할 수 있습니다.
마찬가지로, 불변 데이터 유형은 변경 가능한 데이터 유형보다 빠르기 때문에 가능한 한 불변 데이터 유형을 사용합니다.
실제로 성능이 중요한 영역에서 작업하는 경우 나중에 생각할 때 효율성을 떨어 뜨릴 수 없습니다. 이러한 경우 초기 설계시 최종 결과의 유지 관리 성과 관련하여 고려해야 할 가장 중요한 사항 중 하나입니다.
대규모 서버를 설계하고 구현할 수 없으며 전체 스레드 잠금 기능으로 모든 시스템에 대한 차단 기능을 사용하여 모든 개별 클라이언트 요청을 처리하지 않고 각 개별 클라이언트 요청을 처리하는 모든 기능에 대해 차단 기능을 사용하는 간단하고 문서화 된 코드 작성을 시작할 수 있습니다. 공유 상태, 스레드 경합 및 비동기성에 대해 생각했습니다. 이는 재난을위한 레시피이며, 시도한 결과 경쟁 조건과 교착 상태로 인해 상상하기 어려운 가장 유지 관리하기 어려운 코드베이스를 상상할 수있는 방식으로 작성한 훌륭한 문서화 코드를 다시 디자인하고 다시 작성해야합니다. 효율적이고 단순한 작업 설계를 미리 생각하는 것과는 반대로, 후시에서 필요한 효율성을 달성하기 위해.
게임 개발 팀은 32 개의 코어를 가진 가장 강력한 하드웨어에서 초당 2 프레임 만 사용하는 엔진을 사용하여 8 개월 동안 생산을 시작하면서 화면이 바쁠 때마다 15 초 동안 정지하는 경향이있어 사용 가능한 제품을 즉시 얻을 수는 없습니다 하나의 현지화 된 핫스팟을 고정합니다. 코드 보드의 구석 구석까지 계단식으로 진행될 수있는 드로잉 보드와 디자인 변경에 대한 서사시를 보장하는 방식으로 디자인이 FUBAR 일 수 있습니다.
John Carmack과 함께, 기술 데모를 프로덕션에 통합하기 위해 초당 최소 수백에서 수천 프레임으로 실행하는 방법에 대해 한 번 이야기했습니다. 그것은 효율성에 대한 건강에 해로운 집착이 아닙니다. 그는 고객이 게임을 수용 할 수 있도록 게임을 전체적으로 30+ FPS에서 실행해야한다는 것을 미리 알고 있습니다. 결과적으로 소프트 섀도우 시스템과 같은 하나의 작은 측면은 30 FPS에서 실행될 수 없으며, 그렇지 않으면 게임 전체가 필요한 실시간 피드백을 제공 할만큼 빠를 수 없습니다. 그것은이다 사용할 수 없게 은 필요한 효율을 달성 할 때까지. 효율성에 대한 기본 요구 사항이있는 성능이 중요한 영역에서 적절한 속도를 달성하지 못하는 솔루션은 실제로 전혀 작동하지 않는 솔루션보다 낫지 않습니다.. 그리고 효율성에 대해 많은 관심을 가지지 않으면 실시간 게임 엔진에 필요한 초당 초당 수백에서 수천 프레임으로 실행되는 효율적인 소프트 섀도우 시스템을 설계 할 수 없습니다. 실제로, 이러한 경우, 경로 추적을 사용하여 프레임 당 2 시간 동안 만 잘 작동하는 부드러운 그림자 시스템을 만들어내는 것이 쉽지 않기 때문에 작업의 90 + % 이상이 효율성을 지향합니다. 그러나 조정할 수는 없습니다 완전히 다른 접근 방식을 변경하지 않고 초당 수백 프레임으로 실행합니다.
효율성이 응용 프로그램 설계의 기본 요소 인 경우, 무시 후 작업 설계를 달성 할 수 없기 때문에 무시함으로써 절약 한 시간보다 훨씬 더 많은 시간을 잃지 않으면 서 후시의 효율성을 달성 할 수 없습니다. " 나중에 디자인에 대해 생각하지 않아도 괜찮습니다. 코드를 잘 문서화하면 나중에 적절한 디자인을 만들 수 있습니다 ." 그러나 성능이 중요한 아키텍처에서는 효율적인 디자인에 많은주의와 생각을하지 않으면 효과적으로 수행 할 수 있습니다.
그렇다고해서 바로 구현을 마이크로 튜닝해야한다는 의미는 아닙니다. 구현 세부 사항을 위해, 설계를 변경할 필요가없고 측정을 수행 할 때 가장 생산적인 방법 인 경우 측정 후 더 빠른 솔루션으로 반복 할 여지가 많이 있습니다. 그러나 디자인 수준에서는 디자인과 아키텍처가 처음부터 효율성과 어떤 관계가 있는지에 대해 충분한 생각을해야합니다.
여기서 중요한 차이점은 디자인입니다.. 디자인이 종속성을 누적하여 디자인을 크게 변경하는 것은 쉽지 않으며 디자인이 변경되면 종속성이 손상됩니다. 그리고 디자인이 합리적으로 효율적이어야하거나 경우에 따라 품질이 효율성에 의해 크게 측정되어야하는 요구 사항이있는 경우, 사후에 적절한 디자인을 얻을 수있을 것으로 기 대해서는 안됩니다. 운영 체제 또는 컴파일러, 비디오 프로세서, 레이트 레이서, 게임 엔진 또는 물리 엔진 등 효율성이 품질의 큰 측면 인 경쟁 제품의 경우 효율성과 데이터 표현에 대한 생각은 처음부터 꼼꼼하게 생각되었습니다. 이러한 경우 효율성을 우선적으로 고려하는 것은 조기 최적화가 아닙니다. 그런 생각을 할 때 가장 생산적인 시간에 정확하게 생각해야했습니다.