2008-12-15 4 views
15

내가 일하는 방식에 민첩한 생각을 점차 흡수 해 감에 따라 yagni ("필요하지는 않을 것")가 점점 더 중요 해지고 있습니다. 잘못된 우선 순위를 걸러 내고 이 아닌 다음을 결정하는 가장 효과적인 규칙 중 하나 인 것 같습니다..YAGNI - 지명되어서는 안되는 민첩한 연습?

그러나 yagni는 여기에서 거의 속삭이지 않은 개념 인 것으로 보입니다. 나는 의무 검색을 실행했고, 한 가지 질문 제목에 - 그리고 나서 보조 역할에 대해서만 나타납니다.

왜 이런가요? 그 중요성을 과대 평가합니까?

면책. 응답을 선취하기 위해 내가 이의를 제기 할 것이라고 확신하겠습니다. yagni가의 반대쪽임을 강조하겠습니다. 귀하가해야 할 부분을 올바르게 얻는 데 소중한 시간과 노력을 집중할 것을 권장합니다.

다음은 자주 묻는 질문 중 일부입니다.

내 단위 테스트는 사용자 요구 사항 또는 프레임 워크 구조를 기반으로 선택합니까?

프레임 워크에서 벗어나기 때문에 거기에있는 단위 테스트 만 설치하고 테스트하고 유지 관리합니까?

내 프레임 워크에서 생성 한 코드 중 어느 정도는 보지 않았지만 (그래도 yagni라고해도 언젠가는 나를 물 수 있습니다)?

사용자의 문제가 아니라 도구에 얼마나 많은 시간을 할애하고 있습니까?

쌍 프로그래밍의 경우 관찰자의 역할 값은 종종 "yagni"에 있습니다.

CRUD 도구를 사용합니까? 당신이 _RU_ 도구 또는 C__D 도구로 사용할 수 있습니까? 아니면 하나 또는 두 개만 필요할 때 네 조각의 코드 (네 개의 단위 테스트)를 생성하고 있습니까?

+1

이것은 정말로 당신의 잘못이 아니지만, 나는 지금 내 머리에서 얀니와 그의 빌어 먹을 콧수염을 꺼낼 수 없습니다. – MusiGenesis

+0

당신은이 게시물을 불러야했습니다. 이름을 밝히지 않을 것입니다. – sam

답변

12

TDD는 YAGNI를 일부 포함합니다. TDD를 올바르게 수행하면 필요한 기능을 수행하는 테스트 만 작성한 다음 테스트를 통과하는 가장 간단한 코드를 개발 한 다음 기본적으로 YAGNI 원칙을 따르고 있습니다. 내 경험상, TDD 상자 밖에 있고 테스트 전에 코드를 작성하거나, 필자가 실제로 필요하지 않은 것들을 테스트하거나, YAGNI를 위반하는 테스트를 통과하는 가장 간단한 방법 이상의 코드를 작성하는 것만 가능합니다 .

내 경험에 비추어 볼 때 후자는 TDD를 할 때 가장 흔한 가짜입니다. 나는 뛰어서 다음 테스트를 통과하는 코드를 작성하는 경향이 있습니다. 그로 인해 테스트해야 할 항목의 요구 사항보다는 내 코드를 기반으로 선입견을 얻음으로써 나머지 테스트가 손상 될 수 있습니다.

YMMV.

+0

블로그 게시물에이 게시물에 대해 언급했음을 지적하겠습니다. http://jasonmbaker.wordpress.com/2009/ 01/11/테스트 주도의 개발 원동력/ –

0

나는 yagni의 형식이거나 적어도 ydniy (아직 필요하지 않음) 인 조숙 한 최적화를 참조하는 게시물을 많이 보았습니다.

+0

처음에는 불필요한 것을 조숙하게 최적화 할 때 무엇이라고 부르는 지 궁금합니다. :) – dkretz

+1

le dorfier : 서사시 낭비? (ewot) : D – jalf

4

Yagni와 KISS (간단하고 어리 석다)는 본질적으로 같은 원리입니다. 불행히도, 나는 키스가 "야기 (yagni)"처럼 자주 언급되는 것을 본다.

광야에서 프로젝트 지연과 실패의 가장 일반적인 원인은 불필요한 구성 요소의 실행 불량이므로 기본 정서에 동의합니다.

+0

나 또한 프로젝트 지연에 대한 기본 감정에 동의하지만 YAGNI와 KISS는 동일하다는 데 동의하지 않는다. 필자는 필요하지 않은 많은 간단한 코드와 필요한 복잡한 코드를 보았습니다. –

