객체 지향 사례 확산 방법에 대한 팁

저는 약 250 명의 개발자가있는 중소 기업에서 일합니다. 불행히도, 많은 사람들이 절차 적 사고 방식에 빠져 있으며 일부 팀 은 실제로 응용 프로그램에 풍부한 논리가 포함되어 있으면 큰 트랜잭션 스크립트 응용 프로그램을 지속적으로 제공 합니다. 또한 설계 종속성을 관리하지 못하고 다른 많은 서비스에 의존하는 서비스 ( Big Ball of Mud 의 깔끔한 예)로 끝납니다 .

내 질문은 :이 유형의 지식을 전파하는 방법을 제안 할 수 있습니까?

문제의 표면은 이러한 응용 프로그램의 아키텍처와 디자인이 좋지 않다는 것입니다. 또 다른 문제는 모든 종류의 테스트 작성에 반대하는 개발자가 있다는 것입니다.

내가 이것을 바꾸려고하는 몇 가지 일 (그러나 나는 실패하거나 변화가 너무 작습니다)

• 설계 원칙 (SOLID, 클린 코드 등)에 대한 프레젠테이션을 진행합니다.
• TDD 및 BDD에 대한 워크샵.
• 코칭 팀 (소나, findbugs, jdepend 및 기타 도구 사용 포함).
• IDE 및 리팩토링 회담.

내가 앞으로 할 몇 가지 일 (하지만 나는 좋지 않을 수도 있습니다.)

• 서로 다른 팀에서 OO 사고 방식을 전파하는 OO 복음 주의자 팀을 구성하십시오 (이 사람들은 몇 달마다 팀을 변경해야합니다).
• 설계 검토 세션을 실행하여 설계를 비판하고 개선을 제안합니다 (시간 제한으로 인해 개선이 이루어지지 않은 경우에도 유용 할 수 있습니다)

.

내가 코치하는 팀에서 찾은 것은 내가 떠나 자마자 이전 관행으로 되돌아 간다는 것입니다. 나는 그들과 많은 시간을 보내지 않는다는 것을 알고 있습니다. 그래서 내가하고있는 일은 달라 붙지 않습니다.

이 질문에 답답한 것이 유감입니다 만,이 글을 쓰는 대안은 제가 세상을 떠날 때까지 벽에 머리를 때리는 것이 었습니다.

OOP를 시도하지 마십시오. 상황이 악화 될뿐입니다. OOP는 일반적으로 나쁜 생각이 아니기 때문에 아닙니다. 그러나 그 헤어볼 코드를 책임지는 사람은 이러한 문제를 피할 수있는 도구뿐만 아니라 경험과 더 중요한 동기 부여가 없기 때문입니다.

깨끗한 코드를 작성하고자하는 사람들은 OOP, 절차 적, 기능적 등 어떤 주어진 패러다임에서도 그렇게 할 것입니다. 그러나 모든 프로그래머가 이와 같은 것은 아니며 깨끗한 코드 도구를 그렇지 않은 사람들에게 밀면 필요를 이해하면 이미 존재하는 도구처럼 남용되는 도구로 끝납니다. 관련이없는 메소드를 클래스로 그룹화하고, 관련이없는 클래스에서 상속되는 클래스, 의식적인 디자인이 아닌 시행 착오 디버깅을 기반으로 설정된 메소드 가시성, 정적이 아니어야하는 정적 메소드 및 정적이 아닌 정적 메소드 , 시간을 낭비하게 될 것입니다.

대신, 유지 관리 및 우아함에 대한 의식을 높이는 데 투자 할 수 있는지 확인하십시오. 결국 OOP의 핵심 목표는 캡슐화, 모듈화, 느슨한 결합, 낮은 상호 의존성, 가변 상태 유지 및 범위를 최소한 등등 등등. OOP는 확실히 당신에게 이것을 달성하는데 필요한 도구를 제공하는 유일한 패러다임은 아닙니다.

마지막 요점은 다음과 같습니다. OOP는 훌륭한 아이디어이며 특정 종류의 문제에 대해서는 잘 작동하지만 많은 종류의 문제에 대해 (내 경험에서 말하고 위대한 마음의 의견을 표현하고 있습니다) 문제는 완전히 부적합합니다. OOP를 처음 접할 때 반 절차 적 스파게티 코드가 당신에게 익숙한 유일한 대안 일 때, OOP는 자연적으로 하늘의 선물로 (그리고 상대적으로) 선물로 나타납니다. OOP 망치의 못으로 모든 문제. 그것은 당연한 일이며 OOP가 한계를 넘어 OOP 기술을 쌓을 수있는 좋은 방법이므로 모든 부정적인 것은 아닙니다. 그러나 아마도 (어쩌면)이 특정 코드베이스에는 결국 OOP가 필요하지 않습니다. 절차 적 아키텍처로부터 훨씬 더 많은 이점을 얻을 수있을 것입니다.

