[WebDev] Things You Should Never Do As A Software Engineer

 

Things You Should Never Do As A Software Engineer

---

Being Perfectionist

모든 것은 완벽하지 않다. 그래서 나는 “완벽한 코드”도 존재하지 않는다고 확신한다.

소프트웨어 개발은 반복적인 프로세스이다. 코드를 짜고, 테스트하고, 피드백을 받고, 리팩토링 하고, 이를 반복한다. 오늘 잘 동작하던 것이 내일 동작하지 않을 수 있다. 따라서 소프트웨어는 유연하고 변경하기 용이해야한다. (이것이 soft-ware 라고 불리는 이유이다!)

완벽을 추구하지 말라는 것은 아니다. 단지 너무 경직되고 복잡한 코드를 작성하지 않도록 주의해야 한다는 것이다.

전문가가 되는것은 완벽주의자가 되는 것과는 다르다. 항상 최선을 다하되, 현실적으로 가능한 최적의 상태를 유지하는 것을 의미한다.

 

“Please, give me some time to refactor!”

리팩토링은 이미 동작하고 있는 코드를 외부 동작의 변경 없이 재설계하는 과정이다. 리팩토링 없는 코드는 “코드 악취”를 유발하기 시작한다. 이것은 다른 개발자들이 이해하거나 활용하기 어려운 코드를 의미한다.

우리 개발자들 모두는 하나의 기능을 구현한 후에 리팩토링을 진행해야한다는 것을 모두 알고 있다. 문제는 비개발자들은 이런 상황을 신경쓰지 않는다는 것이다. “우리는 빠르게 성장하고 있는 회사입니다, 그러니 기능 개발에 먼저 초점을 두기를 바랍니다” 라는 요청을 받기도 한다. 그러나 곧 그 코드는 유지보수 되지 않을 것이고, “제발 리팩토링할 시간을 주세요!”라고 간절히 요청하게 될 것이다.

리팩토링을 위해서 추가적인 시간을 요구하지 말아라. 리팩토링을 너의 기능 구현의 한 과정으로 만들어라!

 

Misunderstanding what “legacy code” means

웹 개발 생태계는 빠르게 변화하기로 유명하다. Next.js 버전 10으로 만들었던 웹 프로젝트가 업무를 하기 시작했을 때는 새로운 기능과 성능 향상이 포함된 버전 11이 출시되었고, 바로 버전 10 프로젝트는 legacy 프로젝트가 되었다.

많은 사람들은 “레거시 코드”가 “낡은 코드”를 의미한다고 오해하지만, 그렇지 않다. “Working Effectively with Legacy Code”의 저자 Michael Feathers에 따르면, 레거시 코드는 테스트가 없는 코드이다. 만약 테스트할 수 없는 코드가 있으면, 이 코드는 리팩토링도 불가하다. 리팩토링이 불가하다면, 더이상 유지할 수 없다.

“old” Next.js 프로젝트는 사실 꽤 좋은 테스트 커버리지를 가지고 있었고, 모든 것이 잘 동작하고 있었다. 이는 “유지 보수가 잘 된 코드”이지 “레거시 코드”가 아니다. 제발, 새롭고 멋져보인다는 이유로 신규 툴을 쫒는데에 시간을 낭비하지 마라. 17년동안 유지되고 있는 Github가 여전히 Ruby on Rails라는 사실을 기억해라.

 

“Functional programming is the best!”

함수형 프로그래밍은 요즘 새롭게 떠오르는 트렌드이고, 많은 개발자들이 이를 사용하고 있는 것은 맞다. 하지만 그렇다고 해서 모든 곳에서 이것을 사용해야한다는 의미는 아니다.

예를들어, 만약 Flutter 프로젝트를 작업할 때, UI 레이어에서 함수형 프로그래밍을 사용하는 것은 좋은 생각이 아니다. UI 레이어에서 과도한 “순수 함수형” 코드는 불필요한 재렌더링으로 성능 문제를 야기할 수 있다. Flutter는 객체 지향 프로그래밍 스타일을 사용하도록 설계되어 있기 때문에, 그 방식에 맞춰서 사용해야 한다.

함수형 프로그래밍이나 다른 멋진 기법을 완전히 피해야 한다는 의미는 아니다. 같은 예시로, 함수형 프로그래밍이 적합한 비지니스 로직에서는 이를 사용할 수 있다. 중요한 것은 자신이 작업하는 컨택스트를 잘 인지하고, 상황에 맞는 적절한 도구를 선택해라.

 

Following the “best practices” blindly

클린 아키텍쳐, SOLID 원칙, DRY, KISS, YAGNI, TDD, BDD, CI/CD 등등, 소프트웨어 개발에는 수많은 best practices가 존재한다. 이런 원칙들은 좋은 의도로 만들어졌지만 이것들을 맹목적으로 따를 필요는 없다.

예를들어, TDD(Test-Driven Development)는 작성한 코드가 올바르게(예상대로) 동작하는지를 확신할 수 있는 훌륭한 방법이다. 그러나 Clojure 나 Python같은 REFL 친화적인 언어를 사용할때에는 모든 것에 대해 TDD를 적용할 필요가 없을 수도 있다.

TDD의 유일한 목적은 가능한 빨리 피드백을 받는 것이다. 만약 테스트 작성 없이 피드백을 받을 수 있다면, TDD를 사용할 필요가 없다. (그럼에도, 테스트는 작성해야한다!)

 

Struggling alone

