"적절한"프로그래밍은 언제 더 이상 중요하지 않습니까?

여가 시간에 안드로이드 게임을 만들고 있습니다. 그것은 libgdx 라이브러리를 사용하고 있기 때문에 꽤 많은 노력이 필요합니다.

개발하는 동안 일부 절차에 대해 부주의하게 데이터 유형을 선택했습니다. 연관 배열에 가까운 것을 원했기 때문에 해시 테이블을 사용했습니다. 사람이 읽을 수있는 키 값. 비슷한 것을 달성하기 위해 다른 곳에서는 벡터를 사용합니다. libgdx에 vector2 및 vector3 클래스가 있지만 결코 사용하지는 않았습니다.

이상한 문제를 겪고 도움을 위해 스택 오버플로를 검색하면 다른 사람들이 기술적으로 "적절한"경우 특정 데이터 유형을 사용하는 질문에 답하는 사람들이 많이 있습니다. ArrayList를 사용하는 것과 같이 정의 된 경계가 필요하지 않고 새로운 알려진 경계로 int []를 다시 정의합니다. 또는 다음과 같이 사소한 것도 있습니다.

for(int i = 0; i < items.length; i ++)
{
    // do something
}

모든 반복에서 item.length를 평가한다는 것을 알고 있습니다. 그러나 아이템이 15 ~ 20 개를 넘지 않아야한다는 것도 알고 있습니다. 반복 할 때마다 items.length를 평가해야합니까?

방금 설명한 방법과 적절한 방법을 사용하여 앱의 성능을 확인하기 위해 몇 가지 테스트를 실행했으며 튜토리얼을 따르고 커뮤니티에서 제안한 정확한 데이터 유형을 사용했습니다. 결과 : 같은 것. 평균 45fps 전화와 은하계 탭에서 모든 앱을 열었습니다. 차이 없음.

그래서 나는 당신에게 내 질문이 있다고 생각합니다 : 더 이상 적절하지 않을 때 임계 값이 있습니까? "작업이 완료되는 한 신경 쓰지 않습니까?"

문제를 해결하기위한 프로그램을 작성합니다. 이 문제에는 문제 해결을위한 특정 요구 사항이 수반됩니다. 이러한 요구 사항이 충족되면 문제가 해결되고 목표가 달성됩니다.

그게 다야.

이제 모범 사례를 준수하는 이유는 일부 요구 사항은 유지 관리 성, 테스트 가능성, 성능 보증 등과 관련이 있기 때문입니다. 따라서 적절한 코딩 스타일과 같은 것을 요구하는 나와 같은 성가신 사람들이 있습니다. T를 교차시키고 I를 점으로 표시하는 데 훨씬 많은 노력이 들지 않으며 나중에 코드를 읽고 그것이 무엇인지 알아 내야하는 사람들에게 존경의 몸짓입니다.

대형 시스템의 경우 이러한 종류의 구속과 훈련은 필수적입니다. 다른 모든 시스템과 잘 작동해야 프로젝트가 자체적으로 무너지지 않도록 기술적 부채를 최소화해야하기 때문입니다.

스펙트럼의 반대편에는 현재 특정 문제를 해결하기 위해 작성하는 일회용 유틸리티, 다시는 사용하지 않는 유틸리티가 있습니다. 이러한 경우 스타일과 모범 사례는 전혀 관련이 없습니다. 당신은 일을 함께 해킹하고 실행하고 다음 일에 착수합니다.

따라서 소프트웨어 개발에서 많은 것들과 마찬가지로, 그것은 의존합니다.

현명한 인용구가있다. "노인의 발자취를 따르지 마라. 그들이 찾은 것을 찾으 라." '적절한'코딩의 모든 규칙에는 이유가 있습니다. 이러한 규칙이 존재하는 이유를 아는 것이 해당 규칙이 무엇인지 아는 것보다 중요합니다.

