복잡한 것에 접근하는 방법은 무엇입니까?

Question

프로젝트에 필수적이지만 코드를 완료하는 데 많은 시간이 걸릴 코드의 특정 부분을 알고 있습니까?해당 부분을 작업하는 것보다 다른 작업(아마 덜 중요할 수도 있음)을 수행하거나 코드를 전혀 작성하지 않고 싶다는 느낌을 받은 적이 있습니까?피할 수 없는 구현을 지연시키기 위해 당신이 알고 있는 모든 게으른 속임수를 피하고 사용하기 위해 그렇게 열심히 노력하는 그 짐승?

제가 게으른 것일 수도 있지만 항상 그런 코드를 처리해야 했습니다.쓰고 싶지 않은 글을 쓰세요(그리고 재미로 하고 돈을 받지 못한다면 더 나쁩니다!).유용한 결과나 작동 징후를 다시 얻을 수 있는 단계로 전환하는 데 많은 시간이 걸리는 대규모 시스템입니다.그런 코딩을 어떻게 시작하나요?대부분의 사람들은 아마도 분할 정복 및 유사한 건축 기술을 제안할 것입니다. 그러나 이것은 그것을 수행하는 방법에 관한 것이 아닙니다.그것은 당신이 그것을 시작하는 방법에 관한 것입니다.당신이 취할 첫 번째 단계는 무엇입니까?

Answer 1

나는 이것이 나에게 일어난 사건에 대한 이야기를 들려 줄 것이다.

전진 동적 프로그래밍 (Viterbi 알고리즘)을 사용한 X264에 대한 새로운 Frametype 결정 알고리즘을 구현하고 싶었습니다. 그러나 그것은 복잡하고, 지저분하고, 못생긴 등이 될 것입니다. 그리고 나는 정말로 그것을하고 싶지 않았습니다. 나는 프로젝트를 Google Summer of Code로 찍으려고 노력했지만, 우리가 단순히 그의 프로젝트에 대해 구제 한 한 학생은 그 프로젝트를 선택한 학생이었습니다.

그래서 2 개월 동안 그것에 대해 불평하고 피한 후, 나는 마침내 알고리즘 작업을 시작했습니다. 그리고 여기 내가 한 방법이 있습니다.

먼저, 나는 이미 그것을하는 방법에 대한 아이디어를 이미 가지고있는 다른 개발자와 이야기했습니다. 우리는 그것을 이야기했고, 나는 알고리즘 적 관점에서 프로세스를 완전히 이해할 때까지 그는 그것을 설명했다. 이것은 그러한 프로젝트의 첫 번째 단계입니다. 뒤에있는 알고리즘을 너무 잘 이해하여 전체를 의사 코딩 할 수 있습니다.

그런 다음 다른 동료와 이야기했습니다. 우리는 화이트 보드에 올라 갔고 나는 그것을 스케치했다 그 그것을 이해했습니다. 다른 사람에게 설명함으로써 나는 나 자신을 이해했다. 이것은 두 번째 단계입니다. 다른 사람에게 알고리즘을 설명합니다. 그들 pseudocode를 할 수 있습니다. 프로그래밍은 프로그래밍 프로세스의 에뮬레이션입니다. 프로그래밍은 컴퓨터에 대한 알고리즘을 "설명"하는 형태이기 때문입니다.

그런 다음 비용 기능에 임의의 가짜 값을 사용한 간단한 Java 프로토 타입을 작성했으며 Viterbi 검색을 테스트하는 데 전적으로 사용되었습니다. 나는 그것을 완성하고 철저한 검색에 대해 확인했습니다. 완벽하게 일치했습니다. 내 동적 프로그래밍이 정확했습니다. 이것은 세 번째 단계입니다. 가장 간단한 가능한 환경에서 가장 간단한 알고리즘 형태의 알고리즘을 작성하십시오.

