같은 방식으로 많은 문제를 해결할 경우 걱정해야합니까?

저는 프로그래밍 게임과 퍼즐 제작자 / 게임을 정말 좋아합니다. 나는 이러한 많은 문제를 같은 방식으로 엔지니어링하고 궁극적으로 비슷한 기술을 사용하여 내가 정말로 편한 문제를 프로그래밍한다고 생각합니다.

간단한 통찰력을주기 위해 노드가 객체로 표현되는 그래프를 만들고 싶습니다. 이 객체는 좌표, 위치 및 물론 다른 주변 객체에 대한 참조와 같은 데이터를 보유합니다. 그것들을 모두 데이터 구조에 배치하고 "게임 루프"에서이 정보를 결정합니다.

이것은 간단한 예이지만 모든 상황에서 정확한 것은 아닙니다. 정말 편하게 느끼는 방법 중 하나입니다. 이게 나쁜가요?

아냐 괜찮아

실용적인 프로그래밍의 요점은 많은 유사한 개발에 유용 할 수있는 솔루션을 찾는 것입니다. 당신은 하나를 발견했습니다.

서로 다른 솔루션을 위해 다른 솔루션을 만들 수 없으며 그렇게해서는 안됩니다. 그러나 매번 솔루션을 비판적으로 살펴보고 솔루션이 여전히 좋은지 또는 그 이후로 산업이 발전했는지 스스로에게 물어보고 그에 따라 조정해야합니다.

잘 작동하면 디자인 패턴이라고 부릅니다. 그렇지 않지만 더 잘 모른다면 황금 망치 반 패턴입니다.

현실적으로 우리의 직업에서 우리는 상당히 많은 비슷한 문제를 제기하는 경향이 있습니다.

이러한 상황에서는 자신이 알고있는 것을 고수하는 것이 좋습니다. 나는 사람들이 비 이상적인 기술을 잘 사용한다는 것을 이해하지 못하는 것을 구현하는 사람들의 나쁜 해결책에 대한 더 많은 예를 보았습니다.

무언가를 잘 알고 있다면 필요에 따라 유연성을 높일 수 있고 구현이 확실하고 효과적 일 것입니다. 새로운 기술에 대한 첫 시도에서 그러한 것들이 사실이 아닐 수도 있습니다.

그러나 반대로 당신이 가진 모든 것이 망치라면 모든 것이 못처럼 보입니다. 대안을 알기 위해 그리고 즐겨 찾기를 너무 많이 밀었을 때 자신이해야 할 일을해야합니다.

어쩌면 긴급하지 않거나 중요하지 않은 몇 가지 변경 사항을 선택하여 다른 솔루션을 사용하는 데 도움이 될 수 있습니까?

좋은 질문입니다. 그리고 이것 또한 저를 괴롭히는 것임을 인정해야합니다.

이것은 언제 괜찮습니까? 코드의 성능 분석을 수행하십시오-O (log n) 또는 O (n) 또는 O (n log n)에 있고 문제가 알려진 데이터 구조에 매핑 가능한 경우 일반적으로 괜찮습니다.

언제가 좋지 않습니까? 시간이나 공간의 복잡성이 O (n ^ 2) 이상이거나 정의상 문제가 NP 완료입니다. 이러한 상황에서는 약간의 휴리스틱을 적용하고 다른 영역의 지식을 적용해야합니다.

빠른 예 : 칩 설계에서 최소 전력을 위해 회로에서 게이트를 배열하는 방법을 선택하는 것은 NP- 완료입니다. 그래프만으로도 필요한 것은 아니지만 많은 도움이되지 않습니다. 추가 자료를 읽고, 때때로 많은 학제 간 자료를 읽고 도메인에 지식을 적용해야합니다. 예를 들어, 유전자 알고리즘 (생물학 101에 정의 된 바와 같이 유전자 크로스 오버 및 돌연변이를 모방하는 알고리즘)은 하드웨어 칩 설계에 많은 응용이있다.

반드시 해결하는 것이 좋은 방법은 아닙니다. :)

일반적으로 "솔루션"을 작업 할 때는 다음과 같은 순서로 진행합니다.

• 단순성 ,
• 재사용 ,
• 그리고 마지막 성능 만 .

그 성능은 중요하지 않습니다. 성능을 염두에두고 디자인했지만 너무 멀리 밀어 넣지 마십시오. (StringUtils.isEmpty와 같은 유틸리티 메서드를 호출하거나 같은 흐름에서 이와 비슷한 것을 호출 해야하는 경우) t 마음). 그런 다음 성능이 필요한 경우 (비즈니스 사례 또는 사용자 경험 문제) 간단하고 재사용 가능한 방법과 다른 접근법을 사용합니다. 실용적입니다.

이상하게도 C로 코딩 할 때 Java로 코딩 할 때보 다 성능에 더 관심이 있습니다 ... 습관의 힘 :))

문제가 효율적으로 해결되는 한 걱정할 필요가 없습니다.

나는 그래프가 의사 결정을 나타내는 게임을 디자인하기에 적합한 디자인이라고 생각합니다. 아마도 이것이 세련되고 더 효율적일 수 있으며 다른 도메인에 가장 적합한 솔루션이 아닐 수도 있습니다.

작동하면 괜찮습니다.

하나의 단일 기술에 지나치게 의존하는 것에 대해 걱정이된다면 솔루션을 사용할 수 없게 만드는 해결 된 문제의 변형을 생각해보십시오. 변경 사항을 일반화하여 일반적인 프로세스의 적용 가능한 공간을 정의 할 수있는 경우 추가 포인트

문제를 해결하면 좋습니다. 더 이상 문제를 일으키지 않을 때까지 어떤 방법으로도 문제가되지 않습니다.

당신의 목표가 제품을 생산하는 것이라면 "개발자 예술"은 실제로 정답을 가지고 있습니다. 그리고 "공장"이 만족스러운 제품을 생산한다면 시원합니다.

그러나...

일을하는 새로운 (그리고 잠재적으로 더 나은) 방법을 배우고 싶다면 일을 바꿔야합니다. 이것은 실패를 일으키지 만 실패를 통해서만 실제로 배우게됩니다. 그리고이 새로운 학습을 통해 더욱 우수하고 매력적인 소프트웨어를 제작할 수 있습니다.

이것은 실제로 신경 학적 연구를 통해 백업됩니다. 그래서 당신은 간다.