그런 식으로 for 루프에서 반복적으로 다시 계산할 수있는 테스트를 수행해서는 안되는 규칙이 있습니다. 규칙이 해결되도록 고안된 경우 (성능이 실제로 다를 수 있음), 이치에 맞습니다. 이 경우 정답은 하나뿐입니다. 귀하의 예에서는 성능 차이가 없으며 수십 번의 반복이 불가능하다는 것을 알고 있습니다. 이 경우 어쨌든 규칙을 적용 할 수있는 두 가지 정답이 있습니다. 규칙이 단순하고 아무 것도 해치지 않으며 좋은 습관을 형성하는 데 도움이 될 수 있기 때문에 걱정할 성능 차이가 없으므로 규칙을 무시하는 것입니다.

나는 첫 번째 정답을 선호하고 두 번째 답을 선호하는 것처럼 보입니다. 당신은 그것에 대해 틀리지 않습니다. 나는 '적절한'프로그래밍이 무엇인지에 대한 당신의 생각이 틀렸다고 생각합니다. 그것은 당신에게 도움이되지 않고 목적이없는 무작위로 선택된 규칙 집합을 따르는 것이 아닙니다. 예제에서 for 루프를 수정하지 않으면 실제로 조기 최적화에 대한 매우 좋은 규칙을 따릅니다.

실제 적절한 프로그래밍은 지능적인 방식으로 이해하기 좋은 규칙을 따르는 것입니다.

이를 보는 올바른 방법은 수익을 줄이는 것입니다. 프로그램 개발의 추가 이점을 추가 개발 비용과 비교합니다.

한계 이익이 한계 시간 / 노력보다 적을 때 수익률이 감소합니다.

루프 items.length밖으로 나가기 위한 비즈니스 사례를 만들 수 있습니까 for? 경제적으로, 그러한 변화는 그것을 정당화하는 데 소비 한 시간을 정당화 할 수 있습니까? 사용자 경험에는 차이가 없으므로 측정 시간 (기억해야 할 유용한 교훈을 제외하고)까지도 아무 것도 얻지 못합니다. 사용자는 프로그램보다 더 이상 프로그램을 좋아하지 않으며 변경으로 인해 더 많은 사본이 판매되지 않습니다.

비즈니스 사례는 알 수없는 위험과 위험으로 가득 차 있기 때문에 항상 평가하기 쉽지는 않습니다. 따라서 이해하지 못하는 요소에 노출 될 수 있습니다. 제안 된 변경은 큰 차이가 없도록 완전히 사소하지 않을 수 있습니다.

반품 유형의 사고는 행동을 취하지 않는 변명을 찾고, 위험을 피하는 것을 피할 수 있습니다.

그러나 때로는 무언가를하지 않아야 할 때 분명 합니다. 개발 비용 중 일부가 개발 비용을 지불하기 위해 경제 기적을 요구하는 것처럼 보이는 경우 (아직도) 나쁜 생각 일 수 있습니다.

"적절한"코드를 신경 쓰지 않아야 할 때

• 비즈니스 목표를 달성하고 시간이 지남에 따라 오버 헤드를 낮게 유지하십시오. (사용자는 지불하기 전에 소스를 보지 않습니다)
• MVP / POC-적절한 코드를 작성하는 것이 돈을 버는 방법을 알기 전에 개념에 시간을 낭비하는 것을 의미하는 경우 (수년과 4 천 5 백만 달러를 앱을 작성하고 시장이 없어서 상점을 폐쇄하는 경우 아무도 신경 쓰지 않습니다. 적절한 코드였습니다)
• 생명을 위협하는 상황에 처했을 때 (예 : 아이언 맨 프로토 타입 1은 더러운 핵 이었지만, 동굴 밖으로 나갔습니까?)
• 또는 단순히 올바른 코드를 작성하는 방법을 모른다면 (일부 사람이 적절한 코드를 작성하지 않고 현재 코드를 작성하는 경우 노숙자보다 나쁜 코드를 작성하는 것이 좋습니다)
• 단순히 자신이하는 일을 알고 있거나 자신을 가장하여 도망 칠 수 있다고 생각한다면

