YAGNI와 함께 어디까지 가시나요?[닫은]

https://stackoverflow.com/questions/2023638

19-09-2019
|

문제

저는 엔터프라이즈 시장을 위한 새롭고 혁신적인 웹 애플리케이션을 개발 중입니다.물론, 나보다 먼저 많은 사람들이 자신의 웹 앱이 혁명적일 것이라고 생각했지만 나중에 알고 보니 그렇지 않았습니다.(아니면 그렇긴 한데 어차피 장사가 안 좋거든요).

그래서 나는 내 아이디어가 가장 낮은 비용으로 어떤 견인력을 가지고 있는지 알아보기 위해 극단적인 YAGNI를 따르려고 생각하고 있습니다.

보안 기능이 없습니다(예: 사용자 없음 등).신규 고객을 위해 새 데이터베이스 인스턴스와 새 웹앱 인스턴스를 설치합니다.각 웹앱 인스턴스는 http 서버 비밀번호(https를 통한 다이제스트 또는 기본 인증)로 보호됩니다.
국제화 없음.소스 코드에 영어 문자열이 포함되어 있습니다.
디커플링 없음.데이터베이스와 통신하는 웹페이지일 뿐입니다.
성능 트릭이 없습니다.대기열, 캐시, 타이머, 백그라운드 작업, 비동기 호출 등이 없습니다.
확장성이 없습니다.데이터베이스 파티셔닝, 샤드, 클러스터링 또는 복제가 없습니다.
또한 필요할 때마다 미시적 수준에서 YAGNI를 사용하세요.

저는 프로젝트를 시작하고 간단하고 매력적인 UI로 혁신적인 기능을 판매할 수 있는(또는 판매를 시도할) 지점에 최대한 빨리 도달하고 싶습니다.

계획이 실패하면 일찍 알게 될 것입니다.성공하면 고객이 무엇을 원하는지 볼 것입니다.그들은 프랑스어 버전을 원하나요?아니면 조직 내의 사용자와 역할을 원합니까?

이것이 사람들이 YAGNI를 통해 의미하는 것입니까, 아니면 이것이 YAGNI의 병리적이고 과장된 예입니까?

해결책

나는 Yagni 원칙에 전적으로 동의하지만 여전히 성공을 계획하고 싶습니다. 응용 프로그램에 갑자기 10 명 이상의 사용자가있을 때 완전한 재 작성이 필요한 경우 Yagni는 너무 멀리 가져갑니다.

필요한 것들이 필요합니다. 내 관점에서, 가장 중요한 두 가지 요점 :

국제화를 위해 앱을 준비하지 않음으로써 발에 자신을 쏘지 마십시오. 신청서가 좋은 경우 국제화는 언젠가 테이블에 올 것입니다. 또한 UTF-8을 사용하여 외국 문자를 처리 할 수있는 능력은 2010 년에 처음부터 신청서를 구축 할 때 절대적인 요구 사항입니다. 국제화는 영어 원어민에게는 중요하지는 않지만 나를 믿습니다. 나중에 응용 프로그램은 끔찍합니다.
보안이없는 기능에 대해 두 번 생각하십시오. 다른 보안 수준의 사용자와 함께 앱과 협력하려는 조직이나 그룹은 어떻습니까? 그것 ~할 수 있었다 이것이 당신이 실제로 할 수있는 기능입니다. 저는 아직 잠재력에 익숙하지 않은 많은 제품에 세밀한 보안 시스템이 내장되어 있습니다. 그러나 특정 응용 프로그램이 성공 했더라도 특정 응용 프로그램이 수행 할 수 있는지에 대해 잘 생각하십시오.

다른 팁

이것이 그들이 "프로토 타이핑"이라고 부르는 것입니다. 가십시오.

yagni와 프로토 타이핑 사이에는 미묘함이 있습니다.

사용자가 수반 된 특징 일 때, 당신은 아니오라고 말하면, 그것은 yagni입니다.
구현 (i18n, "디 커플 링"(?), 대기열, 캐시, 타이머 등) 일 때, 당신은 자신에게 거절합니다. 그것은 실제로 Yagni가 아닙니다. 그것은 프로토 타이핑입니다.

여기에있는 대부분은 사용자 지향 금도금 인 것 같습니다. 나는 이것을 정확하게 부르지 않을 것입니다.

YAGNI는 당신이 생각하는 것의 차이점을 볼 수 있도록 상기시켜줍니다. ~할 수 있다 귀하의 요구 사항을 충족시키기 위해 수행해야 할 작업과 수행해야 할 작업.

예를 들어, "사람들이 계정을 만들고 로그인하도록 허용"이라는 요구 사항이 있는 경우 프레임워크의 기본 인증 방법을 사용하고 다음 요구 사항으로 넘어갑니다.

