독서 시기 : 22.09.19 - ing
슬럼프 극복 겸 소프트웨어 엔지니어의 바이럴이라는 책을 충동구매했다. 페이지 당 도움이 되는 구절과 그에 대한 생각들도 적어볼까 하려고. 나는 여태 스타트업 개발을 주로 해왔기 때문에 굉장히 생존성 낮은 코드들, 유통기한이 짧은 코드를 주로 짜왔는데 구글이란 유지기간이 참 긴 소프트웨어 세계에서 어떻게 살아왔나 싶기도 해서.
p46 - 47.
「 다른 엔지니어들이 사용 중인 프로젝트를 유지보수하고 있다면 '동작한다'와 '유지보수 가능하다'를 구분 짓는 가장 중요한 요인은 바로 다음의 '하이럼의 법칙'일 것이다
하이럼의 법칙 : API 사용자가 충분히 많다면 API 명세서에 적힌 내용은 중요하지 않습니다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문입니다.
...
효율과 열역학을 논하려면 엔트로피의 법칙을 알아야 하듯이 시간의 흐름에 따른 변경과 유지보수를 논하려면 하이럼의 법칙을 알아야 합니다. 엔트로피가 절대 낮아지지 않는다고 해서 효율을 포기해서는 안 됩니다. 마찬가지로 소프트웨어 유지보수에 하이럼의 법칙이 적용된다고 해서 계획 세우기를 등한시하거나 소프트웨어를 덜 잘 이해하려는 노력을 포기해서는 안 됩니다. 」
이거에 대해서는 당장 개발 후 상용화 시기부터 느끼는 문제인 것 같다. 막상 애플에서 앱을 출시하거나 구글에서 비정상 종료/ANR 보고서를 받아보면 QC테스트까지 넘겨 완벽하다고 생각했는데 그렇지 않은 부분이 참 많이 보여서 .. 나는 이렇게 사용할 것이라 예상한 적이 없는데 사용자들은 이미 다른 방식으로 이것을 활용하고 있음을 인지하는 경우가 많은 것 같다. 그럼 이것에 대해 유지보수를 계획해야 하는 것도 응당 엔지니어의 일이겠지 ^-ㅠ
p55
「 주석 : 회귀 문제 - 제대로 작동하던 기능이 오작동하는 문제를 말하며, 일반적으로는 기능 추가, 리팩터링, 버그 수정 등 다른 목적으로 코드를 수정하는 과정에서 뜻하지 않게 발생합니다. 」
이건 내가 비전공자라 확실하게 몰랐던 단어 뜻을 알게 되고 간 느낌이라 ^-^
p66
「 우리는 서로 관련은 깊지만 상이한 두 용어인 '프로그래밍'과 '소프트웨어 엔지니어링'을 구별해야 한다고 생각합니다. 그 차이 대부분은 시간 흐름에 따른 코드 관리, 시간 흐름에 따른 규모 확장의 영향, 이런 관점에서의 의사결정 방식에 있습니다. 프로그래밍은 코드를 생산하는 즉각적인 행위입니다. 소프트웨어 엔지니어링은 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케 하는 정책, 관례, 도구 모두를 아우르는 종합적인 개념입니다. 」
두 가지 측면에서 늘 헛갈려 했는데, 나는 프로그래머에 가까운 것 같다.
p81.
「 협업의 열반에 들어가려면 가장 먼저 사회적 스킬의 '세 기둥'을 배우고 익혀야 합니다. 이 세 원칙은 그저 관계라는 톱니바퀴에 기름을 칠하는 정도가 아니라 모든 건강한 상호 작용과 협업의 초석이 되어 줍니다.
기둥 1: 겸손(humility)
당신과 당신의 코드는 우주의 중심이 아닙니다. 당신은 모든 것을 알지도, 완벽하지도 않습니다. 겸손한 사람은 배움에 열려있습니다.
기둥 2: 존중(respect)
함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해합니다.
기둥 3: 신뢰(trust)
동료들이 유능하고 올바른 일을 하리라 믿습니다. 필요하면 그들에게 스스로 방향을 정하게해도 좋습니다.
거의 모든 사회적 갈등의 근본 원인을 분석해보면 결국 겸손, 존중, 신뢰가 부족하여 일어났음을 알게 됩니다. 」
얼마전까지 개발자 커뮤니티에 이슈였던 '독성 말투(Toxic Tone)' 에 대한 것도 이의 연장선상이 아닐까? 커뮤니티 토의의 결과가 독성 말투의 결론은 팀의 붕괴, 와해였는데 이 독성 말투는 이 세가지를 완전히 반대로 실행하며 낳은 말투라고 생각한다. 이제 프로그래머들도 한 명만 유능한 시대가 끝났음을 인지하고 도래한 협업의 시대를 맞이할 준비가 되어 있어야 한다.
p100.
「 다만 엔지니어들이 너무 성급하게 '이건 잘못됐어!'라고 결론짓는 경향이 있습니다. 생소한 코드, 언어, 패러다임을 접했을때는 더욱 심하죠. 」
ㅎㅎ 나도 거의 비슷하게 그런 생각 하는듯. 유지보수 업을 맡으면 남의 코드가 생소해서 그냥 처음부터 만들어버리고 싶은 욕구가 생김..