나는 재미를 위해 코딩 프로젝트에서 작은 그룹의 사람들과 협력하고 있습니다. 조직적이고 상당히 응집력있는 그룹입니다. 내가 함께 일하는 사람들은 프로그래밍과 관련된 다양한 기술을 가지고 있지만, 일부는 과도한 전역 변수, 불충분 한 명명 규칙 및 기타 것들과 같이 오래되거나 완전히 잘못된 방법을 사용합니다. 작동하지만 구현은 좋지 않습니다. 그들의 경험이나 교육에 의문을 제기하지 않고 더 나은 방법론을 사용하도록 정중하게 요청하거나 소개하는 좋은 방법은 무엇입니까?
답변
그들이하고있는 일이 잘못되었다는 것을 깨닫게하는 질문을한다. 예를 들어 다음과 같은 질문을하십시오.
왜 이것을 전역 변수로하기로 결정 했습니까?
왜 그 이름을 주었습니까?
그 흥미 롭군요. [이유가 더 좋은 이유를 삽입하십시오]
그런 식으로 작동합니까? 나는 보통 [당신이 어리석게 보이게 만드는 방법을 삽입하십시오]
나는 이것에 대한 이상적인 방법은 왜 그들이 특정 방식으로 코딩하는지 미묘하게 묻는 것이라고 생각합니다. 다른 방법에는 이점이 있다고 생각할 수도 있습니다. 코딩 스타일의 이유가 잘못된 정보로 인한 것이라는 것을 알지 못하면 타당한 이유없이 내 길을 더 나은 것으로 판단하지 않을 것입니다. 이 문제를 해결하는 가장 좋은 방법은 그들이 왜 그렇게 선택했는지 물어 보는 것입니다. 그것이 그들의 능력이 아니라 공격해야하기 때문에 그들의 추론에 관심을 갖도록하십시오.
코딩 표준은 확실히 도움이 될 것입니다. 그러나 모든 소프트웨어 프로젝트에 대한 해답이라면 천국의 개인 섬에서 칵테일을 마시고 있습니다. 실제로, 우리 모두는 문제가 발생하기 쉽고 소프트웨어 프로젝트는 여전히 낮은 성공률을 가지고 있습니다. 문제는 컨벤션 문제가 아닌 개인의 능력에서 비롯된 것이라고 생각합니다. 따라서 문제가 추악한 머리를 키울 때 그룹으로 문제를 해결하는 것이 좋습니다.
가장 중요한 것은, 자신의 방식이 더 좋다고 즉시 가정하지 마십시오 . 실제로는 그렇습니다. 그러나 우리는 다른 사람의 의견을 다루고 있으며 그들에게는 단 하나의 해결책이 있습니다. 그들이 당신을 잘난 척하는 사람으로보고 싶지 않다면 당신의 길이 더 좋은 방법이라고 말하지 마십시오.
답변
코드 검토 또는 페어 프로그래밍을 시작하십시오.
팀이 그러한 목표를 달성하지 못하면 매주 설계 검토를 시도하십시오. 매주 한 시간 동안 만나 코드 조각에 대해 이야기하십시오. 사람들이 방어적인 것처럼 보이면 적어도 처음에는 더 이상 감정적으로 애착이없는 오래된 코드를 선택하십시오.
@JesperE :가 말했듯이 코더가 아닌 코드에 중점을 둡니다.
당신이 생각하는 것이 다르다고 생각하지만 다른 사람들은 그것을 똑같이 보지 못한다면, 그것을 지적하는 대신 결함으로 이어지는 질문을 시작하십시오. 예를 들면 다음과 같습니다.
Globals :이 중 하나 이상을 원한다고 생각하십니까? 우리가 이것에 대한 접근을 통제하고 싶다고 생각하십니까?
Mutable state : 다른 스레드에서 이것을 조작하고 싶습니까?
또한 사람들이 휴식을 취할 수 있도록 내 한계 에 집중하는 것이 도움이됩니다 . 예를 들면 다음과 같습니다.
긴 기능 : 내 뇌는이 모든 것을 한 번에 수용 할만큼 크지 않습니다. 처리 할 수있는 작은 조각을 어떻게 만들 수 있습니까?
나쁜 이름 : 명확한 코드를 읽을 때 쉽게 혼란스러워합니다. 이름이 오해의 소지가 있으면 저에게는 희망이 없습니다.
궁극적으로 목표는 팀에게 더 나은 코딩 방법을 가르치는 것이 아닙니다. 팀에서 학습 문화를 확립하는 것입니다. 더 나은 프로그래머가되기 위해 각 사람이 다른 사람을 찾는 곳.
답변
코드 표준의 아이디어를 소개합니다. 코드 표준에서 가장 중요한 것은 코드베이스의 일관성에 대한 아이디어를 제안하는 것입니다 ( 이상적으로 는 모든 사람이 한 사람이 작성한 것처럼 보일 것임).
답변
왜 길이 더 좋은지 설명해야합니다 .
잘라 내기 및 붙여 넣기보다 기능이 더 나은 이유를 설명하십시오.
배열이 $ foo1, $ foo2, $ foo3보다 나은 이유를 설명하십시오.
전역 변수가 위험한 이유를 설명하고 지역 변수로 인해 삶이 더 쉬워 질 것이라고 설명하십시오.
단순히 코딩 표준을 사용하지 않고 “do do”라고 말하는 것은 프로그래머에게 그것이 왜 좋은지 설명하지 않기 때문에 가치가 없습니다.
답변
먼저 너무 빨리 판단하지 않도록주의해야합니다. 그럴만한 이유가있을 때 (예 : 이상한 규칙으로 레거시 코드로 작업) 일부 코드를 잘못된 것으로 쉽게 해제 할 수 있습니다. 그러나 그들이 실제로 나쁘다는 순간을 가정합시다.
팀의 입력에 따라 코딩 표준을 설정하도록 제안 할 수 있습니다. 그러나 좋은 코드가 무엇인지에 대한 비전을 강요하는 것이 아니라 그들의 의견을 고려해야합니다.
또 다른 옵션은 기술 서적을 사무실로 가져 와서 (Code Complete, Effective C ++, Pragmatic Programmer …) 다른 사람에게 빌려주도록 제안하는 것입니다 ( “안녕하세요. )
답변
가능하다면 자신이 아니라 자신의 코드를 비판하고 있음을 이해하도록하십시오 .
답변
대립하지 않는 방식으로 더 나은 대안을 제안하십시오.
“이봐, 나도 이런 식으로 작동 할 것 같아. 너희들은 어떻게 생각하니?” [화면에서 더 나은 코드를 만드는 제스처]
