다른 사람을 도울 때, 안되면 되게 하라

GIT이라는 걸 그냥 내 마음대로 만져보기도하고 이리저리 일반 클라우드마냥 썼는데, 이게 또 팀 프로젝트가 되니까 전부 master 에서 작업하는 것이 위험하다는 판단 아래 branch로 나눠 작업하자는 이야기가 있어 branch를 써봤다. 협업이라는 건 신경쓸게 많았다...

 

Branch에 관한 적확한 지식은 없지만, 여러 분기점을 맞아 갈라진 세계선(...)이라고 생각하고 있다.

'평행 세계'에서 일어난 일들을 원래의 세계선에 넣을지 아니면 버릴지.

그걸 그냥 합치면 중간에 충돌이 일어나는 파일이 있기 마련... 충돌 처리를 무서워하지 말자!!!

 

문제는 내가 생각하는 방식 외에 다른 방식으로 작업하다가 오류난 사람들이 도와달라고 했을 때,

'이걸 어떻게 해결해야하는가'

내가 상대방의 모든 작업 과정을 영상마냥 돌려볼 수도 없는 가운데, 어떤 방식으로 해결책을 제시해야하는가.

남을 도와줄 때마다 고민하게되지만, 매번 새롭다... 내가 한 방법과 똑같이 했다고 하는데 결과가 똑같지 않아서 난감.

어디까지 거슬러올라가야하는지 아찔 난감

 

1. 우선 상대방이 어떤 문제에 봉착했는지 확인해야한다. 

>진짜 대부분은 파일 오류. 단순 실수. 제일 빠른 건 원격. 

 

2. 구글선생님은 다 알고계셔

>그리고 스택오버플로우 선생님도 알고계셔....

https://stackoverflow.com/

Stack Overflow - Where Developers Learn, Share, & Build Careers

 

영어도 대부분 자주 사용하는 단어들이라 몰라도 읽을 수 있을 정도... 대부분의 오류는 영어라는 점도 정말 어찌보면 다행일정도... 코드적인 문제는 인터넷 찾아보면 다 나오게 되어있음.

 

하지만 이번 프로젝트 진행하면서 가장 크게 느꼈던 점은 "논리적 오류"를 범하지 말것.

구조적으로 얼마나 준비를 잘 해두었는가, 얼마나 열심히 깔끔하게 구상했는가.

이게 얼마나 많은 시간을 줄이고, 효율적인 코드를 짜는지 판가름하는 기준점이다.

구조를 짜는데 시간을 할애하자. 추후에 리팩토링 할 것을 생각하면서 짜자.

 

작업하는 중간에 이전 파일 들여다보는 습관이 좋은것같진 않은데, 자꾸 나도 모르게 한번씩 들여다보고 기함을 하게됨... 내가 왜 저딴식으로 짰지 ㅠㅠ 

제대로 된 프레임워크를 짜서 계속 리팩토링 했으면 좋겠다. 적어도 난 내가 짠 코드는 그렇게 굴렸으면 좋겠다.