귀하의 웹 앱 ~할 수 있다 OpenID, Active Directory, 로컬 데이터베이스, 플랫 파일 및 수많은 종류의 인증 방법을 지원하지만 가장 간단한 방법을 구현하여 요구 사항을 충족할 수 있습니다.(나에게, 야그니 암시한다 DTSTTCPW).

"시간만 충분하면 뭐든지 할 수 있어요"

- 내가 만난 모든 프로그래머

나 자신의 원칙의 팬이 아닙니다. 나는 그것이 잘못 디자인되지 않은 소프트웨어의 정당화에 너무 자주 사용되는 것을 본다. 과도하게 설계된 소프트웨어도 물론 문제이지만 "Yagni"는 실제로 실제 영향 분석의 여지를 남기지 않습니다.

소프트웨어의 세계에서는 필요하지 않을 것이라고 생각하는 많은 것들이 실제로 필요할 것입니다. 다음 몇 가지. 누가 달린다.

나는 2 년이 지난 후에도 여전히 생산중인 앱이나 홀드 오버로 여겨지는 한두 앱을 작성했습니다. 그들은 유지해야 할 고통입니다.

특히 보안과 같은 것에 관해서는 ~이다 필요합니다.

Yagni는 좋은 원칙이지만 유일한 디자인 원칙은 아닙니다. 위의 많은 부분은 사용자 앞에서 제품을 빠르게 얻는 것이 합리적입니다. 그러나 예를 들어, 데이터베이스와 직접 대화하는 웹 페이지에 각각이 복제 된 코드를 갖기 시작하면 다른 원칙 (이 경우 건조)에 대한 하나의 원칙 (yagni)에 대한 노예 의존성을 알게 될 것입니다. 희망적으로 점점 더 많은 사용자의 기능 요청에 응답합니다.

진정으로 개발하려는 경우 a 엔터프라이즈 시장을위한 혁신적인 웹 응용 프로그램 나는 그 중 어떤 것들을 확실하지 않습니다 와이ou ㅏint Gonna NEED.

또한 예제는 매우 구체적입니다. 예를 들어 "보안 기능 없음"이라고 말할 때 ... 사용자는 사용자가 할 수있는 한 가지 일이지만 입력을 소독하는 것은 할 수없는 일입니다. 또한 "확장 성"은 데이터베이스 샤드 또는 복제의 문제가 아니며 응용 프로그램이 잘 확정되지 않았다는 것을 알게 된 후 결정입니다.

사용하면 차라리 조심하고 싶습니다 야그니 높은 수준의 디자인 가이드 라인으로서, 이상한 제품 기능이나 소프트웨어 구성 요소에 대해 이야기 할 때 가장 적합합니다.

단지 내 0.2

"Yagni"를 그 극단으로 가져 가면 (그리고 그것이 좋은 아이디어인지 아닌지에 대한 토론과 그것이 실제로 "yagni"인지 아닌지에 대한 토론에 대한 토론을 회피 할 것입니다), 당신은 코드베이스를 무자비하게 리팩토링 할 준비를해야합니다 나중에 진흙 공을 만들지 않고 지금 떠나는 것.

내 생각에 Yagni는 "Oh Feature X를 추가하면 똑똑 할 것입니다. 앞으로도 필요할 수 있습니다." 절대 항상 요구 사항이 아닌 기능을 추가하십시오.

즉, 고객이 기능 Y가 절대적으로 필요하다고 생각하면 코드가 항상 수정을 위해 열려 있어야합니다. 좋은 아키텍처는 필수입니다!

확장 성, 대기열, 캐싱과 관련하여 : 그것은 달라집니다. 응용 프로그램의 요구 사항은 무엇입니까? 10 명의 동시 사용자가 사용하는 인트라넷 사이트입니까, 아니면 수백만 명의 사용자가있는 인기있는 웹 사이트입니까? 때에 따라 다르지. 요구 사항을 찾아서 더 이상 아무것도하지 않습니다. 야그니. 요구 사항이 변경되는 경우; 응용 프로그램 변경 - 수정을 위해 열려 있어야합니다.

yagni는 좋은 기회가 있다면 좋습니다. 절대 필요해. 지금은 필요하지 않지만 가까운 미래에 필요할 것이라고 확신한다면, 나중에보다 앞쪽에 맞는 것이 거의 항상 더 쉽습니다. 필요하지 않은 물건을 구현하지 않는 것을 정당화 할 때 이 두 번째 그러나 가까운 미래에 Yagni는 거의 확실히 필요할 것입니다. 그것은 문제가 시작되는 곳입니다.

