팀원들에게 일반적인 프로그래밍에 대한 인식을 확산시키는 방법?

나는 사람들이 믿는 환경에 머물고 있습니다.

1. Java 제네릭은 실제 코딩이 아닌 라이브러리 작성 전용으로 사용되는 기능입니다.
2. C ++는 OO 프로그래밍 언어입니다. template선택적이고 피할 수있는 기능입니다

그러나이 사람들은 일반적인 프로그래밍 (예 : STL, Java 컨테이너)을 사용하여 작성된 라이브러리에 크게 의존합니다. templates 또는을 사용하여 코드를 작성 generics하면 코드 검토자가 해당 코드를 거부 할 가능성이 높으며 "적절하고 이해할 수있는 / 우아한" 방식으로 작성 하겠다고 언급 합니다.

이러한 사고 방식은 일반 프로그래머부터 상급 관리자까지 적용 할 수 있습니다. 시간의 90 %가이 사람들에게 로비가 있기 때문에 탈출구가 없습니다.

가장 좋은 방법은 (무엇 되지 않는 목을 잘라 을 설명하는), 동시에 두 OO 및 일반 프로그램을 구성하는 코드를 작성의 실제적인 접근 방법은?

여전히 "일반 코딩"에서 jave 제네릭을 사용 하지 않는 사람들이 여전히 있습니다 . C ++ 템플릿을 사용하여 믿을 수 있지만 제네릭? 배우거나 사용하기도 어렵지 않습니다. Java 및 C ++의 가장 좋은 기능은 각각 제네릭과 템플릿입니다.

사람들에게 물건을 설득하는 가장 좋은 방법은 설득력있는 주장을하고 위협하지 않고 옳은 것입니다.

프로그래밍 언어로 템플릿을 사용하는 것과 같은 일을하지 않는 한 파라 메트릭 다형성 (일반 / 템플릿)이 거의 확실합니다.

1. 코드 중복을 피하십시오.

이것은 명백하지만 다형성 코드는 일반적인 코드입니다. 그것이 제네릭이라고 불리는 이유입니다.

더 나은 정적 검사를 지원합니다.

파라 메트릭 다형성이 없다면 당신은 같은 것을 쓰고 결국 public Object clone()또는 public boolean equals(object b)단지 가증되지 않는, 그들이하는 일에 대한 정보를 제공하지 유형이 있고, 변함없이 사방에 예외를 던져 결국. 파라 메트릭 다형성의 대안은 모든 곳에서 사용됩니다

3. 비모수 적 다형성 OOP 코드는 기본적으로 "이진 방법"을 올바른 방식으로 처리 할 수 ​​없습니다.

당신은 이것을 자주 사용합니다.

4. 모범 사례입니다

Java에서는 제네릭 사용이 모범 사례로 간주됩니다 (Josh Bloch의 Effective Java 참조). Sutter와 Alexandrescu와 같은 주요 C ++ 사상가들은 템플릿을 사용하여 다양한 문제를 해결하도록 권장합니다.

5. OO 패러다임에 맞습니다.

사람들은 종종 이것을 알지 못하지만 하위 유형과 제네릭의 조합은 시스템 중 하나만있는 시스템보다 훨씬 강력하고 표현적인 시스템을 만들어냅니다.

스칼라의 믹스 인을 고려하십시오. 이것들은 구성 요소 부분에서 객체를 하나로 묶을 수있는 좋은 기능입니다. 제네릭과 템플릿은 이러한 이점 중 일부를 시뮬레이션 할 수 있습니다. 예를 들어 객체 중 하나가 데이터베이스를 사용한다고 가정합니다. 좋은 디자인은 데이터베이스 액세스를 별도의 클래스로 추상화해야합니다. 올바르게 수행하면 데이터 저장소를 모의 할 수있을뿐만 아니라 (테스트의 핵심) 새로운 SQL 데이터베이스와 같은 대체 구현을 추가 할 수도 있습니다. 그러나 사용하는 구현에 관계없이 비즈니스 오브젝트의 다른 기능을 사용하게되면 문제점이있을 수 있습니다.

구조의 제네릭!

   public class Business<S extends Datastore>{
      private S store; ...
   }

이제 Business데이터베이스 별 기능을 사용하는 능력에 따라 객체를 정적으로 차별화 할 수 있습니다. 여전히 런타임 검사와 캐스팅이 필요하지만 더 나은 코드를 만들기 시작할 수 있습니다.

과

6. 일반 코드가 존재하지 않습니다.

프로그래밍 유니버스에는 세 가지만 있습니다.

1. 도서관
2. 구성 및
3. 나쁜 코드.

코드를 라이브러리처럼 생각하지 않으면 프로젝트 요구 사항이 변경 될 때 심각한 문제가 발생합니다. 아키텍처는 (아마도) 좋은 API를 디자인하는 기술입니다.

나는이 태도가 놀랍습니다. 매개 변수화 된 유형으로 프로그래밍하는 데 익숙해지면이를 사용하지 않으면 모든 것이 고통스러워집니다. 그리고 Java와 C ++에는 해결에 도움이되는 거친 지점이 많이 있습니다.

이것은보다 일반적인 질문의 전문화 된 형태입니다. "상사들이 더 새롭고 더 나은 기술을 사용하기 시작하도록 어떻게 설득합니까?"

불행히도, 나는 당신이 할 수 있다고 생각하지 않으며, 당신이해야한다고 확신하지 않습니다. 그들이 선택한 방식으로 원하는 방식으로 일을하도록 비용을 지불하고 있기 때문에 그것은 정의에 의한 선택입니다. 당신이 할 수있는 최선의 방법은이 기술이 이미 있고 많은 사람들이이 기술을 사용하고 있으며 미래의 길로 보인다는 것입니다. 물론 그들이 이미 알아야 할 사실을 언급하고 싶을 수도 있습니다. 사람들이 자신의 기술을 정체시키지 않도록하는 것이 가장 좋습니다. 그러나 그것이 전부입니다. 만약 그들이 그것을 사지 않는다면, 당신이 할 수있는 일은 없습니다.

그들은 당신이 그들의 수준에서 생각하지 않기 때문에 당신이 가지고 있지 않은 다른 고려 사항이있을 수 있습니다. 엔지니어로 생각하고 비즈니스 용어 또는 인적 자원 용어로 더 많이 생각하고있을 수 있습니다.

• 제네릭 (또는 무엇이든)이 제품의 가치를 향상 시킵니까? 아마 아닙니다.

• 제네릭 (또는 무엇이든)은 이미 고용 한 사람들이 자신의 일을하기가 더 어려워지게합니까? 예.

• 제네릭은 출시 기간을 개선 할 수 있습니까? 유일한 엔지니어라면 당신 일 것입니다. 그러나 집에 다른 코드 줄을 작성하기 전에 엔지니어 전체가 제네릭에 대해 교육을 받아야하는 경우, 아니요.

따라서 작업 변경 만 고려할 수도 있습니다. 마지막 작업에서 Java와 함께 제네릭을 사용한 첫 번째 사람 이었지만 다행히도 문제가 없었습니다. 그들은 제네릭이 코드를 '읽기 더 어렵게 만든다'는 우려를 표명했지만 내 길을 가지게했다. 그런 직업을 찾으십시오.

나는 모든 검토에 앞서 제네릭의 장점을 코드 검토 자와 다른 동료들에게 알리겠다.

1) 제네릭 클래스 또는 메서드에 의해 수행되는 유형을 지정할 수있게함으로써 제네릭 기능은 유형 안전 부담을 사용자에서 컴파일러로 이동시킵니다. 컴파일시 적용되므로 올바른 데이터 유형을 테스트하기 위해 코드를 작성할 필요가 없습니다. 유형 캐스팅이 필요하고 런타임 오류 가능성이 줄어 듭니다.

2) 제네릭은 여러 구현의 오버 헤드없이 형식 안전성을 제공합니다.

따라서 [1]과 [2]는 코드 오류의 위험을 줄입니다. 이를 통해 개발자 시간과 회사 비용이 절약됩니다.

가독성이 문제인 경우 일반 유형을 사용하는 것이 어색 할 수 있습니다. 이것이 코딩 지침을 확장하려는 이유 중 하나입니다. 이것은 라이브러리를 확장하기위한 것이 아니라 작업 일 컨텍스트에서 수행 할 수 있습니다 (그러나 나중에 쉽게 인식 할 수 있도록 코드에서 라이브러리에 대해 가능한 후보 메소드를 표시하고 리팩토링하는 것이 좋습니다). 따라서 작업 환경에서 사용하지 않는 이유는 없습니다.

다른 프로그래머가 제네릭에 문제가없는 방법에 대한 몇 가지 진술을 추가합니다. 제네릭은 Java 및 C #과 같은 다른 많은 언어에서 널리 사용됩니다. 진지한 프로그래머라면 그런 안전한 빌딩 블록 없이는 삶을 어려워 할 것입니다.

그럼에도 불구하고 일부 개발자가 처음부터 시작하지 않았을 수도 있습니다. 경영진은 과거에 프로젝트를 보호하기 위해 의식적인 결정을 내릴 수 있었으므로 이러한 챕터를 위험한 지역으로부터 보호 할 수있었습니다. 여기에서 충분한 분석이나 미세 관리가 거의 수행되지 않기 때문에 무고한 사람과 유죄 인 모두 책임을집니다.