적절한 코드를 작성하는시기

• 비즈니스에 중대한 영향을 미치는 경우 (예 : 성과가 수익에 영향을 미치거나 판매를 방해 할 수 있음)
• 코드를 유지 관리하는 것이 비즈니스 문제가되는 것이 적절하지 않은 경우 (높은 유지 관리 비용)
• 대규모 오픈 소스 프로젝트를 수행하는 알려진 프로그래머 인 경우
• 사내 도서관을 세계에 제공하는 대기업과 동일
• 향후 인터뷰에서 작품을 포트폴리오로 보여주고 싶다면

성능이 주요 관심사입니까? 그것이 당신이 극대화하려는 것입니까?

그렇다면 배우는 기본 교훈이 있으며, 그렇게하면 몇 안되는 사람이 될 것입니다.

더 빨리하기 위해해야 ​​할 일을 "생각"하려고하지 마십시오. "이 컨테이너 클래스를 사용해야합니까?"또는 " length루프 상태를 설정해야합니까?" 환자에게 질문 또는 검사.

추측하고 있습니다. 모두가 그것을하지만 작동하지 않습니다.

대신 프로그램 자체에 문제가 무엇인지 알려주십시오. 자세한 예는 다음과 같습니다.

차이점이 보입니까?

귀하의 질문은 "작업이 완료되는 한 신경 쓰지 않습니까?"입니다.

제 대답은 "코드에 어떤 일이 일어날 지 전혀 모른다"입니다. "사용자 문제를 해결하기 위해이 빠른 작업을 작성하겠습니다."로 시작한 많은 프로젝트에 참여했습니다. 그것을 쓰고, 거기에 넣고, 다시는 생각하지 마십시오.

한 번, 내가 쓴 것은 "오, 이제 사용자 부서 전체가 그 코드를 사용하고 싶다"로 바뀌 었습니다.이 코드를 사용하기 전에 "회사 전체가 해당 코드를 사용하고 있으며 이제는 감사에서 살아남을 것임을 증명해야합니다" 내일 예정된 20 명 코드 검토가 있으며 일부 부사장이 이미 고객에게 판매했습니다. "

나는 당신이 "여가 시간에 안드로이드 게임을 작성하고있다"는 것을 알고 있지만, 그 게임이 이륙하여 명성과 행운의 표가 될지 결코 알 수 없습니다. 더 나쁜 것은, 그 게임은 사람들의 전화를 계속 부수기 때문에 악의적 인 티켓이 될 수 있습니다. 누군가의 자녀가 휴대 전화에서 게임을하는 것을 멈출 수 없기 때문에 구인을 받고 싶은 사람이되고 싶습니까, 아니면 이와 같은 게시판에서 비방을받는 사람이되고 싶습니까?

대답은 결코 중요하지 않으며 항상 중요하다는 것입니다.

적절한 프로그래밍이든 아니든 프로그래밍은 목표 자체가 아니라 목표를 달성하는 방법이기 때문에 중요하지 않습니다. "적절한"프로그래밍없이 그 목표를 달성하면 괜찮습니다 (비즈니스 관점에서는 프로그래밍없이 목표를 달성 할 수있는 것이 가장 좋습니다).

적절한 프로그래밍은 목표 달성에 도움이되는 도구이기 때문에 항상 중요합니다. 일을하는 올바른 방법은 단순히 다른 방법으로하는 것이 장기적으로는 절약하는 것보다 더 많은 고통을 초래한다는 인식입니다.

어느 것이 당신이 그것을 무시할 수 있는지에 대한 질문에 대답합니다-장기적으로 다른 방법이 더 쉬울 것이라고 확신 할 때 (아마도 장기가 없기 때문에).