그런 다음 x264의 모국어 C, C로 포팅했습니다. 다시 작동했습니다. 이것은 네 번째 단계입니다. 포트는 전체 환경에 대한 간단한 형태의 알고리즘 형태입니다.

그런 다음 마침내 가짜 비용 기능을 실제 비용으로 교체했습니다. 약간의 부기와 고정 후, 그것은 효과가있었습니다. 이것이 최종 단계입니다. 알고리즘을 환경과 완전히 통합합니다.

이 과정은 거의 일주일이 걸렸지 만 프로젝트가 시작될 때 저의 관점에서 완전히 어려웠으며 나는 심지어 시작할 수 없었습니다. 나는뿐만 아니라 할 수 있었다 끝내십시오, 그러나 내가 예상했던 것보다 훨씬 빨리 끝내십시오.

그리고 혜택은 X264를 훨씬 뛰어 넘었습니다. 나는 이제 Viterbi가 너무 철저히 이해하여 이제 다른 사람들에게 설명 할 수 있습니다 ... 그리고 다른 사람들은 그것으로부터 큰 혜택을 줄 수 있습니다. 예를 들어, FFMPEG 개발자 중 하나는 내 알고리즘과 코드의 적응을 사용하여 오디오 파일의 최적의 헤더 배치 인 다소 다른 문제를 최적으로 해결하기 위해 노력하고 있습니다.

Answer 2

일반적으로 나는 크고 복잡한 부분을 좋아합니다. 그것들은 실제로 도전을 확장하고 내가하는 일을 신중하게 고려하도록 강요하는 부분입니다. 내가 싫어하는 작고 지루한 비트입니다. 그러나, 내가 한 일을하는 것과 관련하여 나는 간단한 조언이 중요하다고 생각합니다.

그냥 해!!!

진지하게, 일단 시작되면 마무리하기가 훨씬 쉽습니다. 나는 항상 내가 그들을 시작할 때까지 물건을 끄는 것을 발견 한 다음 갑자기, 나는 내가 시작한 지금 내가 상상했던 것만 큼 나쁘지 않으며, 거의 거의 끝났다는 것을 알았습니다!

Answer 3

분할 및 정복은 코드를 구조화하는 것뿐만 아니라 프로젝트를 개념적으로 관리 가능하게 만드는 접근 방식으로도 작동합니다.프로젝트를 시작하는 데 어려움을 겪는다면 거의 항상 그 이유는 프로젝트가 너무 크고 규모가 크기 때문입니다. 무서운.개념적으로 관리 가능한 부분으로 나누면 덜 무섭습니다.

나 역시 "를 믿는다.추적자 총알" 실용적인 프로그래머가 설명한대로입니다. 줄이다 핵심 부품에 대해 가능한 가장 간단한 "개념 증명"을 위한 프로젝트입니다.UI, 특별한 경우, 오류 처리 등이 없습니다.아마도 관련 단위 테스트가 포함된 몇 가지 핵심 루틴일 것입니다.이를 통해 무서운 부분을 정복하고 핵심부터 구축할 수 있습니다.

기본적으로 (적어도 나에게는) 시작하는 요령은 다음과 같습니다.전체 프로젝트를 시작하지 마십시오.하나의 작은(가급적 핵심) 부품에서 시작하여 거기서부터 구축해 보세요.만약 내가 아직 시작하기 힘드시죠, 제가 결정한 작은 부분이 아직 너무 크기 때문에 더 나누어서 줄여야 겠습니다.

Answer 4