만약 당신이 좋은 사례를 제시하고 합리적인 대가로 답을 얻지 못하면 비밀리에 프로그래밍을 진지하게 다루는 다른 회사를 찾기 시작합니다.

아키텍트 / 기술 책임자가 아닌 한 제네릭 / 템플릿을 사용해야하는 것은 어렵습니다. 코드 검토 전, 바람직하게는 구현을 시작하기 전에 제네릭 / 템플릿 솔루션을 제안해야합니다.

당신이 할 수있는 일은 어떤 경우에 제네릭을 사용해야하는 이유를 설명하는 것입니다. 이점을 입증 할 수 있으면 동료가 동의 할 수 있습니다. 제네릭 / 템플릿을 사용해야하는 가능한 이유는 다음과 같습니다.

• 반복적 인 작업을 위해 더 적은 코드를 작성할 수 있어야합니다.
• 프로그래머 작업이 쉬워집니다
• 솔루션 설계자가 설정 한 패턴을 시행합니다.
• 일반적인 기능을 캡슐화하여 프로그래머가 코드를 복사하여 붙여 넣지 않도록합니다 (즉, 이중 유지 보수 문제 방지).
• 미래에는 코드를 합리적으로 증명 합니다 (이 길은 추론하기 어렵지만)

최근 Java 프로젝트에서 몇 가지 기본 사항을 만족했기 때문에 일반적인 추상 클래스를 성공적으로 추가했습니다. 팀의 다른 사람들이 작업을 쉽게 하고 건축가가 이미 제안한 패턴을 시행했으며 프로그래머가 필요로하지 않는 공통 코드가있었습니다. 복사 및 붙여 넣기. 건축가가 합리적으로 유능한 사람들이 실제 시스템의 복잡성으로 인해 여전히 잘못되었다고 썼지 만, 제네릭은 어느 클래스가 어디로 가는지를 표시합니다.

분명히 비밀 유지 계약을 위반하지 않으면 실제 사례를 보여줄 수 없습니다. 그러나 내가 한 일의 예로 전략 패턴 을 수행 하고 제네릭을 사용 하여 전략 을 시행하는 것입니다. 이것이 전략 패턴입니다.

그리고 프로그래머가이 패턴을 적용하기 위해 형식이 Context있는 것을 사용해야한다는 일반 형식을 추가 할 수 있습니다 Strategy. 코드 측면에서는 Java에서 다음과 같이 보입니다.

// declare the generic Context class that has a type "S" 
// that is an upper bound class of Strategy
public class Context <S extends Strategy> {
    S strategy;

    // Constructor with an initial strategy
    public Context(S initialStrategy) {
        this.strategy = initialStrategy;
    }

    public void doSomething() {
      strategy.execute(); // assumes that Strategy has an execute() method.
    }

    public void setStrategy(S strategy) {
        this.strategy = strategy;
    }
}

내가 아는 한 어떤 패턴 으로도이 작업을 거의 수행 할 수 있습니다. 코드 디자인에 대한 확신을 가지려면 단위 테스트를 사용하여 일반 / 템플릿 디자인을 테스트 할 수 있는지 확인하십시오.

동료가 아이디어를 좋아하지 않는다면 개인적으로 생각하지 마십시오. 생각한대로 쉽게 처리 할 수있는 솔루션이 아닐 수도 있습니다. 그렇기 때문에 구현을 시작하기 전에 일반 / 템플릿 솔루션을 제안해야합니다. 실제 문제를 다른 방식으로 해결하려면 여전히 동료와 협력해야합니다.

항상 같은 일을하는 몇 가지 방법이 있습니다. 템플릿 사용이 템플릿을 잘못 사용하는 경우 코드 검토에 실패해야합니다.

그러나 코드가 템플릿을 이해하지 못하기 때문에 코드가 검토에 실패하면 문제의 종류가 다릅니다. 이 경우 템플릿을 익히도록 조언하십시오.

여기서 다루는 것은 편향의 모음입니다. 사람들은 현 상태를 선호하고, 집단적 사고가 이루어졌으며, 사람들이 그들의 믿음에 굳건 해 지도록 몇 차례 논쟁을 벌였습니다.

