더 나은 생산성을 얻기 위해 바보입니까?

저는 "좋은 디자인", "디자인 패턴"등에 관한 다른 책을 읽는 데 많은 시간을 보냈습니다. 저는 SOLID 접근 방식 의 큰 팬이며 간단한 코드를 작성해야 할 때마다 미래. 따라서 새로운 기능이나 버그 수정을 구현하려면 다음과 같이 세 줄의 코드 만 추가하면됩니다.

if(xxx) {
    doSomething();
}

내가 이런 식으로하겠다는 의미는 아닙니다. 가장 가까운 미래에이 코드 조각이 커질 것 같으면 추상화를 추가하고이 기능을 다른 곳으로 옮기는 등의 방법을 생각할 것입니다. 내가 추구하는 목표는 평균 복잡도를 변경하기 전과 동일 하게 유지하는 것입니다 .

나는 코드 관점에서 볼 때 아주 좋은 생각이라고 생각합니다. 내 코드는 충분히 길지 않으며 클래스, 메소드 및 클래스와 객체 간의 관계와 같은 다른 엔티티의 의미를 이해하는 것은 쉽습니다.

문제는 너무 많은 시간이 걸리고 종종 "있는 그대로"그 기능을 구현하면 더 나아질 것입니다. "세 줄의 코드"대 "새로운 인터페이스 + 해당 인터페이스를 구현하는 두 개의 클래스"에 불과합니다.

제품 관점에서 ( 결과 에 대해 이야기 할 때 ), 내가하는 일은 매우 의미가 없습니다. 다음 버전에서 작업 할 경우 좋은 코드를 갖는 것이 정말 좋습니다. 그러나 다른 한편으로, 코드를 "좋은"것으로 만드는 데 소비 한 시간은 몇 가지 유용한 기능을 구현하는 데 소비되었을 수 있습니다.

나는 종종 내 결과에 매우 만족하지 않는다고 생각합니다. A 만 할 수있는 좋은 코드는 A, B, C 및 D를 할 수있는 나쁜 코드보다 나쁩니다.

이 접근법이 소프트웨어 프로젝트에 긍정적 인 순이익을 가져다 줄까, 아니면 시간 낭비인가?

A 만 할 수있는 좋은 코드는 A, B, C, D를 할 수있는 나쁜 코드보다 나쁩니다.

이것은 투기 일반 성과 같은 냄새가 난다 . 고객에게 B, C 및 D 기능 이 필요 하다는 것을 알지 못하거나 최소한 합리적으로 확신하지 않으면 불필요하게 디자인을 지나치게 복잡하게 만들 수 있습니다. 더 복잡한 코드는 장기적으로 이해하고 유지하기가 더 어렵습니다. 추가적인 복잡성은 유용한 추가 기능에 의해서만 정당화됩니다 . 그러나 우리는 일반적으로 미래 예측에 매우 나쁩니다. 우리가 생각하는 대부분의 기능이 있습니다 미래에 필요한 이제까지 실제 생활에서 요구되지 않습니다.

그래서:

A 만 할 수있는 좋은 코드 (단순하고 깔끔하게 수행하는 것)는 A, B, C, D를 수행 할 수있는 나쁜 코드보다 더 좋습니다 (일부 는 나중에 언젠가 필요할 수 있습니다).

일화 시간 :

이 방법으로 과도하게 엔지니어링하는 두 명의 개발자가 저를 위해 일했습니다.

그들 중 하나의 경우, 이것은 특히 새 프로젝트를 시작할 때 기본적으로 그의 생산성을 정지시킵니다. 특히 프로젝트가 본질적으로 상당히 간단한 경우에 특히 그렇습니다. 궁극적으로 지금 작동하는 소프트웨어가 필요합니다. 이것은 너무 나빠서 그를 보내야했습니다.

과도하게 엔지니어링되기 쉬운 다른 개발자는 생산성이 매우 뛰어납니다. 따라서 모든 관련없는 코드에도 불구하고 그는 여전히 대부분의 것보다 빠르게 전달했습니다. 그러나 이제 그가 이사를 했으므로 추상화 계층 등을 수정해야 할 때 기능을 추가하는 데 필요한 추가 작업에 종종 자극을 느낍니다.