Yagni가 많은 사람들 사이에서 하나의 위대한 원칙이라는 점은 기억하기에 좋은 것입니다. 때때로 Yagni는 하나의 결정을 제안하지만 다른 결정을 선호하는 이유는 똑같이 좋은 이유가 있습니다.

여기에 일부 Yagni 지지자들이 멀리 갈 수 있다고 생각하는 영역이 있습니다. ood/다형성에 익숙하다면 보통 프로토 타입에서도 향후 사용을위한 훌륭한 확장 포인트를 "굽는 데 거의"비용이 거의 들지 않습니다.

여기 예입니다 ...

인쇄 친화적 인 보고서를 표시 할 수있는 기능이 포함 된 프로토 타입 웹 앱을 만들고 있습니다. 당신은 빨리 일해야하지만 스테이크 홀더가 보고서를 이메일로 보내는 능력을 요구할 것이라고 생각합니다.

서버 측 Java 코드에서 보고서가 인터페이스 뒤에있는 프린터를 위해 준비되어 있다는 사실에 대한 지식을 숨 깁니다. 해당 책임을 유지하기 위해 인터페이스를 확장하는 구체적인 클래스를 만듭니다. 실제로 꺼지지 마십시오 쓰다 yagni이기 때문에 인터페이스의 이메일 버전입니다. 그러나 만약 당신이 그렇게한다면, 당신은 당신의 기존 기능에 대학살없이 그것을 추가하도록 설정되었습니다.

나는 당신이 모든 상식을 버리고 가능한 가장 신호적인 방식으로 전체 프로젝트를 수행하여 시작하는 경우, 당신이 끝날 것이 큰 실패의 더미입니다 ... 이것은 결코 혁명적이 아닙니다 (혁명적). TM).

그것이 유용한지를 진정으로 알고 싶다면 스크린 모의 업을하십시오. 어쩌면 규칙적인 오래된 하드 코드 HTML조차도. 잠재 고객에게 가져 가서 발을 문에 넣을 수 있는지 확인하십시오. 그들 중 일부는 물기 시작하면 엉덩이를 터 뜨리고 쌓으십시오.

계약을 체결하고 지불을 받고 고객 직원의 누군가가 실제로 사용을 시작하는 데 시간이 걸릴 것입니다. 그것이 진행되는 동안, 그것을 구축하십시오.

아마도 일어날 일 가능성은 아마도 잠재 고객이 귀하의 앱을보고, 왜 그것이 효과가 없는지 알려줄 것이라는 것입니다. 모의 업을 바꾸고 돌아갑니다. 누군가가 지불 할 제품에 대한 프론트 엔드 디자인이있을 때까지 필요에 따라 반복하십시오.

내가 할 일은 다음과 같습니다.

1) 올바른 건축 결정을 고려하여 설계하십시오. 이 경우 국제화와 보안은 아마도 가능할 것입니다.

2) 개발할 때는 나중에 해당 원칙을 구현할 수있는 후크를 만듭니다. 따라서 시간과 예산이 있으면 주요 리모델링을하지 않고도 구현할 수 있습니다.

3) 그러면 응용 프로그램을 비행하고 잠재적 인 고객에게 더 중요한 기능에 집중할 수 있습니다.

그래서 나는이 경우 당신이 제안한대로 "Extreme Yagni"보다 더 많은 키스 접근법을 사용할 것이라고 생각합니다.

제 생각에는 Yagni는 생산성 향상.

몇 가지 예외가 있습니다. 예를 들어, 제 3 자 도서관을 개발하는 경우 적어도 조금 미리 생각하고 향후 사용자의 요구를 예상해야합니다. 즉, Yagni를 완전히 포기해야한다고 말하는 것은 아니지만 사내 개발과 마찬가지로 엄격하게 따라야합니다.

네,하지만...

나는 당신의 많은 고려 사항에 동의하는 경향이 있습니다 제외하고 Yagni의 "IT"는 사고 단계가 아니라 기능성을 나타 내기 때문에 "디 커플 링". 몇 가지 추상화 (분리에 필요한 것만)를 도입하면 오류가 발생하지 않거나 오류가 더 빨리 발견되고 제거 된 측면에서 즉시 지불됩니다.

좋은 (당신이 생각하는 것을 절약하기 때문에) 그러한 추상화를 소개하는 방법은 다음과 같습니다. 좋은 웹 프레임 워크를 사용하고 제안 된 응용 프로그램 구조 스타일을 간단히 따릅니다..

프린지 혜택으로 보안, 국제화, 성과 및 스케일링을 추가하는 것이 훨씬 쉬워지면 Yagni-Behavior Now는 합리적으로 안전 해져야합니다.

(불행히도, 논쟁은 이미 웹 프레임 워크를 알고있는 경우에만 적용됩니다. 지식은 Yagni Kingdom에서 최고를 지배합니다.)

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow