코딩 우선순위:성능, 유지 관리성, 재사용성?

Question

이는 주로 SQL 질문에 대한 답변으로 인해 발생했습니다.UDF 및 하위 쿼리는 성능 때문에 의도적으로 생략되었습니다.당연하게 여겨야 하는 것이 아니라 코드가 작동해야 하기 때문에 신뢰성을 포함하지 않았습니다.

항상 성능이 우선인가요?성능을 최우선으로 하여 많은 답변이 제공됩니다.내 사용자는 코드를 얼마나 빨리 수정할 수 있는지에 더 관심을 갖는 것 같습니다.따라서 보고서를 실행하는 데 12초가 아닌 15초가 걸립니다.내가 해결책을 제시하지 못한 것에 대해 변명을 하지 않는 한 그들은 그것을 감수할 수 있습니다.

15초가 15분으로 바뀌면 분명히 문제가 있지만 사용자는 기능을 원합니다.그들은 애플리케이션이 비즈니스 규칙 변경 및 개선 요청에 적응하기를 원합니다.나는 지금으로부터 6개월 후에 코드를 보고 쉽게 식별할 수 있는 한 지점에서 변경 작업을 수행할 수 있고 다른 함수나 하위 루틴 또는 Udf를 호출할 것이라고 생각하여 코드를 복사하여 붙여넣은 모든 위치를 추적하지 않고 싶습니다. 성능을 방해합니다.

말한 모든 것, 나는 다음을 주문할 것입니다:유지 관리성(변화는 삶의 사실입니다.), 성능(아무도 모래시계를 쳐다보는 것을 좋아하지 않습니다.), 재사용성(어떤 코드를 다시 사용해야 하는지 결정하기 어렵습니다.)

Answer 1

1. 유지 보수 : 코드를 읽을 수없는 경우 아무리 빠르더라도 쓸모가 없습니다. 그리고 그것은 확실히 재사용되지 않을 것입니다.

2. 재사용 성 : 모든 코드가 재사용 할 수있는 것은 아니지만 많은 코드입니다. 할 수 있다면 항상 코드를 더 간단하게 만듭니다. 가장 쉬운 것은 분열과 정복입니다. 예를 들어, 반복해서 사용할 간단한 구성 요소를 만듭니다. UI 위젯이 가장 일반적입니다. 그러나 유틸리티와 동일합니다. 또한 코드에 구조/프레임 워크를 작성하면 도움이됩니다. 오류 유효성 검사 코드 등

3. 성능 : 일반적으로 대부분의 코드는 충분히 수행됩니다. 그렇지 않은 경우 코드 프로파일 러를 사용하십시오. 병목 현상이 가독성 또는 재사용 가능성의 비용으로 수행 할 수있는 소규모 코드 최적화보다 훨씬 더 자주 발생합니다.

Answer 2

목록에서 하나를 놓친 것 같아요 : 신뢰성;

그래서 내 주문입니다

• 신뢰성과 정확성
• 유지 가능성
• 재사용 성
• 성능

코드가 옳지 않은 경우 얼마나 빨리 코드인지는 중요하지 않습니다. 첫째, 코드는 신뢰할 수 있어야합니다.

성능은 목록의 맨 아래에 있습니다. 너무 일찍 최적화하지 말고 성능이 문제가 될 때만 성능을 향상시킵니다.

나는 비행 시뮬레이션을 포함한 실시간 시스템에서 작업했으며, 심지어 환경에서도 성능이 고려되었지만 가장 중요한 주요 관심사는 아닙니다. ¹.

나는 내 경험상 내가 작성한 코드의 1% 미만을 최적화해야한다고 말할 것입니다.

---

¹ 때로는 무언가가 빠르지 않으며, 설계 및 코딩 할 때 물론 성능이 고려되면 목록의 최상위에 있지 않습니다.

Answer 3

빨판 대답은 물론 "그것은 의존한다"입니다.