도덕은 과도 공학이 유용한 일을하는 데 더 잘 쓸 수있는 여분의 시간을 소비한다는 것입니다. 또한 자신의 시간뿐만 아니라 코드를 다루어야하는 사람들도 있습니다.

그러지 마

코드는 가능한 한 단순하고 단순하지 않아야합니다. '어쩌면'을 다루는 것이 더 간단 해지지는 않습니다. 잘못 생각하면 코드를 표시하기 위해 실제 이득없이 코드를 더 복잡하게 만들 것입니다.

SOLID와 KISS / YAGNI의 원리는 거의 정반대입니다. doSomething ()을 호출하는 클래스가 수행하는 작업의 필수 부분으로 정당화 할 수 없다면 느슨하게 결합되고 주입 된 다른 클래스에 있어야한다는 것을 알 수 있습니다. 다른 하나는 이것이 doSomething이 사용되는 곳이라면 방법으로 추출하는 것조차 지나친 것일 수 있다고 말합니다.

이것이 좋은 프로그래머가 자신의 몸무게를 금으로하는 이유입니다. "적절한"구조는 사례별로 현재 코드베이스, 프로그램의 미래 경로 및 프로그램 배후 비즈니스 요구 사항에 대한 지식이 필요합니다.

이 간단한 3 단계 방법론을 따르고 싶습니다.

• 첫 번째 패스에서 작동 시키십시오.
• 두 번째 패스에서는 깨끗하게 만드십시오.
• 세 번째 단계에서는 SOLID로 만듭니다.

기본적으로 KISS와 SOLID를 혼합하는 방법입니다. 처음으로 코드 줄을 작성할 때는 모든 것이 일회성 일 것입니다. 그것은 단순히 작동하고 아무도 신경 쓰지 않으므로 화려하지 마십시오. 두 번째로 커서를 해당 코드 줄에 넣으면 원래 가설이 반증되었습니다. 이 코드를 다시 방문하면 코드를 확장하거나 다른 곳에서 연결할 수 있습니다. 이제 조금 정리해야합니다. 일반적으로 사용되는 tidbits에 대한 메소드를 추출하고, 복사 / 붙여 넣기 코딩을 줄이거 나 제거하고, 주석을 추가하는 등의 작업을 수행하십시오.이 코드로 세 번째로 돌아 오면 이제는 프로그램 실행 경로의 주요 교차점입니다. 이제이를 프로그램의 핵심 부분으로 취급하고 가능한 경우 SOLID 규칙을 적용해야합니다.

예 : 콘솔에 간단한 텍스트 줄을 작성해야합니다. 처음 이런 일이 발생하면 Console.WriteLine ()이 좋습니다. 그런 다음 새로운 요구 사항에 따라 동일한 줄을 출력 로그에 쓰도록 지시하면이 코드로 돌아옵니다. 이 간단한 예에서는 반복적 인 "복사 / 붙여 넣기"코드가 많지 않을 수도 있지만 기본적인 정리를 수행하거나 IO 작업을 더 깊은 비즈니스 로직으로 인라인하지 않도록 방법을 추출 할 수 있습니다. . 그런 다음 클라이언트가 모니터링 서버의 명명 된 파이프에 동일한 텍스트 출력을 원할 때 되돌아옵니다. 이 출력 루틴은 큰 문제입니다. 같은 텍스트를 세 가지 방법으로 방송하고 있습니다. 컴포지트 패턴을 사용하는 알고리즘의 교과서 예입니다. Write () 메소드로 간단한 IWriter 인터페이스를 개발하십시오. 해당 인터페이스를 구현하여 ConsoleWriter, FileWriter 및 NamedPipeWriter 클래스를 작성하고 한 번 더 "MultiWriter"복합 클래스를 작성한 후 클래스에 대한 IWriter 종속성을 노출하고 세 명의 실제 작성자로 MultiWriter 복합을 설정 한 후 플러그인하십시오. 이제는 꽤 견고합니다. 이 시점부터 요구 사항에 따라 출력이 새로운 곳으로 가야한다고 지시 할 때마다 새 IWriter를 만들어 MultiWriter에 연결하기 만하면 기존 작업 코드를 건드릴 필요가 없습니다.

A 만 할 수있는 좋은 코드는 A, B, C, D를 할 수있는 나쁜 코드보다 나쁩니다.

1)해야 할 일만하는 코드를 작성하십시오.

가장 가까운 미래에이 코드 조각이 커질 것 같으면 추상화를 추가하고이 기능을 다른 곳으로 옮기는 등의 방법을 생각할 것입니다.

2) A, B, C 및 D를 수행하도록 코드를 계획하는 경우 고객은 궁극적으로 E를 요청합니다.

코드는해야 할 일을 수행해야합니다. 코드를 지속적으로 변경하지 말고 코드를 과도하게 디자인 할 것이기 때문에 향후 구현에 대해서는 지금 생각하지 않아야합니다. 물론 프로젝트 아키텍처의 일부로 계획하지 않는 한 아직 수행하지 않은 작업을 준비하는 데 어려움을 겪지 않고 현재 기능으로 인해 코드가 필요할 때마다 리팩터링해야합니다.

나는 당신이 좋은 책을 읽을 것을 제안합니다 : Pragmatic Programmer . 그것은 당신의 마음을 열고 당신이해야 할 것과하지 말아야 할 것을 가르쳐 줄 것입니다.

또한 Code Complete 는 모든 개발자 (프로그래머 만이 아님)가 읽어야하는 유용한 정보로 가득한 훌륭한 자료입니다.

아주 간단한 코드를 작성해야 할 때가되면 미래에 대해 생각합니다

어쩌면 여기에 문제가 있습니다.

초기 단계에서는 최종 제품이 무엇인지 전혀 모릅니다. 또는 당신이 그것을 가지고 있다면, 그것은 잘못입니다. 확실 해요 며칠 전 프로그래머에게 질문 한 14 세 소년과 같습니다 .SE는 미래의 경력을 위해 웹 응용 프로그램 중에서 선택해야하며 다른 것을 기억하지 못하는 경우 몇 년 안에 그는 변화를 좋아하고 다른 영역에 관심을 가질 것입니다.

세 줄의 코드를 작성하기 위해 새 인터페이스와 두 개의 클래스를 만들면 과도하게 엔지니어링됩니다. 모든 유용한 코드 줄마다 필요하지 않은 두 줄의 코드가 있기 때문에 유지 관리가 어렵고 읽기 어려운 코드를 얻을 수 있습니다. XML 문서, 단위 테스트 등을 계산하지 않습니다.

생각해보십시오. 코드에서 기능이 어떻게 구현되는지 알고 싶다면 20 줄의 코드를 더 쉽게 읽을 수 있습니까? 아니면 수십 개의 반 빈 클래스를 여는 것이 더 빠르고 쉽습니다. 어느 것이 어느 것을 사용하는지, 어떻게 관련되어 있는지 등을 알아내는 인터페이스?

코드베이스가 클수록 더 많은 유지 관리가 필요합니다. 피할 수있을 때 더 많은 코드를 작성하지 마십시오.

당신의 접근 방식은 다른 측면에서도 해 롭습니다.

• 기능을 제거해야하는 경우 수십 클래스 간의 종속성을 이해하기 위해 시간을 낭비하는 것보다 특정 20 라인 방법이 사용되는 위치를 파악하는 것이 쉽지 않습니까?

• 디버깅 할 때 작은 스택 추적을 갖는 것이 쉽지 않습니까, 아니면 무엇을 호출하는지 파악하기 위해 수십 줄을 읽는 것을 선호합니까?

결론적으로, 그것은 조기 최적화 와 비슷해 보입니다 . 처음에 문제가 있는지, 어디에 있는지 확실하지 않고 문제를 해결하려고합니다. 제품 버전 1에서 작업 할 때는 지금 구현해야하는 기능을 구현하십시오. 버전 14에서 2 년 안에 구현할 것으로 생각하는 것을 생각하지 마십시오.

(아마도) 결코 사용되지 않을 많은 코드를 작성하는 것은 P45로 발행되는 아주 좋은 방법 입니다. 당신은 필요가 없습니다 크리스탈 볼을 그냥 돌아올 수없는 돈을 비용을 개발 그래서 이러한 기능에 시간을 보내는 걸릴 것 최종 방향에 대한 아무 생각이 없습니다.

미래의 코드에서 무엇이 필요할지 예측하려고하면 종종 과도한 엔지니어링이 필요하지 않게됩니다 (현재 흔들려고하는 습관). 나는 단지 세 줄을한다고 말할 것이다. 필요가 생길 때 (이전이 아닌) 리팩토링. 그렇게하면 코드가 복잡하지 않고 항상 필요한 것을 수행하고 리팩토링을 통해 자연스럽게 좋은 구조를 발전시킵니다.

나는 종종 코딩이 힘의 빛 쪽 / 어두운 쪽과 같다고 말합니다. "빛"쪽은 더 많은 노력이 필요하지만 더 큰 결과를냅니다. "어두운"면은 빠르고 쉬우 며 즉시 큰 이점을 제공하지만 길을 잃게됩니다. 일단 어두운 길을 시작하면 영원히 운명을 지배 할 것입니다.

내가 가진 모든 직업에서, 나는 항상이 문제에 부딪친 다. 그것은 내가 탈출 할 수없는 저주와 같다. 회사 문화는 항상 어두운면의 경로이며, 새로운 기능을 제공하기위한 빠른 해킹 / 수정이며, 리팩토링 및 코드 작성에 대한 나의 탄원과 호소가 청각 장애에 빠지게됩니다. 변화를 시도하는 것 "(디자인 패턴을 소개하고 빠른 해킹을 피하고 싶었 기 때문에 몇 번의 농담도 없었습니다).

슬픈 사실은 종종 어리 석고 어두운면이 당신이 밟아야하는 길이며, 당신은 가볍게 밟아야한다는 것입니다. 소프트웨어를 작성 하는 올바른 방법 (예 : SOLID, 설계 패턴 사용, SoC 준수 등) 을 이해하는 프로그래머 if는 버그를 해결하기 위해 문장을 작성하는 단서가없는 해킹보다 훨씬 덜 일반적 이라는 점을 천천히 슬프게도 깨달았습니다 . 더 많은 버그가 발생하면 "이 작업을 수행하는 더 좋은 방법이있을 것입니다"라고 생각하고 코드를 올바르게 확장 가능하도록 리팩토링하는 대신 해당 명령문에 추가하십시오.

미래에 어떤 일이 일어날 지 알면 결코 나쁘지 않습니다. 어떤 일을하는 더 좋은 방법에 대해 생각하는 것은 일을 잘하게 만드는 것의 일부입니다. 더 어려운 부분은 소요 시간 : 지불 비율이 정당화되는지 여부를 결정하는 것입니다. 우리는 사람들이 즉각적인 출혈 (및 / 또는 고함)을 멈추기 위해 "쉬운 if"를하는 상황을 보았고, 그로 인해 혼란스러운 코드가 생겼습니다. 우리 중 많은 사람들은 원래의 코더가 움직 인 후에도 수수께끼 인 추상화를 과도하게 경험했으며 혼란스러운 코드를 생성했습니다.

귀하의 상황을보고 다음과 같은 질문을합니다.

1. 이 코드는 미션 크리티컬 한 것이며, 다시 코딩하면 훨씬 더 안정적입니까? 수술에서이 리팩토링 인명 구조입니까, 아니면 선택적이고 미용적인 것일까 요?

2. 6 개월 안에 교체 할 리팩토링 코드를 고려하고 있습니까?

3. 리팩토링에 소비하는 것만 큼 미래 개발자를위한 디자인과 추론을 문서화하는 데 많은 시간이 걸리나요?

4. 미래의 기능을 추가하기위한 우아한 디자인과 관련하여 사용자가 매주 변경을 요청하는 코드입니까? 아니면 올해 처음으로 만졌습니까?

