회사 생활을 2년정도 하다보니 주변 사람들의 좋은 습관들이 많이 눈에 보인다.
내가 앞으로 더 나은 사람, 개발자가 되기 위해서는 어떻게 해야할지에 대해서 고민을 했을 때
주변 사람들의 좋은 습관을 훔치면 어떨까하는 생각이 들어서 좋다고 생각되는 모습들을 훔치고 내 것으로 만들어 보았다.
아래 작성한 것들 중에는 내것으로 만들어 실천하는 것도 있고, 방향성을 갖고 나아가는 것도 있다.
아직 내 것으로 만들지 못했더라도 나는 방향성을 잡았기 때문에 이미 좋은 습관을 가졌다고 생각하고 글을 작성해본다.
1. 리팩토링 할 때 주의 할 사항
프로젝트가 막바지를 향해갈 때 쯤 나는 리펙토링을 통해서 코드를 간결하게 만들었다.(내 생각)
그리고 어느날 부장님께서 잠시 부르시더니 세가지 케이스를 보여주시며 어떤게 제일 빠를 거 같은지 여쭤 보셧다
const a = 1;
const b = 2;
const c = 3;
const sum = (x,y) => x+y;
/* case 1 */
const case1 = 3;
/* case 1 */
const case1 = c;
/* case 1 */
const case3 = sum(a,b);
당연히 1, 2, 3 순으로 속도가 점점 느려진다고 답을 했고, 그걸 아는 애가 왜 이렇게 코드를 짯냐고 물어보셨다.
순간 얼어붙어서 어버버 하고 있으니, 내가 짠 코드를 같이 보면서 지적을 해주셨다.
/**
* 계속 호출되는 Function 들
*/
const scaleY = (d) => scale_Linear(d.product_qty) * infoScale;
const axisY = (d) => projection([d.lng, d.lat])[1] - (maxRadius[d.nation_cd] - scaleY(d));
const calCY = (d) => d.cy - maxRadius[d.nation_cd] - common_gap_Y(d);
const itemImageCY = (d) =>calCY(d) - d.circleSize;
const itemImageCX = (d) => d.cx + d.circleSize*0.55;
/**
* 위 Function을 반복해서 호출 함
*/
nationInfo
.append("circle")
.attr("r", (d) => d.circleSize)
.attr("cx", (d) => d.cx)
.attr("cy", (d) => calCY(d))
.attr("class", (d) => "amount-circle item-bg-" + d.item_grp_cd)
.style("fill", (d) => `url(#${d.item_grp_cd})`);
nationInfo
.append("circle")
.attr("r", (d) => 8)
.attr("cx", (d) => itemImageCX(d) )
.attr("cy", (d) => itemImageCY(d) )
.attr("class", (d) => "amount-circle item-bg-" + d.item_grp_cd)
.style("fill", (d) => `url(#${d.item_grp_cd})`)
.attr("fill-opacity", 0.9);
nationInfo
.append("image")
.attr("x", (d) => itemImageCX(d) - 6 )
.attr("y", (d) => itemImageCY(d) -6 )
.attr("width", (d) => 12)
.attr("height", (d) => 12)
.attr("xlink:href", (d) => contextRoot + "/static/images/item_" + d.item_grp_cd + ".png")
.attr("opacity", 0.8);
위 코드를 보면 동일한 값을 반복해서 함수로 호출을 하고 있다.
반복되거나 변경이 없는 것들은 상수처리를 해서 한번만 메모리에 저장한 다음 계속 호출을 하면 되는 것을 나는 계속 메모리를 낭비하는 코드를 작성했던 것이었다.
이 경험을 통해서 리팩토링을 너무 쉽게 생각했던 나 자신을 반성하고 두번 더 생각하고 코드를 작성해야겠단 생각을 하게되었다.
그리고 또 이와 유사하게 사용된게 없나 체크하였고, 수정을 하였다..
/**
* 위 nationInfo를 생성할 때 d3의 each() 메서드를 통해 루프를 돌며 값을 할당하는 부분이 있다. => (f_dataUpdate)
*
* f_dataUpdate를 loop 돌 때 반복되는 함수들을 미리 상수로 저장하여 이후에 실행되는 로직에서는 상수값을 사용하여 로직을 실행 횟수를 줄였다.
*/
let nationInfo = nationProdCanvas
.selectAll("g")
.data(nationData)
.each(f_dataUpdate)
...(중략)
2. 매일 작성하는 업무일지
지금은 퇴사한 사람이지만 그 사람을 통해서 기록의 중요성을 많이 깨달았다. 지금 이렇게 블로그를 하게 되는 것도 그 사람의 영향이 엄청 컸다. 그 사람은 매일 아침에 오늘 진행할 업무를 정리하고 업무 중에 만나는 문제점들을 모두 정리를 하였고 관리도 너무 잘하였다. 그 사람이 퇴사를 하게 된 것도 그렇게 관리한 블로그와 기록한 것을 보고 모 스타트업에서 스카웃 제의를 받았고 기존의 연봉의 두배 가까이 올려받으며 이직을 하였다.
내가 업무 일지를 작성하게 된 계기 중에는 물론 이직을 잘 하기 위함도 있지만, 실제로 업무 일지와 직면한 문제를 작성해나가면서 느끼는 점은 업무 시 길을 잃지 않고 나중의 나를 위해 좀 더 열심히 정리하고 기록하기 위해 꼼꼼하게 알아보려고 노력한다는 점이다.
요약하면 업무를 대하는 내 자세가 달라졌다. 좀 더 깊게 알기 위해 노력하고 알게된 내용을 명확하게 정리하려하고 해야할 업무를 정확하게 파악하게 되어 능률이 향상되었다는 점이다.
이 습관은 모두가 가졌으면 하는 아주 좋은 습관인것 같다.
3. 가끔은 잘 몰라도 자신있게
이 사람은 참 대단하게 잘 모르지만 아는 것 처럼 말로 사람을 홀리는 재주가 있다. 그런 모습은 나에게는 없어서 조금은 닮고 싶었다.
고객을 상대할 때 고객에게 우리는 프로이기 때문에 잘 몰라서 어버버 대는 모습을 보여주게 되면 신뢰를 잃을 수 있기 때문에 잘 몰라도 항상 자신있는 모습을 보여주는게 중요하다고 생각이 든다.
이 역량을 기르기 위해서 부장님이 질문 하실 때 가끔 아는 척 하고 자신있게 밀어 붙였다가 틀려서 혼나기도 했지만 ㅋㅋㅋ 그래도 한번씩 나를 위한 건강한 반항(?)은 계속 이어갈 예정이다.
4. 확실하다면 강하게 어필하기
이건 부장님을 보면서 많이 배우게 되었다. 부장님은 고객과 이야기를 할 때 항상 자신 있는 모습을 보여주며 되는 것과 안되는 것을 확실하게 이야기 하신다.
부장님과 함께 일하는 사람으로서 부장님이 가능하다고 생각하는 것에 대해 개발을 하다보니 많은 고마움을 느낀다.
하루는 어떻게 부장님은 이렇게 고객들에게 명확하게 이야기를 할수 있는지 여쭤본 적이 있다. 그러자 “안되는 걸 안된다고 이야기하고 다른 방향으로는 이런 방법이 있다 라며 대안을 제시 해주면 고객도 뭐라할 말이 없다“고 답변하셨다. 너무 당연한 말인데 그걸 당연하게 만든 것은 부장님이 확실한거에 대해서는 강력하게 임펙트있게 이야기를 해주시기 때문이라고 생각한다.
5. 회의록은 간단명료 & 확인메일
이건 이전 회사를 다닐 떄도 되게 중요하고 기본적인 요소였다. 회의 후에는 항상 recap을 작성하여 메일로 공유를 하였다. 공유를 하면서 상이한 부분에 대해서 꼭 수정을 요청을 하곤 했었다. 그리고 이러한 recap 문화가 너무 잘 잡혀있었다.
하지만 이번 회사의 경우 비교적 편안한 분위기여서 그런지 recap이 필수적인 분위기가 아니었다. 그래도 부장님은 항상 고객과 회의 후 항상 recap 메일을 보내고 고객들에게 상이한 부분을 컨펌 받았다. 그리고 이러한 메일을 보내는 것에 대해 경영진 분들도 "너희 부장님이 우리 회사에서 제일 메일 깔끔하게 잘 보내고 협의를 잘하는 사람이니 꼭 메일을 정독하고 배워라" 고 말씀을 하셨다.
확실히 부장님이 작성하신 메일을 보면 핵심을 명확하게 서술하고 각 업무 별 담당자까지 작성을 하셨다. 난공불락 이라는 말이 절로 떠오르게 만드는 메일이었다.
