기존 팀원에게 OOP 개념을 도입하기위한 모욕적 인 방법이 아닌 효율적인 방법을 찾고 있습니까? 내 팀원은 OO 언어를 처음 사용하지 않습니다. 우리는 오랫동안 C ++ / C #을 해왔으므로 기술 자체가 친숙합니다.
그러나 나는 노력 (주로 코드 검토의 형태)을 크게 주입하지 않고 둘러보고, 우리가 생산하는 것은 클래스 내부에서 발생하는 C 코드 인 것 같습니다. 단일 책임 원칙, 추상화 또는 커플 링을 최소화하려는 시도는 거의 사용되지 않습니다. 생성자가 없지만 인스턴스화 될 때마다 0으로 memset되는 클래스를 보았습니다.
그러나 내가 OOP를 시작할 때마다 모두가 항상 고개를 끄덕이며 내가 말하는 것을 정확히 알고있는 것처럼 보입니다. 개념을 아는 것은 좋지만 실제 작업을 수행하는 데있어 개념을 적용하는 데 어려움을 겪는 것 같습니다.
코드 검토는 매우 도움이되었지만 코드 검토의 문제점은 사실 이후에만 발생하므로 일부는 방금 작성된 코드를 다시 작성하는 것입니다 (주로 리팩토링이지만 여전히 많은 시간이 걸립니다). 또한 코드 검토는 전체 팀이 아닌 개별 엔지니어에게만 피드백을 제공합니다.
프레젠테이션 (또는 시리즈)을 수행한다는 아이디어를 가지고 놀면서 더 잘 작성되고 리팩토링 될 수있는 기존 코드의 예와 함께 OOP를 다시 시도하려고합니다. 아무도 더 이상 소유하지 않은 오래된 프로젝트를 사용할 수 있으므로 적어도 그 부분은 민감한 문제가되어서는 안됩니다. 그러나 이것이 효과가 있습니까? 내가 말했듯이 대부분의 사람들은 C ++을 오랫동안 해왔 기 때문에 내 추측은 a) 왜 내가 이미 알고있는 것들을 말하고 있는지 왜 생각하는지 앉아있을 것입니다 .b) 그들은 실제로 모욕으로 생각할 수 있습니다 그들에게 그들이 수십 년이 아니더라도 몇 년 동안 해왔 던 일을 어떻게해야할지 모른다고 말합니다.
코드 검토보다 더 많은 잠재 고객에게 도달 할 수있는 다른 방법이 있지만 동시에 처벌 강의처럼 느껴지지 않습니까?
나는 완벽하게 설계된 코드의 유토피아 적 이상을 가진 대학에서 신선한 아이가 아니며 다른 사람으로부터 그것을 기대하지 않습니다. 제가이 글을 쓰는 이유는 종이에 실제로 고급 디자인을 한 사람을 검토했기 때문입니다. 그러나 클래스를 A-> B-> C-> D로 묘사하면 코드 B, C 및 D는 거의 동일한 공용 인터페이스를 구현하고 B / C에는 하나의 라이너 기능이 있으므로 최상위 클래스 A가 절대적으로 수행됩니다. 모든 작업 (메모리 관리, 문자열 구문 분석, 설정 협상 ...)은 주로 4 가지 몽고 방법으로 이루어지며 모든 의도와 목적을 위해 거의 직접 D로 호출합니다.
업데이트 : 저는 기술 책임자 (이 역할에서 6 개월)이며 그룹 관리자를 전적으로 지원합니다. 우리는 매우 성숙한 제품을 개발하고 있으며 유지 보수 비용이 확실히 알려지고 있습니다.