+1

KISS는 실제로 KIASAN이어야합니다 (필요한만큼 간단하게 유지). 불필요한 간단한 구성 요소는 필요한 것보다 더 복잡합니다. 아무것도 (NISTN?)보다 단순하지 않습니다. – MusiGenesis

-1

저는 YAGNI가 빠르고 더러운 것의 반대라고 생각하지 않습니다. 그것은 단지 필요한 일을하고 있으며, 누군가가 쓰는 소프트웨어가 지난 50 년간 지속되도록 계획하고 있지도 않습니다. 적어도 내 마음에는 질문 할 질문이별로 없기 때문에 드물게 올 수 있습니다. "자신을 반복하지 말 것"및 "간단하고 바보 같은"규칙과 비슷하지만 101 가지 방법으로 반드시 분석하고 분석 할 필요는 없습니다. 어떤 것들은 아주 간단해서 보통 작은 연습을 한 후에 곧 가져옵니다. 어떤 것들은 무대 뒤에서 개발되고, 돌아 서서 보게되면 그 것들이 진술하는 또 다른 방법이 될 수 있습니다.

+0

요점을 놓치고 있습니다. YAGNI, 물처럼 (예 h2o) 너무 나쁠 수 있습니다. 이것에 대한 카운터는 BDUF라고 불리우거나 유추를 원한다면 Ivory Tower를 참조하십시오. 리더 (또는 누군가)가 아이보리 타워에 서 있거나 약점이나 알려지지 않은 점을 발견하여 BDUF에 참여하는 경우 문제가 발생합니다. 이것은 본질적으로 애자일 인 YAGNI의 관행을 질책하는 면허를 부여하지 않습니다. – gogogadgetinternet

1

내가 아는 문제는 사람들이 YAGNI에서 DI 컨테이너를 사용하여 공장을 작성하는 경향이 있다는 것입니다 (이미 코드베이스에 있지 않은 경우). 나는 JB King에게 동의한다. YAGNI와 함께 일한 많은 사람들에게 모서리를 자르거나 코드를 잘못 작성하는 면허가있는 것 같습니다.

예를 들어, 여러 모델/제조업체의 PINPad를 추상화하기위한 PinPad API를 작성했습니다. 전반적인 구조가 없으면 단원 테스트도 작성할 수 없습니다. 나는 TDD의 노련한 분장자가 아닐지도 모른다. 내가 한 일이 YAGNI인지 아닌지에 대한 의견이 다를 거라 확신합니다.

+1

공장 스팸으로 인해 나를 변덕스럽게 만듭니다. 종종 필요한 것은 공장으로 봉사하는 고차 함수입니다. 그리고 심지어 더 * 더 자주, 공장이 전혀 필요하지 않지만 그것은 이해하기 쉬운 황금 망치입니다. – dss539

+0

아래의 JB King에 대한 제 응답을보십시오. 니가 YAGNI를 이해하고 있다고 생각하지 않는다. – gogogadgetinternet

3

자유롭게 변경할 수있는 드라이브 YAGNI. 폭포 프로젝트에서 만트라는 통제 범위입니다. 범위는 고객과 계약을 맺음으로써 제어됩니다. 따라서 고객은 계약서에 서명 한 후 범위 변경이 어려울 것이라는 것을 알고 범위 문서에서 생각할 수있는 모든 것을 채워 넣습니다. 결과적으로 가치가있는 기능 세트가 아닌 기능의 세탁 목록이있는 응용 프로그램으로 끝납니다.

애자일 프로젝트에서는 제품 소유자가 우선 순위가 지정된 제품 백 로그를 작성합니다. 개발 팀은 우선 순위, 즉 가치에 따라 기능을 구축합니다. 결과적으로 가장 중요한 것들이 먼저 만들어집니다. 결국 사용자가 가치가있는 기능을 가진 응용 프로그램으로 끝납니다. 중요하지 않은 내용은 목록에서 제외되거나 완료되지 않습니다. 그건 YAGNI입니다.

YAGNI는 연습이 아니지만 우선 순위가 지정된 백 로그 목록의 결과입니다. 비즈니스 파트너는 반복에서 반복되는 제품 백 로그를 변경하고 우선 순위를 다시 지정할 수 있으므로 비즈니스에 부여되는 유연성을 중요시합니다. YAGNI는 우리가 변화를 쉽게 받아 들일 때, 심지어 늦게까지도 받아 들일 때 얻을 수있는 이익이라고 설명하는 것으로 충분합니다.