비즈니스 라인 애플리케이션의 경우 관련 활동에 대한 응답 시간은 실행되는 주파수에 반비례해야합니다. 사용자가 한 시간에 4 ~ 5 회 액세스 해야하는 기능이라면 그 월말 보고서를 가져 오는 것보다 더 잘 어울 렸습니다.

나는 어느 정도까지, 당신은 당신의 자신의 질문에 대답하고 그것에 대한 몇 가지 유효한 이유를 제공했다고 생각합니다. 당신이 놓친 유일한 것은 신뢰성입니다. 이것은 NASA 유추가 나오는 곳입니다. NASA 또는 금융 기관을위한 코드를 작성하는 경우 피의 웰이 강력하고 신뢰할 수있는 것이 더 좋았습니다 ... 그리고 나는 그것이 첫 번째 우선 순위라고 생각합니다.

Answer 4

저는 NASA 계약자이며 보고서 실행 및 추적 프로젝트와 같은 관리 목적으로 주로 소프트웨어를 개발하고 유지 관리합니다.

나는 약 1.5 년 동안 그곳에서 일해 왔으며 그들의 주요 관심사는 유지 가능성 그리고 새로운 기능이나 모듈을 얼마나 빨리 배포 할 수 있습니까?

소프트웨어가 탁월한 시간이 걸리지 않는 한, Guiness와 마찬가지로, 그들은 신경 쓰지 않는 것 같습니다.

그들이 가지고있는 또 다른 주요 관심사는 유용성입니다. 응용 프로그램은 쉽고 간단해야합니다.

결론적으로 유지 가능성, 유용성, 성능은 내부보고 및 추적 도구에 대한 NASA의 주요 관심사로 보입니다.

Answer 5

프로젝트에 따라 이러한 우선 순위를 재정렬 할 수 있어야하며 프로젝트 나 다른 코드 섹션을 전환 할 때 어려운 일은 행동을 빠르게 변경할 수 있습니다. 프로파일이 매우 다른 세 가지 응용 프로그램에서 작업합니다.

1. 하나는 실시간이며 많은 작업이 성능이 예측 가능하고 (반드시 빠르게 가벼워지지는 않음) 변경 사항은 큰 문제가 아니며 IETF가 RFC를 변경/쓸모 없게 할 때만 크게 변경되고 부호가 거의 없습니다. 그것의. (즉, 나는 그 유지 가능성 수준을 매우 자랑스럽게 생각합니다).

   • 다른 앱은 때때로 1 일의 데이터를 처리하기 위해 16 시간 동안 사용되었습니다. 말할 것도없이 절대 성능이 빠르게 최우선 순위가되었습니다. 그러나이 앱 내에서도 성능 강조는 배치 당 코드의 '중요하지 않음'에서 클라이언트 당 코드, 작업 당 코드 당, 프라이드 코드 당, 레코드 코드 당 PER 당 극적으로 다릅니다. -바이트 당 코드에서 '매우 중요한'-필드 코드.

   • 최종 앱에는 비즈니스 논리의 많은 부분이 포함되어 있으며 성능은 문제가되지 않으며 유지 관리 가능성이 중요 하며이 앱은 모든 세련된 방법론에서 가장 큰 이점을 제공하지만 몇 주 또는 몇 달 동안 성능을 위해 리팩토링을 보냈을 때 매우 어렵습니다. "String1 + string2 + string3 + string4"를 작성하려면 가장 읽기 쉬우 며 성능이 관련이 없습니다.

Answer 6

2010-03-02 편집: 질문은 원래 시작되었습니다.

모두 NASA에서 일합니까? 성능은 항상 먼저 오는가? 너무 많은 답변 ...

우리 중 가장 큰 사람은 NASA에서 일하지 않습니다.

아니오 : 신뢰성과 유지 관리는 성능보다 앞서 나옵니다. 재사용 가능성도 좋습니다.

광범위한 한계 내에서 성능은 중요하지 않습니다.

Answer 7

이것은 흥미로운 질문이며 답은 매우 흥미 롭습니다. 우선 순위는 구현에 따라 다릅니다. 사용자가 유지 가능성이나 재사용 성을 위해 성능을 희생하지 않는 예 중 하나를 제시하고 싶습니다. 예, 신뢰성의 요인이 있습니다. 버그/오류가 있어야합니다. 따라서 유지 관리, 성능 및 재사용 성을 비교할 때.

고객 중 하나가 온라인 거래 사이트를 가지고 있습니다. 피크로드에서 평균 트랜잭션은 중간ware 수준에서 약 14ms를 완료하는 데 걸립니다. 후자 후자는 응용 프로그램의 성능이 일부 이유로 인해 저하되고 거래 평균 시간은 24ms로 증가했습니다. 이제 일반 개발자로서 우리는 10ms가 그렇게 놀라 울 정도로 중요하지 않다고 생각합니다. 그러나 우리가 비즈니스 관점에서 생각한다면 그것은 놀라운 일입니다. 어떻게? 분석하자 :

피크 하중 하에서 리소스가 완전히 활용되고 14ms로 100 개의 거래를 할 수 있다고 가정 해 봅시다. 성능이 저하되면 트랜잭션은 10ms 추가로 71.42% 추가 시간이 걸립니다. 이제 이는 100 개의 거래 대신 28.58 개의 거래에만 서비스를 제공 할 수 있음을 의미합니다. 이것은 사업의 심각한 손실을 의미합니다.

사실 애플리케이션 성능의 중요성에 대한 많은 문헌이 있습니다. "컴퓨터 아키텍처에 대한 정량적 접근 방식"이 있습니다.이 책은 성능, 주제, 신뢰성, 변호성의 요인을 비즈니스/사용자 용어로 어떻게 정량화 할 수 있는지 설명합니다.

나는 컨텍스트에 따라 중요한 순서를 지정하지 않을 것입니다.

Answer 8

그들은 다른 기능이나 하위 루틴 또는 UDF를 호출하는 것이 성능을 방해한다고 생각했습니다.

그것은 잘못된 생각입니다.

나는 유지 가능성, 성능, 재사용 성을 주문할 것입니다.

때때로 (보통 IMO) 재사용 가능성 ~이다 유지 가능성 : "쉽게 식별 된 하나의 지점에서 변경할 수 있고 Soneone이 복사 및 붙여 넣은 코드를 쫓지 않을 수있는 것을 재사용했기 때문입니다.

Answer 9

NASA에서도 성능은 먼저 오지 않습니다! NASA에서는 코드가 정확하고 신뢰할 수 없다면 사람들은 죽습니다.

더욱이, 내 경험에 따르면, 성능이 가치가있는 경우에도 그것은 어느 정도입니다. 일반적으로 추가 가치가 거의 없거나 전혀없는 성능 수준이 있습니다. 대조적으로, 코드 조각이 아무리 신뢰할 수 있더라도 정확성을 향상시키는 데 추가 가치가 있습니다. 코드 조각은 실제로 예상대로 작동 할 수 없습니다.

나에게 질서는 다음과 같습니다.

• 유지 가능성: 변경하기 쉽지 않다면 지금은 맞아도 오래 지속되지 않습니다.
• 재사용 성: 재사용은 생산성을 향상시키고 코드는 일반적으로 더 많은 코드보다 더 안정적입니다.
• 성능: 때로는 성능이 중요하지만 성능 중요한 응용 프로그램에서도 성능이 중요하지 않은 코드의 양에 놀랄 것입니다. 병목 현상에만 성능 최적화가 중요합니다.

Answer 10

고립된 대답에서는 사실상 항상 성능이 우선시됩니다.

이 코드 조각을 연속으로 백만 번 칠지 알 수 없으므로 기본적으로 성능이 중요합니다.우리의 귀중한 코드 조각이 어떻게 상호 작용하는지 모르기 때문에 애플리케이션의 병목 현상이 될지 여부는 알 수 없습니다.(라이브러리 코드를 작성할 때도 마찬가지입니다.이것이 어떻게 사용되고 있는지 모르겠습니다.IMO 코드를 재사용하는 이유 중 하나는 단순히 "유사한 코드를 공유 엔터티로 이동"하는 것이 아닙니다.)

유지 관리성 코드가 우리에게 알려지지 않은 코드와 상호 작용하는 방식에 훨씬 더 많은 영향을 받습니다.답변은 귀하가 설정한 범위 내에서 문제를 해결합니다.SQL, SQL Server 또는 MySQL을 요청하거나 태그를 지정할 수 있습니다.나머지는 우리가 모릅니다:비슷한 코드 경로가 몇 개나 있나요?프로젝트 기간 동안 이 코드가 얼마나 자주 변경됩니까?해당 특정 데이터베이스 서버 버전을 10년 동안 계속 사용하시겠습니까, 아니면 자주 업데이트하시겠습니까?

유지 관리 가능성을 해결하는 것은 주로 귀하의 임무입니다.격리되어야 하는 독립체에게 묻는 질문인가요?

가독성 대부분 완료되었으며 나머지는 귀하의 작업입니다.답변할 때 우리는 일반적으로 귀하가 답변을 이해하는 데 관심이 있으므로 최소한 귀하가 읽을 수 있어야 합니다.해당 조각을 코드에 복사하여 붙여넣고 // That weird query 더 이상 내 문제가 아닙니다.

여기에 성능을 더 쉽게 이해할 수 있다는 사실을 추가하십시오.기능적으로 동등한 두 가지 답변 중에서 M+R 부서에서 큰 실수를 하지 않는 한 항상 "Joe의 답변과 비슷하지만 조금 더 빠릅니다"라는 답변을 선택합니다.

---

지금 이 글을 쓰면서 성급한 최적화가 유혹을 받는 이유가 있는 것 같습니다.이것 ~이다 몇 가지 이유로 우선순위가 잘못되었습니다.

하지만 최적화 우선순위가 낮은 데에는 두 가지 주요 이유가 있습니다.

Answer 11

단정 유지 가능성, 재사용 성 또는 성능보다 중요합니다. 정확성을 목표로한다면 다른 세 가지를 할인을받을 수 있습니다.

• 필요한 것보다 더 이상 코드를 쓰지 마십시오.
• 표준 라이브러리를 활용하십시오.
• 영리에 대한 투명성을 선호합니다.
• 작고 테스트 가능한 기능을 작성하십시오.

Answer 12

태그 수에 따른 결과는 다음과 같습니다.

• 성능 -952
• 재사용 성 (몇 가지 관련 태그) -43
• 유지 가능성 -14

이것은 무엇을 의미합니까 : 성능이 중요해야합니까? 성능이 더 어렵 기 때문에 더 많은 질문이 있습니다. 성능 질문 이이 사이트에서 더 구체적/적절한가요?

Answer 13

나 하다 NASA에서 일하십시오. 그러나 (현재 어쨌든) 실시간 코드 또는 그 모든 성능이 중요한 것을 유지하거나 개발하지 않습니다. NASA에서 수행 된 대부분의 소프트웨어는 아마도 그렇지 않을 것입니다. 내 하루에 끔찍한 코드를 보았을 때, 조나단의 신뢰성과 유지 관리에 대한 답변과 성능과 대부분의 응용 프로그램에 대한 재사용 성과 함께 갈 것입니다.

Answer 14

내가 가장 좋아하는 인용문 중 하나는 SICP입니다.

"컴퓨터 프로그램은 인간이 읽을 수 있도록 설계되었으며 (Computers)에 의해 불순하게 운영됩니다."

나는 내 일의 모든 ascpect를 평가한다. 그러나 내 코드의 가독성 (일부는 표현성이라는 용어)과 내가 중요한 목록과 함께 일하는 것들이 중요합니다.

내 2C, 멋진 주말 보내세요!