YAGNI와 KISS가 하루를이기는 시간이 있지만 근본적인 변화가 당신을 곤두박질하게 만드는 날이 있습니다. 당신이 원하는 것뿐만 아니라 다른 사람들이 당신의 작업을 유지하기 위해 무엇을해야하는지 평가하는 것이 현실적이라면, 어떤 상황이 어떤 것인지 더 잘 결정할 수있을 것입니다. 아, 그리고 당신이 한 일과 그 이유를 적어 두는 것을 잊지 마십시오. 그것은 당신을 따르는 사람들뿐만 아니라 나중에 다시 와야 할 때 당신을 구할 것입니다.

Stroustrups의 두 번째 버전 인 'C ++ 프로그래밍 언어'에서 (페이지가 없습니다.)

자연스럽게 코드를 추가하지 마십시오.

그리고 나는 조언에 따라 잘 갔다. 물론 장단점이 있으며 균형을 찾아야하지만 짧은 파편은 큰 스파게티 엉망보다 테스트하기 쉽습니다.

한 사례에서 두 사례로 차별화하면서 2 개를 n 개의 사례로 생각하면 생각하지 못했던 많은 새로운 가능성에 대한 문을 열었습니다.

그러나 당신은 YAGNI 질문을해야합니다 : 그만한 가치가 있습니까? 정말 유용할까요? 경험이 있다는 것은 당신이 거의 잘못하지 않으며 초보자로서 더 자주 잘못된다는 것을 의미합니다.

패턴을 인식하고, 추상화가 너무 많아 코드를 유지하기 어려운지, 모든 것이 제대로 해결 되었기 때문에 유지하기 어려운지를 감지 할만큼 충분히 중요해야합니다.

해결책은 이것 또는 저것이 아니라 그것에 대한 생각입니다. :)

"A 만 할 수있는 좋은 코드는 A, B, C 및 D를 할 수있는 나쁜 코드보다 나쁩니다."

이는 제품 개발에 의미가있을 수 있습니다. 그러나 대부분의 IT 전문가는 제품 개발보다는 '프로젝트'에서 일합니다.

'IT 프로젝트'에서 우수한 컴 포넷을 프로그래밍하면 프로젝트 수명 기간 동안 원활하게 작동합니다. 5 년 또는 10 년 이상 실행되지 않으면 비즈니스 시나리오가 오래되어 새 프로젝트 / ERP가 될 수 있습니다. 제품이 교체되었을 수 있습니다. 이 5/10 년 수명 동안 코드에 결함이 없다면 아무도 그것이 존재한다는 사실을 알지 못하고 최고의 생각의 장점은 눈에 띄지 않습니다! (나만의 트럼펫을 치는 데 능숙하지 않다면!)

많은 사람들이 'Windows Ctl + Alt + Del'을 프로그래밍 할 기회를 얻지 못하고 그 기회를 얻는 사람들은 미래의 코드 잠재력을 깨닫지 못할 수도 있습니다!

린 (lean) 및 / 또는 민첩한 개발에 관한 많은 책들이이 접근 방식을 강화하는 데 도움이 될 것입니다 : 지금 필요한 것을 수행하십시오. 프레임 워크를 구축하고 있다는 것을 알고 있다면 추상화를 추가하십시오. 그렇지 않으면 필요할 때까지 복잡성을 추가하지 마십시오 . 린 소프트웨어 개발 (Lean Software Development )을 추천합니다 . 이것은 생산성에 실질적인 차이를 줄 수있는 다른 많은 개념을 소개합니다.

사람들이 올바른 방식으로 / 잘못된 방식으로 일하는 방식에 대해 이야기하는 것은 재밌습니다. 동시에 프로그래밍 작업은 여전히 ​​어렵고 복잡한 시스템을 작성하기위한 좋은 솔루션을 제공하지 않습니다.

언젠가 프로그래머는 복잡한 소프트웨어를 작성하는 방법을 알아낼 것입니다. 그때까지는 항상 "멍청한"프로토 타입 구현으로 시작한 다음 리팩토링에 충분한 시간을 투자하여 대학이 코드를 따를 수 있도록하십시오.

나중에 나오는 실제 요구 사항에 전혀 맞지 않는 조기 일반화 된 디자인을 보았을 때 나는 나를 위해 규칙을 고안했습니다.