여기서 가장 효과적인 전략 중 하나는 작은 승리에 집중하는 것입니다. 난에서 다음 예제를 읽을 책 : 저자가 철저한 비 애플 사용자이었다. 그녀는 그것들을 좋아하지 않았고 그들과는 아무런 관계도 원하지 않았습니다. 그녀는 Pro-Apple 자세를 가진 사람들과 많은 토론을했으며, 각각은 발 뒤꿈치를 땅에 깊숙이 밀어 넣었습니다. 그런 다음 누군가가 그녀에게 iPod shuffle을 구입했으며 그런 식으로 편견이 사라졌습니다. 애플 제품 만 사고 싶지는 않았지만 견고하고 견고한 안티 애플 자세는보다 균형 잡힌 관점으로 대체되었다. 타협의 여지가 있었고 그녀는 천천히 애플로 완전히 전환했다.

따라서 모든 사람을 한 번에 설득하려고 시도하지 마십시오. 반대의 효과가 있습니다. 하나의 작은 것에 집중하면 나머지는 저절로 일어날 것입니다. 사람들이 한 번에 한 번이 아니라 조금씩 지나갈 수 있도록 논쟁의 양 면적 특성을 제거하십시오.

초점을 맞출 특정 요점은 상황에 따라 다르지만 여기에는 한 가지 아이디어가 있습니다. 라이브러리와 '실제 코드'간 스케치는 부자연 스럽습니다. 내 생각에, 응용 프로그램을 만드는 프로그래머는 자신이 만들고있는 응용 프로그램 유형에 대해 라이브러리에서 시간의 80 %를 소비하고 해당 라이브러리를 사용하여 응용 프로그램을 빌드하는 데 20 %를 사용해야합니다. 보관할 가치가있는 모든 코드는 라이브러리로 간주해야합니다. 귀하의 상사에게 코드의 일부를 사내 라이브러리로 일반화 할 것을 제안합니다 (아직없는 경우). 자체 로직에 따라 제네릭을 사용해야하며 위의 추정에 따르면 코드의 80 %가 라이브러리 내부로 끝날 수 있습니다. 모든 사람이 다른 쪽에서 제네릭을 사용하게되면 익숙해 져야하고 편향이 사라져야합니다.

"이해할 수 있음"에 유의하십시오. 코드 검토자가 제네릭의 이점을 보지 못하면 모든 항목은 <<<>>>이해할 수없는 노이즈이므로 불필요합니다.

제네릭을 사용하여 피할 수 있었던 버그 데이터베이스에 실제로 포함 된 현재 버그 (개방되었거나 최근에 수정 된 버그)의 수를 살펴 보는 것이 좋습니다. ClassCastExceptions를 찾으십시오.

또한 제네릭을 사용하여 피할 수있는 버그가없는 경우 동료는 버그가 필요하지 않다는 점에 유의하십시오.

나는 이것을 쉽게 할 것입니다. 몇 년 전에 Java 1.4에서 1.6으로 옮겨 갔으며 제네릭은 정말 충격적이었습니다. 컬렉션, 맵 및 기타 구조를 몇 가지 저글링하려는 경우 간단하고 매우 유용합니다. 그러나 일반 데이터를 매개 변수로 사용하고 조작하고 다른 클래스에 전달하는 클래스를 작성하는 것은 매우 혼란스러워집니다. 모든 작업을 수행함으로써 큰 ​​만족을 얻었지만 추가 시간과 노력이 그만한 가치가 있는지 궁금합니다. 또한 많은 수의 Java 프로그래머가 실제로 중단되지 않을 수도 있습니다.

지금까지의 일반적인 여정에서 몇 가지 더 랜덤 한 생각 :

• ClassCastException은 런타임에 발생하지만 일반적으로 처음 몇 번의 실행에 표시되며 수정하기 쉽습니다.
• 내가 제네릭에 대해 읽은 모든 기사는 때로는 작동하지 않으며 @SuppressWarnings(value="unchecked")가끔 사용해야한다고 말합니다 . 제네릭의 한계를 넘어서거나 어리 석고 생각이 더 필요한지 어떻게 알 수 있습니까?
• @SuppressWarnings(value="unchecked")한 줄에만 적용 하기 어려울 수 있습니다 .
• 클래스 중 하나에 멋진 제네릭을 추가했습니다. 나는 결코 그것을 만질 수 없었던 클래스를 일반화하기 전에 클래스를 향상시킬 수있는 몇 명의 프로그래머를 알고 있었고 나중에 깨끗한 컴파일을 얻었습니다.

제네릭은 내 코드를 정리하고 코드를 거부하기에 너무 많은 문제를 경고했지만, 개발 시간이 길어지고 교육에 더 많은 시간이 걸리며 Java 프로그래머는 C #, C 및 Visual Basic에서 일해야했습니다. .. 또는 Java 1.4. 동료가 이해할 수있는 코드 작성에 중점을 둡니다. 이해할 수있는 제네릭을 사용할 수 있다면 좋습니다. Java generics는 아직 파악되지 않은 기회 / 문제로 생각합니다.