Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1주차] Clean_Code_1-2장_김현수 #4

Closed
find11570 opened this issue Jun 1, 2024 · 5 comments
Closed

[1주차] Clean_Code_1-2장_김현수 #4

find11570 opened this issue Jun 1, 2024 · 5 comments

Comments

@find11570
Copy link
Contributor

find11570 commented Jun 1, 2024

이슈 1(팀원의 관점). 클린 코드를 작성해야 할 필요성을 항상 느끼지만, 기존 진행되던 프로젝트에 투입된 상황에서는 막상 적용하기 쉽지 않다.
팀간 조화와 본인이 추구하는 방향이 맞지 않을 때 어떤 것을 더 우선시 해야할까?

이슈 2(리더의 관점). 클린 코드는 많은 장점도 있지만, 몇몇 단점도 있다.
비관적으로 생각하면 짧은 데드라인에 다들 생각하는 견해의 차이나 추상화/일반화의 범위를 조율해 나가야하기 때문에 사실 항상 클린 코드를 작성하기는 현실적으로 어려운 것이 사실이다. 결과론적을 중시하는 사회에서 과정 중심을 주장하기란 쉽지 않다.
본인이 PM이나 PL이 되어 타이트한 프로젝트를 진행한다고 하였을 때 우선적으로 고려할 가치는 무엇인가?

@chuseok
Copy link
Contributor

chuseok commented Jun 3, 2024

공통 답변입니다.

협업에 있어서 시스템 설계, 규칙 정의, 코드 리뷰와 같이 기능 구현 이외의 부수적인 작업에 대한 시간의 비중이 더 큽니다. 나쁜 코드를 바로 잡지 않는다면 추후의 유지보수에서 나쁜 코드를 더 많이 양산하고 바로 잡는 시간 이상의 시간이 소요될 것으로 예상합니다. 그렇게 되면 결국 돌고 돌아서 유지보수 작업이 들어올 것이고 팀원들을 설득할 수 있는 방향으로 진행해야 할 것입니다.

@lee-JunR
Copy link
Contributor

lee-JunR commented Jun 3, 2024

이슈 1

  1. 기존 프로젝트에서도 클린 코드 원칙을 지키며 코드를 작성하기란 쉬운 것 이 아닌데 (신입의 신분으로) 래거시 프로젝트에 투입되었을 때는 더더욱 어려움이 많을 것 같습니다.
  2. 끝없는 데드라인과의 싸움에서 저라면 1장의 보이스카우트 규칙만은 지키려고 할 것 같습니다.

코드는 처음 읽을때보다 더 깨끗하게 해놓고 떠나라.

  1. 한꺼번에 많은 시간을 투자할 필요는 없으며 조금 긴 함수 하나를 분할하고 중복을 제거하는 것으로 충분하다고 설명하고 있습니다.
  2. 물론 팀원들과의 견해차이와 규칙들을 세부적으로 조정할 시간도 없을 때도 많겠지만 개인적으로 가장 현실적인 방법이라는 생각이 드네요!

이슈 2

  1. 자신이 PM이나 PL이 됐는데 이러한 타이트한 프로젝트을 지속적으로 맡게된다면 해야할 것은 경영진들로부터 설득하는게 아닐까 싶습니다.
  2. 결과를 중시하는 사회이기에 클린코드나 코드리뷰와 같은 이상적인 문화들을 정착시키는 것이 쉽지 않겠지만 그렇기에 이러한 문화의 효능을 문서화하여 경영진을 설득하는 것이 가장 필요할 것 같아요!
  3. 생산성과 클린코드는 일맥상통이다. 이 가치를 포기할 순 없다는 걸 전제로 깔고 최대한 융퉁성 있게 프로젝트를 진행할 것 같네요!

클린 코드와 관련된 것은 아니지만 해당 질문과 비슷한 이슈의 답변을 본 영상이 있어 첨부합니다!
지속가능한 SW 개발을 위한 코드리뷰 :: 4월 우아한테크세미나
해당 영상의 FAQ 부분 (1:32:50) 입니다!

@kjy-asl
Copy link
Contributor

kjy-asl commented Jun 3, 2024

A1. 함께 프로젝트를 시작한 상황이 아닌 기존 진행된던 프로젝트에 투입된 상황이라면 기존 팀의 관행을 따라가는 것이 옳지 않을까요? 물론 좋은 방식이 적용되면 당연히 개선되고 좋겠지만 추구하는 방향이 다르다면 팀의 조화를 우선하는 것이 맞을 것 같다는 생각이 드네요.

A2. 사실 코드 규칙을 정하고 지키는 것도 중요하지만 극단적인 상황까지 생각하게 된다면 뭐가 됐든 클라이언트의 요구 사항이 가장 중요할 것 같다는 생각이 듭니다.

@GaHee99
Copy link
Contributor

GaHee99 commented Jun 3, 2024

1.클린 코드에 대한 조직적 정의가 필요할 것 같아요, 만약 중요하게 다뤄지고 코드리뷰나 피드백이 활발한(제 뇌피셜)조직이면 같은 생각을 공유하시는 분들이 많지 않을까욥.?
🤔 이에 대한 근거로 제가 성장하고자 하는 분들이 많은 곳에 취업하고 싶은 이유입니다..

  1. 이것도 마찬가지로.. 팀이 이해하고 있는 추상화 수준에 대해서 많은 차별점이 생길 것 같습니다.🤔

@cheongwonyoung
Copy link

  1. 우선은 팀간의 조화가 우선이라고 생각합니다. 기존 팀 분위기에 녹아든 후 설득해 나아가며 팀원들의 반감을 사지 않는 분위기에서 부분적인 리펙토링을 진행하면 좋을 것 같다고 생각합니다 !
  2. 일정에 지장이 가지 않는 선에서 지속적인 코드 리뷰가 필요하다고 생각합니다. 이를 통해 추후 나쁜 코드가 산처럼 쌓이는 일은 방지해야 합니다. 하지만, 이상적으로 생각했을 때는 그렇지만.. 만약 불가능한 상황이라면 일단은 일정을 우선시할 것 같습니다..

@GaHee99 GaHee99 closed this as completed Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants