모순되는 프로그래밍 조언 조정 : 코딩하기 전에 무언가를 생각하고 반복하는 것과 실제로 생각하는 것

나는 석사 학위의 중간 정도 인 몇 년의 전문적인 경험을 가진 중급 프로그래머입니다. 프로그램을 배우면서 종종 모순되는 두 가지 조언을 들었습니다.

첫 번째 조언은 빠르게 작동하는 무언가를 얻고, 프로토 타입 또는 비공식 테스트를 통해 작동하는 방식을 확인하고, 버전을 개선하고, 작동 방식을 다시 확인하고, 다시 개선하고, 완료 할 때까지주기를 반복하는 것이 었습니다. . 이것은 때때로 "나선 개발"또는 "일찍 출시, 자주 출시"로 표시됩니다.

두 번째 조언은 코드를 작성하기 전에 프로젝트를 생각하는 것입니다.

나는 두 가지 방법으로 성공했으며 각 철학에 동의한다고 말하고 싶습니다.

그러나 이제는 분산 응용 프로그램 및 성능 중심 그래픽 프로그래밍과 같이 완료하는 방법을 모르는 훨씬 더 복잡한 프로젝트를 다루기 시작했습니다.

이 프로젝트를 어떻게 진행합니까?

SOMETHING 코딩을 시작하고 진행하면서 학습 (플랫폼 / 방법 / 언어 / 아키텍처)을 수행합니까? 아니면 IDE를 열기 전에 코딩을 중단하고 많은 연구 / 읽기를 수행합니까?

이러한 모순되는 프로그래밍 조언을 어떻게 조정합니까?

미리 문제에 대해 생각하는 것과 반복적 인 접근법이 서로 모순된다고 확신하지 않습니다. 다른 많은 것들과 마찬가지로, 나는 당신이 둘 사이의 균형을 이루기 위해 노력해야한다고 생각합니다. 균형을 어떻게 찾습니까? 그것은 당신이 경험으로 배우고 종종 시간에 가장 좋은 교훈 (즉, 당신에게 경험을주는 것들)은 당신이 그것을 올바르게 얻지 못했을 때입니다 (또는 더 나은 교훈 : 그냥 평평하게하십시오). 이미 지적했듯이 "빠른 릴리스, 자주 릴리스"라는 문구가 있습니다. 또 다른 비슷한 것이 있는데, "초기 실패, 빨리 실패, 자주 실패"

미리 생각하는 것은 위대하며 절대적으로해야합니다. 그러나 경험이 있으면 데이터를 모두 가지고 있지 않아도 생각을 멈추고 무언가를 구축하는시기를 배우십시오. 그것을 구축함으로써, 당신은 문제 영역에 대한 더 많은 통찰력을 얻고 잠재적으로 훨씬 더 나은 솔루션을 얻을 수 있습니다. 그래서 나는 다른 것을 배제하지 말고 "생각"을 반복의 일부로 만들고 시간이 지남에 따라이 질문에 대한 올바른 대답을 스스로 찾을 것이라고 생각합니다.

작은 예입니다. 다른 날 저는 소프트웨어 디자인 결정에 어려움을 겪고있었습니다. 뒤늦게 보면 비교적 사소한 것이었지만 두 가지 대안이 있었고 두 가지 모두 효과가있는 것처럼 보였습니다. 나는 각각의 장단점으로 계속 돌면서 돌아 서서 내 결정을 재고했다. 되돌아 보면, 내가 생각하는 데 얼마나 많은 시간이 걸 렸는지 조금 당황 스럽습니다. 그런 다음 나는 나 자신에게 말했다, f # @ k 그것! 그리고 디자인 중 하나를 사용하는 대신 방금 가서 코드를 해킹하여 좋은 디자인에 대해 배우는 모든 좋은 것을 완전히 무시했습니다. 약 45 분 안에 기능이 작동합니다. 그런 다음 돌아가서 내 코드를 살펴보고 소스 컨트롤을 확인하는 데 부끄러워하지 않는 견고한 소스로 리팩토링했습니다. 재미있는 부분은 해킹 작업을 마친 후 "

현재 직면하고있는 문제 (특히 크고 복잡한 과제가 계속 진행되고 있음)에 대해 특별히 권장하는 또 다른 사항입니다. 직렬로 작업하는 대신 병렬로 수행하십시오. 최소한 하루 동안 연구를 한 다음, 중지하고, 기어와 코드를 전환하여 적어도 알려지지 않은 프로젝트 부분에 하루를 보내십시오. 이 방법으로 코드에 가까이 머무르면 더 나은 시야를 확보 할 수 있으며 너무 많은 정보를 너무 빨리 흡수하여 화상을 입지 않아도됩니다. 적어도 몇 시간의 연구 끝에 뇌가 물건을 소화하고 작업을 전환하며 잠시 동안 다른 일을하는 것이 좋습니다. 그런 다음 더 많은 연구로 돌아옵니다.

미리 결정해야 할 특정 결정이 있습니다.