소프트웨어의 많은 크고 중요한 부분이 글을 쓰는 것이 재미 있지 않다는 데 동의합니다. 나는 일반적으로 여기에 기능을 추가하거나 버그를 수정하는 것과 같은 작은 것들로 개발 일을 시작합니다. 시간이되면 큰 부분으로 시작하지만 더 이상 물건을 볼 수 없을 때 다른 일을합니다. 당신이 여전히 정시에 모든 것을 끝내면 괜찮습니다. 그리고 당신이하기 전에, 그리고 당신이하고있는 동안, 그리고 끝난 후에 그 큰 짐승에 대해 다른 사람들과 이야기하면 일이 쉬워 질 수 있습니다. 이것은 당신의 마음을 자유롭게 할뿐만 아니라 덜 주관적인 관점에서 다른 사람들의 의견을 얻을 수 있습니다. 그러한 것들을 함께 계획하는 것도 도움이됩니다.

Answer 5

재밌 네요, 나는 다른 방법입니다. 문제를 해결하기 시작하면 먼저 큰 문제가됩니다. 문제의 핵심은 일반적으로 나에게 관심이있는 것입니다.

내가 나 자신을 위해 프로젝트를하고 있다면, 나는 보통 가장자리 주위의 퍼지 비트를 구현하는 것을 귀찮게 할 수 없었기 때문에 결코 끝나지 않습니다. 내가 진짜로 무언가를하고 있다면 결국 모든 퍼지 비트에 도달하지만 제가 가장 좋아하는 부분은 아닙니다.

Answer 6

여기에는 두 가지 문제가 있다고 생각합니다.

먼저 실제로 시작하는 것입니다. 당신이 말했듯이, 그것은 꽤 까다로울 수 있습니다. 개인적으로 나는 단지 약간의 시작을 시작합니다. 단지 종이/화면에 무언가를 얻습니다. 아마도 잘못되었고 편집이 필요하지만 일반적으로 자신의 작업에서도 생성하는 것보다 비판하는 것이 더 쉽습니다.

그런 다음 어려운 문제를 해결하는 실제 과정이 있습니다. 다양한 문제에 접근하는 방법을 논의하는 "개념적 블록 버스트"라는 훌륭한 책이 있습니다. 나는 문제 해결에 어떻게 접근하는지에 대해 많은 것을 배웠고 그 책을 사용하여 블라인드 스팟에 대해 많은 것을 배웠습니다. 추천.

Answer 7

나는 시스템이 무엇을하려고하는지에 대한 은유를 확립하려고 노력합니다. 나는 은유의 관점에서 행동을 묘사 할 수있을 때 항상 더 편안하다고 느낍니다.

그런 다음 테스트 중심의 개발 관점에서 접근합니다. 즉, 올바른 동작을 확인하는 테스트를 설정하여 시스템이 무엇을 해야하는지 설명합니다.

HTH.

건배,

롭

Answer 8

프로젝트의 가장 어려운 부분은 아무것도하지 않는 것부터 첫 번째 줄로가는 것입니다. 종이에 아무것도 내려 놓으면이 과정이 시작되면 나머지가 얼마나 빨리 흐를 수 있는지 놀랍습니다.

나는 "팬"나누고 정복하십시오"-유형은 나 자신에게 접근한다.

나에게 매달려있는 시스템에 특별한 큰 작업이있을 때, 나는 컴퓨터를 떠나 펜과 종이를 가져다가 논리적 구성 요소와 작업 흐름의 모든 작업을 분해합니다.

그런 다음 이러한 각 작업을 수행하고 필요한 가장 기본적인 기능 / 호출로 분류하십시오.

그런 다음 필요한 스텁 방법을 넣을 수 있습니다. 그리고 그들을 하나씩 살펴보십시오. 이 시점에서 이러한 각 "하위 작업"은 동일한 프로젝트를 공전하는 소규모 개발 작업보다 크지 않으므로 훨씬 덜 덜한 작업처럼 느껴집니다.

Answer 9

나는 보통 펜과 종이 조각을 사용하여 집에서 이런 종류의 문제를 해결합니다. 나는 알고리즘 및/또는 논리적 흐름을 상상하고 (종이에 포함!) 클래스와 방법 스터브와 내가 /컴퓨터가 훨씬 쉽게 할 수 있습니다 ... 아마도 나일 것입니다 ..