TL; DR : 어떤 것도 복음화하고 싶다면, 특정한 패러다임이나 방법론이 아닌 (플랫폼에 구애받지 않는) 좋은 코딩 관행이되게하십시오.

아직 변경하고 싶지 않은 사람은 변경할 수 없습니다. 그렇기 때문에 코치 한 팀이 기존 방식으로 복귀 한 것입니다.

실제로 귀하의 질문은 "개발자가 OO 접근 방식으로 변경하기를 원하는 방법은 무엇입니까?"

간단하게 시작하고, 작게 시작하고, 그곳에서 일을 시작하십시오. 코드, 다른 개발자 또는 회사에 대한 추상적 또는 철학적 이점 대신 개별 개발자에게 이점을 보여주십시오.

다양한 OO 기법으로 이어질 것입니다 방법을 보여 적은 그들이 같은 빠른뿐만 아니라 개발 시간을 쓸 필요가 있음을 코드. 거의 모든 개발자는 자신의 업무를보다 쉽게 ​​만들어 줄 제안을들을 것입니다.

그런 다음 OO 기술이 코드를보다 쉽게 ​​유지 관리하는 방법을 시연하십시오. 이러한 유형의 환경에있는 모든 사람 은 프로덕션 응용 프로그램의 3 분의 1을 없애는 " 변경 "을하는 것을 두려워 합니다. 캡슐화는 이러한 위험을 피하기위한 열쇠이며 응용 프로그램의 각 계층이 다른 계층과 계약을 유지할 수 있도록합니다.

데이터가 어떻게 전달되는지 살펴 보겠습니다. 매번 변수의 목록이 길면 예비 단계로 구조체 (또는 클래스!)에 변수를 묶는 것을 고려하십시오. 객체 내에서 데이터를 간단히 래핑하는 것은 레이어 간 계약의 시작입니다.

더 넓은 수준에서-아직 노력하지 않은 경우 이러한 노력을 위해 경영진 구매를 고려하십시오. 경영진은 결함 감소와 변경으로 인한 위험 감소의 구체적인 이점을 파악해야합니다. 결국 리팩토링 프로세스는 개발 시간을 단축해야하지만 장기적인 이점입니다.

복습 팀과 OO 전도사에 대한 당신의 생각은 좋은 것입니다. 이 아젠다를 추진하는 것은 당신 이상의 것이어야합니다.

내 경험은 절차 적 사고 방식에서 OO 사고 방식으로 전환하는 것이 큰 장애물이라는 것입니다. 많은 개발자들이 견딜 수없는 인내가 필요합니다. 이는 주로 OO의 기본 사항을 검토했기 때문입니다.

서로 다른 팀에서 OO 사고 방식을 전파하는 OO 복음 주의자 팀을 구성하십시오 (이 사람들은 몇 달마다 팀을 변경해야합니다).

좋은 생각입니다. 철저하고 OO에 대해 처음부터 이야기해야합니다. OO를 배울 때 역사적 일화가 많은 도움이되었습니다.

나는 또한 제안 할 것이다.

• 동기 부여가 핵심이므로 OO가 작업, 특히 코드 유지 관리 기능을 향상시킬 수있는 방법을 자세히 설명하십시오.
• 코드 검토를 수행하고 컴포지션, 상속, 다형성 및 패턴을 적용하여 리팩토링하는 방법을 보여줍니다.
• SCRUM과 같은 좋은 프로세스를 소개하고 개발자를 참여 시키십시오.
• '리팩토링'및 '패턴 리팩토링'과 같은 책을 반드시 읽으십시오.

Shuvo Naser에 동의합니다. 큰 장애물이므로 등반처럼 취급하십시오. OOP를 사용하여 전체 응용 프로그램을 설계하는 방법을 배우려면 시간이 걸립니다.

1. OOP를 이해하는 사람들을 식별하고 팀 리더, 트레이너, 디자이너, 코드 검토 자 등에 더 가깝게 옮기십시오.
2. 기존 프로젝트를 학습 참조로 사용하십시오. 아마도 # 1의 사람들이 그 팀에 있었을 것입니다.
3. 기존 프로젝트를 리팩터링하십시오. 이를 통해 일부 사람들은 절차 코드와 OO 코드를 연결하는 데 도움이됩니다. 기본부터 시작하십시오. 이 원칙을 언제, 어디서, 왜 사용해야하는지 알아야합니다.
4. 그들이하는 일을 알고있는 사람들과 디자인 세션에 참여하십시오.
5. 설계 지침을 제공 할 수있는 사람과 함께 개발 팀에 배치하고 프로젝트가 OO 원칙을 고수하는지 확인하십시오 (처음에이 작업을 수행하려는 이유가 개발을 개선하기 때문이라고 가정).