가상 요구 사항의 경우 가상 코드 만 작성하십시오.

즉, 나중에 발생할 수있는 변경 사항에 대해 생각하는 것이 좋습니다. 그러나 이러한 통찰력 만 사용하여 요구 사항이 실제로 발생할 경우 쉽게 변경하고 리팩터링 할 수있는 코드 디자인을 선택할 수 있습니다. 당신은 당신의 머리 (가상 코드)에 그 경우에 쓰고 싶은 코드를 쓸 수도 있지만 실제 코드는 쓰지 않을 것입니다!

나는 당신에게 도움이되는 사고 방식은 항상 추상 솔루션 대신 코딩 문제에 대한 구체적인 솔루션을 위해 노력하는 것이라고 생각합니다 . 추상화는 실제로 코드베이스를 단순화하는 데 도움이되는 경우에만 추가해야합니다 (예를 들어 코드베이스를 더 작게 만들 수있는 경우).

많은 프로그래머들은 코드 를 건조 시킬 때 추상화가 거의 스스로 발생한다는 것을 발견 했습니다. 디자인 패턴 및 모범 사례를 사용하면 그렇게 할 수있는 기회를 찾을 수 있지만 추구해야 할 목표는 아닙니다.

오버 엔지니어링은 종종 코드 작성에 대한 불안감으로 보인다고 생각합니다. 모든 추상적 원칙과 패턴은 당신을 도울 수있는 도구로 취급되어야합니다. 흔히 발생하는 것은 표준으로 취급되므로 반드시 준수해야합니다.

나는 프로그래머가 항상 공리보다 추상화하는 방법을 결정하는 데 더 나은 위치에 있다고 생각합니다.

나머지는 이미 KeithS에 의해 언급되었습니다

좋은 디자인의 장점이 무엇인지 스스로에게 물어보십시오.

• 이해하기 쉬움
• 더 쉬운 유지
• 가지고 다닐 수 있는
• 오랫동안 유용함
• 새로운 기능을 쉽게 추가

이제 추상화의 모든 레이어를 추가하면 실제로 위에서 언급 한 요점에 추가되는지 묻습니다. 그렇지 않으면 잘못 하고 있습니다 .

다음과 같이 3 줄의 코드를 추가하여 새로운 기능을 추가 할 수있는 경우 :

if (condition()) {
  doSomething()
}

그럼 제발 그렇게 해주세요 이는 이전 디자인이 우수하고 적응하기 쉽다는 것을 나타냅니다. 클래스가 특정 확장 이상으로 커지기 시작한 후에 만 리팩토링 을 사용 하여 함수를 분할하고 새 클래스를 추출하십시오.

제 경험에 따르면 새로운 기능은 가능한 최소한으로 구현해야합니다. 무엇인가를 미리 파악해야 할 때만 (구체적으로 구현하는 데 1 일 또는 반일 이상 걸리는 경우) 거친 글로벌 디자인을 추가 할 수 있습니다. 그런 다음 코드 크기가 커질 때만 추상화 레이어를 추가하십시오. 그런 다음 나중에 리팩터링하십시오! 잠시 후 조각을 조금 더 디자인하거나 빠른 길을 가야 할 때 자연스럽게 느껴질 것입니다. 일부 코드에서 일부 정리를 사용할 수있는 또 다른 표시는 재사용 할 때입니다. 새 기능을 추가하거나 새 장소에서 이전 코드를 호출 할 때마다 이전 코드를보고 다시 추가하기 전에 조금 개선 할 수 있는지 확인해야합니다. 이런 식으로, 핫 코드는 천천히 더 깨끗해지며, 흥미없는 부분은 천천히 썩어 가며 소중한 시간을 소비하지 않습니다.

이런 식으로 작업하면 아무 것도 과도하게 디자인하지 않습니다. 새로운 것을 추가하고 싶을 때 오래된 코드로 돌아가거나 새로운 코드를 조금 더 추악하게 남기려면 약간의 훈련이 필요할 수 있지만, 과도하게 엔지니어링되는 대신 생산적인 무언가를 향해 노력하고 있습니다.