웹 응용 프로그램을 만들고 있습니까? 그런 다음 전체 아키텍처가 어떤 모습인지 알아야합니다. MVC와 같은 아키텍처는 이미 라우팅, 컨트롤러, 모델, 서비스 계층, 통신 프로토콜 등과 같은 대규모 기능 요소를 정의합니다. 처음부터 모든 것을 발명하는 것은 오래 걸리고 불필요하며 아마도 이미 발명 된 것보다 열등 할 것입니다.

개체 또는 데이터 수집과 관련된 모든 종류의 응용 프로그램을 작성하고 있습니까? 그런 다음 특정 시나리오에 가장 적합한 데이터 구조 종류와 성능 특성이 무엇인지 알아야합니다. 빠른 조회 시간이 필요하십니까? 주문 된 데이터 세트는 어떻습니까? 인 메모리 컬렉션이 있습니까, 아니면 데이터베이스와 같은 더 강력한 산업이 필요합니까? 이러한 결정을 생각하지 않고 코딩을 시작할 수는 없습니다. 잘못 선택하면 다시 시작해야하기 때문입니다.

즉, 일단 기술적 결정이 내려지면 설정 한 프레임 워크 내에서 자유를 얻게됩니다. 그런 다음 목표는 고객이 원하는 것에 대해 마음이 바뀔 때 최소한의 번거 로움을 수용 할 수 있도록 유연하고 반복적이며 민첩하게 유지하는 것입니다.

어떻게합니까? 주로 경험하십시오. 누군가가 한 번 말했듯이 경험은 필요할 때 바로 얻는 것입니다. 그러나 다른 플랫폼 (라이브러리, 라이브러리 및 기타 거래 도구에 구현 된)의 성공적인 디자인 결정을 따르는 경우 이들을 통해 배우고 위험을 줄일 수 있습니다.

나는 둘을 상호 배타적 인 것으로 보지 않습니다.

모든 종류의 프로젝트 관리와 마찬가지로 장기 비전과 단기 목표가 모두 필요합니다.

전자가 없으면 사용하지 않는 기능에 대한 시간을 낭비하게되고 후자가 없으면 프로젝트를 완료하지 않고 완벽한 응용 프로그램을 만드는 방법을 하루 종일 쓸 것입니다.

얼마나 자주 당신이 릴리스 / 등. 사용중인 특정 방법론에 따라 다릅니다.

연구해야 할 것은 알고있는 것과 편안하지 않은 것에 따라 다릅니다.

"반복"과 "생각"은 상충되는 것이 아니라 상호 보완 적입니다.

극단적 인 경우에도 동일한 장소에 도달하기위한 두 가지 경로를 반영합니다.

• 반복의 극단은 수천 개의 원숭이가 수천 개의 키보드를 두드리는 것입니다. 충분한 시간이 있으면 요구 사항을 충족하는 것을 얻을 수 있습니다.
• "생각해 보는 것"의 극단은 폭포 방식입니다. 운이 좋으면 코드를 제공 할 때까지 프로젝트 시작부터 요구 사항이 크게 바뀌지 않았습니다. 또는 분석 마비로 끝나고 아무것도 제공하지 않습니다.

코딩을 시작하기 전에 도메인과 문제를 이해해야합니다. 이것은 "생각"부분입니다. 이상적으로는 문제를 해결하는 방법에 대한 높은 수준의 경로를 처음부터 끝까지 볼 수 있습니다.

그러나 당신은 그 길의 주요 부분만을 볼 수있을 것입니다. 그것이 반복이 시작되는 곳입니다. 다음을 수행하기 위해 애플리케이션 버전을 반복하고 피드백을 요청할 수 있습니다.

• 더 낮은 수준의 세부 사항에서 나타나는 장애물을 식별하십시오.
• 이해 관계자 피드백을 참조하여 높은 수준의 어두운 영역을 명확하게하십시오.

결정 의 라틴어 루트는 "잘라 내기"를 의미합니다. 반복을 통해 이론 대신 실제로 작동하는 것을 결정할 수 있으며 반복을 통해 실현 불가능한 다른 옵션을 제거 할 수 있습니다.

따라서 수행하려는 작업을 이해하려면 문제를 해결해야합니다. 그러나 아이디어를 실제 코드로 실제로 변환하려면 애플리케이션 버전을 반복해야합니다.

내 경험 법칙 : 문제의 일부를 완전히 이해하지 못하면 물러서서 완전히 생각해야합니다 (API 등을 이해하기위한 프로토 타입 및 버리기 코드를 포함하여 "생각"). . 기본적으로 이전에 해결 한 문제 모음 이고이 특정 인스턴스에서 모든 것을 함께 맞추는 가장 좋은 방법을 찾아야하는 경우 반복하십시오.

솔직히, 그것은 어렵고 빠른 규칙이 아닙니다. 주어진 프로젝트에 대해 두 가지를 혼합해야한다고 생각합니다. 각각의 작업량은 아마도 과거에 이미 완료 한 프로젝트와 얼마나 가까운 지에 달려있을 것입니다.