일회용 도구는 일반적으로 오류 점검이나 기타 유효성 검사가 거의 또는 전혀없고, 예외 로깅, 일반적인 변경 대신 약간의 변경 또는 변경이없는 cut-n-paste 코드 등을 사용하여 최대한 빠르고 더러운 작업을 수행합니다. .

그냥 조심하십시오 : 때로는 그 빠르고 더러운 앱이 자신의 삶을 사로 잡습니다.

또는 다음과 같이 사소한 것도 있습니다.

for(int i = 0; i < items.length;i ++) {
     // do something 
}

모든 반복에서 item.length를 평가한다는 것을 알고 있습니다. 그러나 아이템이 15 ~ 20 개를 넘지 않아야한다는 것도 알고 있습니다. 반복 할 때마다 items.length를 평가해야합니까?

실제로 최종 코드에서 items.length는 컴파일러가 최적화하기 때문에 모든 반복에서 평가되지 않습니다. 그렇지 않은 경우에도 length는 배열 객체의 공용 필드입니다. 비용이 들지 않습니다.

그래서 나는 당신에게 내 질문이 있다고 생각합니다 : 더 이상 적절하지 않을 때 임계 값이 있습니까? "작업이 완료되는 한, 신경 쓰지 않습니까?"라고 말할 수 있습니까?

실제로 최종 제품에서 기대하는 바에 따라 다릅니다. 평균적인 제품과 훌륭한 제품의 차이점은 세부적으로 의존합니다. Tata Nano와 같은 자동차와 Mercedes S와 같은 자동차는 "작업을 수행합니다"-한 곳에서 다른 곳으로 이동합니다. 차이점은 엔진 출력, 편안함, 안전 및 기타 세부 사항에 달려 있습니다. 소프트웨어 제품을 포함하여 존재하는 모든 제품과 동일합니다. 예를 들어 MySQL과 Postgre가 무료이기 때문에 Oracle, IBM 또는 Microsoft에 Oracle 데이터베이스, DB2 또는 MS SQL Server를 지불하는 이유는 무엇입니까?

세부 사항에주의를 기울이고 고품질의 제품을 얻으려면이 물건 (및 다른 물건, 분명히)에 관심을 가져야합니다.

집에서 직접 프로그래밍하는 경우 몇 구석을자를 수 있습니다. 그리고 당신이 실험하고 시도 할 때 이것은 완전히 정당화됩니다.

그러나 조심하십시오. 이 예에서는 실제로 해당 모서리를자를 필요가 없으므로주의해야합니다. 이것은 추세를 시작하고 집에서하는 나쁜 습관이 직장에서 코드에 영향을 줄 수 있습니다. 집에서 좋은 습관을 연습하고 개선하고 직장에서 코드를 살펴 보는 것이 훨씬 좋습니다. 그것은 당신을 도울 것이고 다른 사람들을 도울 것입니다.

당신이하는 프로그래밍과 프로그래밍에 대한 당신의 생각은 운동입니다. 가치있게 만드십시오. 그렇지 않으면 돌아와서 물릴 것입니다.

그래도 좋은 편을보세요. 당신은 이것에 대해 물었으므로 아마도 내가 만들고있는 요점을 이미 알고있을 것입니다.

가구 제조업체가 품질이 가장 중요하지 않은 곳이나 품질이 눈에 띄지 않는 곳에서 사용할 가구를 만들고 있다면 여전히 똑바로 자르려고 노력하고 조각을 결합하는 적절한 일을해야합니까?

많은 사람들이 소프트웨어를 장인 정신이라고 생각합니다. 우리가 구축하는 것은 기능을 수행 할뿐만 아니라 신뢰성, 유지 보수성, 견고성을 갖추어야합니다. 이러한 소프트웨어를 만들려면 기술이 필요하며이 기술은 실습에서 비롯됩니다.

따라서 오늘날 작업하고있는 것에 대해 루핑 구조를 선택하는 것은 중요하지 않지만 항상 올바른 구조를 사용하려고 노력한다는 사실은 시간이 지남에 따라 더 나은 프로그래머가 될 것입니다.