신속한 프로토 타이핑 및 리팩토링

때로는 작은 프로젝트 (Android 앱과 같은)를 시작할 때 어떤 접근법이 결국에는 효과가 있는지 알지 못하며 한 가지 접근법으로 가서 시도해보십시오. 그러나 이전에이 방법을 사용한 적이 없다면 (이전에 프로그래밍 한 적이없는 응용 프로그램의 경우) 알 수없는 지형으로 들어가는 것과 같습니다. 사용할 라이브러리를 모릅니다 (어쩌면 여러 라이브러리를 시도해야 할 수도 있음). 그리고 많은 unkonwns가 있습니다 (예 : 안드로이드에서 원시 오디오 데이터를 얻는 방법)

그래서 내 개발 과정은 다음과 같습니다.

• 접근 방식에 기회가 있는지 코드 조각을 작성하십시오. (접근법이 불확실할수록 코드가 더 나빠집니다)
• 작동하면 아름답게 될 때까지 많이 리팩토링하십시오.

이 시점에서 소프트웨어 디자인을 세부적으로 계획하면 시간 낭비 일 수 있습니다.지도없이 여행을 계획하는 것과 같습니다.

이것이 애자일 개발의 일부입니까? 소프트웨어 개발에서 알 수없는 지형을 어떻게 처리합니까?

애자일과는 아무런 관련이 없지만 사람들은 민첩하다고 생각하기 때문에 일종의 가정을합니다. 히피 코뮌에서 머리없는 닭 발달.

현재 귀하가하고있는 일은 현재 기술에 대한 판단 경험이 충분하지 않기 때문에 기술을 평가하는 것입니다. 새로운 라이브러리, 프레임 워크, 언어 및 플랫폼이 거의 매일 나타나기 때문에 이것은 좋으며 결코 끝나지 않습니다.

당신이 미지의 문제를 다루는 방법은 실제로 정말 좋은 질문이며 대안을 연구하고, 대안을 평가 한 다음 선택하는 것입니다.

여기에 도움이되는 애자일과 관련된 경향이있는 기술은 리팩토링하기 쉽고 안전한 코드를 만드는 것을 포함합니다. TDD가 좋은 예입니다. 결과 측면에서 개발을 고려하도록 권장합니다. "이 코드는이 결과를 가져와야합니다."는 마음을 집중시키고 목표 해결에 기여하지 않는 코드의 양을 줄입니다.

SOLID (약어) 원칙에 따라 코드를 작성하는 경우 나중에 잘못된 선택을 한 경우 라이브러리를 대체 할 수있는 좋은 위치에있게됩니다.

이런 종류의 질문을하는 것이 좋습니다. 여러 가지 이유로 올바른 기술을 선택하기 위해 시간을내어 "무지한"것처럼 보일 위험이없는 개발자가 너무 많습니다. 늦지 않은 프로젝트 초기에 실수를 저 지르십시오. 실험은 낭비가 아니므로 올바른 방법으로 진행하고 있다고 생각합니다.

이것이 애자일 개발의 일부입니까? 소프트웨어 개발에서 알 수없는 지형을 어떻게 처리합니까?

당신이 묘사 한 것은 민첩하지 않습니다. 애자일 개발은 시간이 박스 반복적 인 접근 방식을 적응 계획, 진화 적 개발 및 제공을 홍보에 대한 자세한. 애자일은 변화에 대한 신속하고 유연한 대응을 장려합니다. 따라서 개발이 진행됨에 따라 코드를 리팩토링하면 민첩한 방법론이 적용됩니다.

알려지지 않은 프로젝트를 다루는 것은 높은 수준의 디자인으로 알려진 요구 사항을 수집하는 것으로 시작됩니다. 대부분의 구성 요소가 준비되면 올바른 솔루션을 검색 할 수 있습니다. 그러나 본격적인 개발 이전에 작은 개념 증명을 구축하는 것이 우리 팀이 따르는 접근법입니다.

SOLID 라는 소프트웨어 개발 원칙이 있습니다 . 내 경험상 문제 / 문제에 적용하는 것은 항상 프로젝트의 코드 기반을 개선하기위한 한 걸음입니다.

프로젝트에 따라 소규모 프로젝트를 단독으로 수행하는 경우 개발의 일환으로 기술 연구 및 조사를 수행하는 것이 좋습니다. 그리고 애자일의 일부는 아니지만, 애자일 방법론을 사용하여 이에 대한 제어를 추가 할 수 있습니다. 그러나 이로 인해 프로세스를 예측하거나 시간 상자를 매우 어렵게 만듭니다. 전적으로 작은 프로젝트에서 혼자 작업하는 경우 요구 사항을 학습하면서 전개 할 수 있습니다. 길을 따라 좋은 원칙을 사용하고 일관성을 유지하면 리팩토링을 많이하지 않아도됩니다.

직장에서는 Kanban, Scrum 및 더 전통적인 폭포 방식을 사용합니다. 프로젝트에 따라 사전 정의 된 사전 요구 사항이있는 복잡한 개발이 애자일에 가장 적합하지 않은 것으로 나타났습니다.

민첩한 프로젝트 (가장 단순하지는 않지만)에서 작업을 시작하기 전에 몇 가지 문서를 작성합니다. 우리는 모의 (ui 집중된 경우), 일련의 요구 사항 및 기능 사양을 가지고 있습니다.

기능 사양에서 기술 사양을 작성하도록 개발이 요청되며이 프로세스 중에 기술을 지정하고 필요한 선행 연구를 수행합니다. 이 프로세스는 요구 사항 / 기능 사양의 차이를 볼 수있는 기회를 제공하고 경험과 시스템 지식을 가진 사람들에게 큰 결정을 내려 결정을 내릴 수 있기 때문에 나에게 매우 중요합니다.

중요한 점은 기능 사양이 글 머리 기호 목록이 될 수 있으며 기술 사양은 일반적으로 일부 글 머리 기호 및 기술 조정 기능이있는 모델이며 경우에 따라 3 ~ 4 페이지 일 수 있다는 것입니다.

애자일 프로젝트를 실행할 때도 문서를 만듭니다.

• 모든 문서에는 비용이 있습니다.
• 이동 및 부정확 한 높은 수준의 요구 사항에 대한 개발에는 비용이 있습니다.
• 위의 정확한 균형은 프로젝트, 문화 및 사람들에 따라 다릅니다.
• 문서화 적시에 문서가 오래되었습니다.
• 우리는 간신히 충분히 / 충분히 문서화합니다.
• 우리는 이러한 문서를 유지 관리하거나 업데이트하지 않으며 많은 노력을 기울이지 않습니다. 그들은 작다. 우리는 그것들을 버릴 것으로 기대합니다.
• 우리는 기술 결정, 흐릿한 요구 사항 및 아키텍처와 같은 큰 미지의 문제를 해결합니다.
• 시작하기 전에 무엇을 개발하고 있는지 알고 있습니다.
• 우리는 개발자들이 문서에 대한 정보에 입각 한 결정을 내리고 문제를 논의 할 것을 신뢰합니다.
• 우리는 관련된 모든 사람들이 자주 의사 소통하기를 기대하므로 문서보다는 의사 소통을 중요하게 생각합니다.
• 우리는 개발 후가 아닌 이전에 시스템 (개요)을 문서화합니다.

민첩한 프로세스에 작은 폭포가 있습니다.

혼자서 작업하는 경우 선행 모델 (다이어그램!)을 작성하고 기술을 가지고 놀면서 기술을 선택한 다음, 높은 수준의 요구 사항에 대한 개념이 있으면 앞서 가서 민첩한 반복 방식으로 개발하지만 좋은 원칙과 갈수록 일관성을 유지하면서 갈수록 리팩터링을 줄이고 리팩터링해야합니다.

그러나 일반적으로 실제 비용이 드는 경우 (취미가 아님) 코드를 작성하기 전에 개발중인 내용을 알고 있지만 마음이 바뀌면 빠르게 중복되는 문서를 작성하는 데 너무 많은 시간을 낭비하지 마십시오. 더 나은 정보를 얻으면서 개발하는 동안 마음을 바꾸십시오. 그리고 프로젝트는 진로를 크게 바꿀 수 있지만 잘 정의 된 기초부터 시작하십시오.

이것은 대략 새로운 프로젝트를 시작하는 방법이며 작은 프로젝트에 대해 이야기하고 있다고 가정하면 잘 작동합니다. 예를 들어 ORM이나 그와 비슷한 규모의 글을 쓰고 있다면이 길을 가지 않을 것입니다. 때때로 나는 정말로 머리 위로있을 때 더 공식적인 연구에 의지 할 것이다. 그러나 대부분 코드 작성을 시작하고 어떤 일이 일어나는지 확인합니다. 그러나이 작업을 수행 할 때 많은 코드를 버릴 준비가되어 있어야합니다.