많은 주니어 개발자들이 자신의 “문제 해결 능력”을 자랑하려는 것을 많이 보았다. 그들은 이미 다른 사람들에 의해 해결된 문제를 해결하기 위해 고군 분투 한다. 제발 그렇게 되지 마라. 바퀴를 다시 발명하지 마라.

세상에서 가장 위대한 마인드는 거인의 어깨 위에 서있는 사람들이다.

팀에서 일하기 시작하면, 경험이 더 많은 동료들로부터 많은 것을 배울 수 있다는 것을 깨닫게 될 것이다. 그들은 너의 “거인”이다. 그들에 어깨 위에 올라타서, 다시 땅으로 내려가는데에 시간을 낭비하지 마라. 이제 너의 목표는 더 높은 거인을 향해 올라가는 것이다.

 

Falling into the “flow”, without self-awareness

“flow”를 경험해 본 적 있는가? 이것은 업무에 완전히 몰입하고, 에너지가 넘치며 집중된 상태를 말한다. 프로그래머로서 “flow”에 빠지면 나는 단순히 매개체일 뿐 코드가 스스로 작성되는 것 처럼 느껴진다. 나는 단순히 그 영역 안에 있다고 할 수 있다.

하지만 조심해라. “너무 많은” 코드를 작성할 수 있다. 종종 “flow”에 빠져있을 때 오버 엔지니어링을 하고 있는 나를 발견한다. 나 뿐만이 아니다, “클린 코드”의 저자 Robert C.Martin 도 플로우 중에 생산성이 반대로 나오는 경험을 했다.

플로우를 의도적으로 깨기 위해, “뽀모도로 기법”을 사용하는 것을 추천한다. 이것은 25분동안 일하고 5분의 휴식을 갖는 방법이다. 이것은 집중력을 유지하고 번아웃을 피할 수 있도록 도와줄 것이다.

 

Not moving your body

소프트웨어 엔지니어로 일하는 것은 쉽지 않다. 몇 시간동안 컴퓨터 앞에 앉아서, 키보드를 두들기고, 화면을 응시해야한다. “몰입” 상태에 있을 때, 건강을 잃기 쉽다. 하지만 기억해라! 너의 건강은 어떤 것 보다도 중요하다. 만약 몸이 말을 듣지 않는다면 뇌는 쓸모가 없어진다.

30분 마다 몸을 움직여라(만약 뽀모도로 기법을 사용하고 있다면 25분도 좋다). 일어나서, 스트레칭하고, 산책을 하고, 물을 마셔라. 이것 또한 집중력을 유지하고 번아웃을 피할 수 있도록 도와줄 것이다.

 

Forgetting how fun it is to be a programmer

처음 코딩을 시작할 때, 흥미가 가득했다. 무언가를 만들고, 문제를 해결하고, 새로운 것을 매일 배워나갔다.

그러나 시간이 지나면서, 코딩하는 즐거움을 잊어버리기 시작했다. “클린 코드”를 짜고, “best practices”를 따르고, “어려운 문제”를 해결하는 것에만 너무 집중하고 있었다. 점점 더 자주, 다른 사람이나 다른 회사의 코드를 따라가느라 너무 바쁜 나머지 나만의 코드를 짤 수 없었다. 내 창의성은 어디로 갔는가!

항상 프로그래머로서 즐거움을 기억해야한다. 어렵다는 것을 알지만, 나만의 프로젝트를 만들고, 새로운 것을 배우고, 멋진 것들을 계속 만들면서 시간을 보내야한다. 직장에서도 너의 동료들과 흥미로운 새로운 기술에 대해 이야기하려 노력해라. 이것은 동기 부여도 되며 열정을 유지하도록 도와줄 것이다.

 

Being a “coder”, not a software engineer

“코더”와 “소프트웨어 엔지니어”는 다르다. “코더”는 코드를 짜는 사람이고, “소프트웨어 엔지니어”는 코드를 사용해서 문제를 해결하는 사람이다. “코더”가 되면 안되는 두가지 핵심 이유가 있다.

• “코더”는 미래에 AI로 대체될 것이다.(사실 이미 교체되고 있다!). 논란이 많다는 것은 알지만, 슬프게도 사실이다.
• 사람들은 너의 코드를 신경쓰지 않는다. 그들은 너가 그들의 문제를 어떻게 잘 푸는지에만 관심이 있다.

코드를 도구로 사용하는 “문제 해결사”가 되어라. 문제를 이해하고, 최선의 해결법을 찾고, 너의 코드를 사용해서 구현해라. 그것이 소프트웨어 엔지니어이다.

---

👩‍💻 Opinion

점점 주니어를 벗어나야하는 시기에 적절한 글을 마주쳤다.

당연한 것들이고 실무하면서 많이 느끼는 나의 생각들을 정리해놓은 글이 아닌가 싶을 정도로 나의 생각과 유사했다. 

특히 리팩토링 시간에 대해서 그렇다 :) 리팩토링을 위해 시간을 투자하기보다 구현의 과정으로서의 리팩토링을 가져가야한다는 글에 100% 동의한다.

그리고 무엇보다 마지막 말이 인상깊다. "코더"가 되지 말자는 다짐을 하고 있지만, "코더"가 되지 않고 "문제를 해결하는 사람"이 되어야 한다는 것은 내가 모호하게 느끼고 있었던 부분을 알맞게 정의해준 말 같다.

오늘도 즐거운 개발자의 덕목을 배우는 날이었다:)