입양이 혜택을 보는 것보다 드물다. 복잡한 디자인에 대해 이야기하고 있으며 TPS 보고서 표지를 사용하지 않습니다 .

이미 좋은 아이디어가 있습니다

질문에 요약 한 아이디어는 훌륭합니다. 당신이 성공을 찾지 못한다는 것은 큰 놀라움입니다. 2012 년이며, 객체 지향 혁명은 최첨단 기술에서 실용적 기술로 오래 전부터 이어졌습니다. 이직률이 낮고 채용이 거의없는 한, 수십 또는 수백 명의 훌륭한 객체 지향 프로그래머를 얻는 데 어려움을 겪을 것입니다.

민첩하거나 객체 지향적입니까?

TDD와 같은 일부 애자일 기술과 일부 새로운 개념에 대해 언급 했으므로 여전히 일부 관리 팀이 적극적으로 싸운 것을 수용하지 않는 사람들에게 너무 가혹하지 마십시오. 어떤 사람들은 애자일을 수용한다고 주장하지만, 그것에 대해 이야기 할 때, 그것이 의미하는 바를 의미합니다. 조직은 의사 결정과 적응을하는 팀이 아니라 강력한 계층 적 계약 스타일 제어를 특징으로합니다.

그러나 객체 지향으로 돌아갑니다. 객체 지향 분석이나 디자인에 대해서는 언급하지 않았으며 어떤 프로그래밍 언어가 어떤 객체 지향 프로그래밍 언어에 영향을 미치는지 잘 모르겠습니다. UML은 많은 객체 지향 프로그래머들 사이에서 인기 문제가 있다는 것을 알고 있습니다. OOAD에서 철저히 훈련을 받았으므로 자연 언어를 배우고 싶은 나라의 문화와 역사를 배우는 것과 같습니다. 예를 들어, 그리스어를 배우고 싶다면 알파벳, 어휘 및 문법을 배울 수 있지만 풍부한 역사와 문화를 무시하면 많이 그리워 할 것입니다. 어쨌든 객체 지향 프로그래밍 언어에 대한 모든 것을 배우지 만 OOAD에 대해서는 아무것도 배우지 못하면 중요한 기회가 사라 졌다고 생각합니다.

극복 할 문제?

다리가 너무 멀어요? 사람들에게 일주일에 한 번 작은 일을 배우도록 요청하면 참여하는 사람들 사이에 많은 변화가있을 것입니다. 당신이 그들에게 그들이 알고있는 모든 것을 바꾸라고 요구한다면, 그것은 많은 사람들에게 환영받을 것이며, 많은 사람들에게는 어렵고 다른 사람들에게는 불가능할 것입니다. 소스 제어와 같은 일부 변경 사항이 현지화되었습니다. 당신은 전에 그것을하지 않는 전환, 기억의 한계를 강조하지 않는 훈련을했다, 누군가 처음으로 당신을 안내 한 다음, 매일 매우 쉬웠다.

다른 변화는 널리 퍼져 있습니다. 예를 들어, C를 덤프하고 Java로 전환하려면 새로운 IDE, 새로운 컴파일러, 새로운 언어, 새로운 API, 새로운 배치 모델 등을 채택하기 위해 매일 상당한 훈련, 설정 및 큰 변화가 필요합니다. 파일럿 프로그램이나 기업 구조 조정과 관련하여 가장 자주 발생하는 일.

혁명을 이끌고 있습니까? 현재 일을하고있는 사람들이 보상을받는 이력을 가지고 있고 회사가 실패의 위험에 처해 있지 않다면 변화에 대한 동기는 무엇입니까? 방향을 가리키고 그들이 예측할 수없는 결과에 대해 책임을지게하는 외부인처럼 보인다면, 그것은 모든 위험, 보상이없는 것처럼 보일 수 있습니다.

권력 또는 아이디어 리더십? 많은 조직이 직책에 따라 운영됩니다. 관리자, 섹션 책임자, 이사 및 부사장의 눈에 띄는 지원이 없다면 아이디어 리더 일뿐입니다. 어떤 사람들은 한 가지 생각을 가지고 다른 생각을 즐겁게 할 수없는 위험한 위치에 있습니다. 당신이 그들에게 말하지 않고 보여줄 수 있다면, 회의론자들을 조용히하고 재능있는 동맹국들에게 관심을 가지게 될 것입니다.

지원 기반이 너무 작습니까? 250 명의 사람들 사이에서 심사를 수행하고 그들을 포용 할 준비가되어 있고 배우고 싶어하며 배우고 싶지 않은 세 가지 범주로 분류하십시오. 변화에 관심이없는 일부 사람들과 좌절해야 할 충분한 이유가 있습니다. 로프를 밀고있을 수도 있습니다. 이것은 노력 낭비입니다. 누가 변화를지지하는지에 대한 느낌이 있다면, 어떤 변화에 관심이 있는지 알 수 있습니다.

윤리적이고 실질적인 선택이 도움을 줄 수있는 중간 그룹을 돕는 의료 심사와는 달리 판단과 선호도에 따라 에너지와 시간을 투자 할 수 있습니다. 당신의 성공을 위해 새로운 아이디어를 수용 할 준비가 된 그룹을 육성하지 않겠습니까? 그것들은 처음에는 적지 만 눈덩이처럼 옹호자 인 가시성과 신뢰성이 커질 것입니다. 곧 사람들이 다음 훈련이 언제 될지 묻습니다.

장기적으로는? 당신이 후에 물건을 운반 할 챔피언을 육성 할 때까지, 당신은 관계를 구축하는데 시간을 투자해야합니다. 한 달 이상 코치 한 팀과 함께 있어야 할 수도 있습니다. 팀이 자체적으로 개선 된 관행을 소유 할 때까지는 기술 또는 방법론 경찰 일뿐입니다. 멘토링은 몇 년이 걸릴 수있는 프로세스입니다. 개발자가 원하지 않는 많은 것들이 중요하다고 생각합니다 (특히 단위 테스트를 언급했습니다). 이것이 가져 오는 가치에 대한 공유 비전을 구축하는 데 시간이 걸릴 수 있습니다. 품질에 대한 명성이 높은 포춘지 선정 500 대 기업의 코드 커버리지 툴을 옹호 한 적이 있기 때문에 경험을 통해이 사실을 알고 있습니다.

전문가 또는 풀뿌리? 멘토링보다 훨씬 빠른 것은 각 팀원이 제공하는 풀뿌리 지원을 장려하는 것입니다. 10 명의 소프트웨어 전문가 팀부터 시작하여 한 사람이 항상 프로세스 작업을하도록하거나 10 명의 사람이 프로세스의 10 %를 처리하도록 선택할 경우 두 번째를 선택합니다. 풀뿌리 프로세스를 통해 옹호자들은 접근 방식의 영향을 느끼고 작업을 소유 한 팀의 문제를 가장 잘 해결할 수 있도록 접근 방식을 조정할 수 있습니다.

프리덤 라인이 보입니까? "모범 사례"도입의 일부는 사람들이 일반적인 방식으로 일을 할 수있는 자유를 포기하도록하는 것입니다. 개발자에게 많은 선택권을 남길 수있는 기회를 찾는다면 프로그래머의 재량권을 얻는 것이 더 맛있습니다. 그들이 선택한 것은 우리가 자유 선이라고 부를 수있는 파티션에 의해 지시 된 것으로부터 묘사됩니다. 조직, 지역 / 현장 별, 팀 및 개인 관행에 대해 유사하고 정당한 부서가 필요할 수 있습니다.

이것은 코멘트 였어야하지만, 아직 물건에 대해 언급 할 수 없기 때문에 대답 일 수도 있습니다.

이런 종류의 혁신에서 가장 중요한 것은 (OPP 또는 다른 프로그래밍 패러다임 전환, 예를 들어 함수형 프로그래밍 또는 내년에 나오는 것 등)은 DO CODE REVIEWS AND PEER PROGRAMMING 입니다. 그들과 함께 팀을 도와 다른 방법으로 그들을 도울 것입니다.

객체 지향 프로그래밍에 대한 나의 개인적인 길은 코드 검토를 수행하는 임의의 임의의 주장이 모듈 방식으로 작업을 수행하고 완전한 C ++ OO를 가지지 않고 상태를 유지하기 위해 나를 쫓아서 시작했을 때 시작되었습니다. 코드를 생각하다

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(clients_total은 전체적으로 중복 될 수 있으며 특히 계획이 좋지 않은 예일 수 있습니다)

그리고 더 많은 상급 동료가 내 화면을 가리킬 때만이 작업을 마쳤습니다. "같은 것을 한 번 이상 쓰면 프로시 저나 함수를 사용하고 반복해서 호출합니다"라고 말했습니다.

대화와 회의 및 선택적 관행은 순수한 호기심 외에는 실질적인 추진력이 없기 때문에 패러다임 전환이나 새로운 관행을 도입하지 않습니다. 반면에, 나쁜 일을하지 않거나 일반적으로 일에 찡 그리게하면 채택률이 실제로 높아집니다.

그들이하고있는 일에 적절한 디자인을 통합 할 때까지 계속되는 기발하고 계급 지향적 인 개발에 대비하십시오. 당신은 당신이 조금 안에 죽게 할 많은 것들을 보게 될 것입니다. 그러나 그것이 학습의 길처럼 보입니다.