better_mixed.log

“I like my code to be elegant and efficient. The logic should be straightforward and make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”
Bjarne Stroustrup, inventor of ‘C++
"저는 제 코드가 우아하고 효율적인 것이 좋습니다. 논리는 간단하고 버그를 숨기기 어렵게 만들어야 하며, 유지보수를 용이하게 하기 위해 최소한의 의존성, 명확한 전략에 따라 오류 처리가 완료되어야 하며, 사람들이 원칙 없는 최적화로 코드를 엉망으로 만들지 않도록 최적에 가까운 성능을 제공해야 합니다. 클린 코드는 한 가지를 잘 수행하는 코드 입니다.”

c++ 창시자는 클린코드를 유지보수와 디버깅에 용이하고 준수한 성능과 명확한 의도를 가진 코드 정도로 표현하였네요.

어려운 말을 좀 써보면 깨끗한 코드의 요소는 응집도, 단일책임, 추상화, SOLID 등등 여러 개념들이 있을 수 있을 겁니다.

근데 결국 일하면서 느낀 클린 코드는 내가 적은 코드에 의도를 담고, 그 의도를 다른사람으로 하여금 납득할 수 있게 하는 것 입니다.

너무 추상적이라구요? 어쩔 수 없습니다. 깨끗한 코드에 정답은 없으니까요.

그럼 도대체 왜 이 글을 쓰냐고 물으실 수도 있을 것 같네요. 다음 단락으로 넘어 가보겠습니다.

Why?

많은 개발자들이 말로는 "클린 코드가 중요한건 알지~" 라고 합니다. 좀 찔리시죠?

클린 코드는 추상적이고 머리가 아픕니다. 내 코드가 냄새난다고 지적을 받으면 속이 울렁거리고 머리가 어지럽습니다.

왜 우리는 굳이 힘들게 깨끗한 코드를 써야할까요?

그건 우리가 함께 일하기 때문입니다.

전 죽을때까지 평생 혼자서만 일한건데 깨끗한 코드를 작성해야 하나요?

네, 그렇습니다.

도서 Clean Code에서 로버트 마틴 아저씨가 남긴 좋은 말이 있습니다.

"유지보수 하기 쉽게 코드를 작성하고 코드에 의도를 담아라. 6개월 뒤에 그 코드를 다시 보는 사람은 아주 높은 확률로 너다."

우리는 항상 과거의 나와 싸워야합니다. "과거의 나"는 나와 협업 하는 아주 짜증나는 동료입니다.

요구사항이 늘어나고, 앱이 커지고, 냄새나고 누덕누덕한 더러운 코드에서 엄청난 양의 에러가 쏟아져 나올 것입니다.

사람들은 얼른 버그가 없어지고 새로운 기능이 원할히 동작하기를 바랍니다. 그럼 어떻게 되냐구요? 결국엔 내가 싼 똥을 내가 치우러 가야겠죠.

결국 우리는 미래의 나를 위해서라도 깨끗한 코드를 쓰도록 노력해야합니다.

물론 항상 깨끗한 코드에 강박에 갇혀서 살아갈 수는 없습니다. 그렇지만 깨끗한 코드를 추구하는 개발자와 그렇지 않은 개발자는 다릅니다.

말만하고 아무것도 고려하지 않는 게으른 개발자는 발전없이 머무를 뿐입니다.

결국 클린코드는 비단 깨끗한 코드 그 자체를 넘어 개발자의 마인드셋과 직결되는 문제입니다.

즉, 내가 더 좋은 개발자가 되기위해, 옆자리에서 나는 코드 냄새에 페브리즈를 뿌려버릴 수 있는 사람이 되기위해 우리는 클린코드를 지향해야합니다.

How?

앞서 너무 추상적인, 마인드적인 내용만 담았네요.

사실 클린 코드를 쓰는 방법론은 구글, 유튜브, 도서에 너무나도 많습니다. 아무리 클린코드에 대해서 검색해도 대부분 그런 내용들 뿐입니다.

의미있는 이름을 쓰고, 의도에 맞게 분리하고, 여러 패턴을 사용해서 의존성을 관리하고 등등

이 글에서는 그런 내용들을 담지 않으려고 합니다. 방법론적인 내용보다 많은 개발자들이 좀더 쉽 게 행동할 수 있게 하고 경각심을 깨워주는 글이 되었으면 합니다.

여러분은 깨끗한 코드를 쓰기 위해 어떤 노력을 하고 계시나요? "깨끗한 코드가 뭐죠? 그거 어떻게 써야하는거죠?" 그저 묻고만 돌아다니시진 않으셨나요?

클린코드를 위한 첫 걸음은 Action 입니다.

담대하게 기존 코드를 수정하기

두려워 하지말고 기존 코드를 씹고 뜯고 맛보고 즐기자

Toss Slash 21 | 실무에서 바로 쓰는 Frontend Clean Code 세션에서 유림님이 남겨주신 클린코드를 위해 추천하는 첫번째 방법입니다.

"내일 고치지 뭐~" 말로만 하는 클린 코드는 아무런 의미가 없습니다. 어설퍼도 지금 당장 고치는 코드가 더 의미있습니다.

여러분에게 갑자기 부사수가 생겼다고 상상해봅시다.

BSS : "A님, 이 프로젝트 파악하려고 하는데 어디부터 보면 될까요?" YOU : "... 아..."

어떤가요? 지금 여러분이 적고있는 코드, 프로젝트에 만족스럽고 당당하신가요? 얼른 가서 코드를 박박 닦고싶은 의지가 생기지는 않나요?

더 많이 알려고 노력하라

글을 쓸때 누구는 2000단어만 쓸 수 있고 누구는 20000 단어를 쓸 수 있다고 생각해봅시다.

누가 더 글을 잘 쓸 수 있을까요?

누군가 어니스트 헤밍웨이에게 내기를 요청했다
"단어 여섯 개로 단편 소설을 지어서 사람들을 울릴 수 있다면 당신이 이긴 거요"
헤밍웨이는 내기에서 이겼다
For sale : baby shoes, never worn (아이 신발 팝니다. 한번도 안 신었어요)

정답은 6단어밖에 안쓴 헤밍웨이... 죄송합니다.

두번째로 중요한건 Knowledge 입니다.

우리는 컴퓨터 위에서 도는 프로그램을 작성합니다. 당연하게도 많은 개발자이 공부하는 CS 지식, 알고리즘, SW 방법론 등을 등한시 하면 안됩니다. 또한 개발자들끼리 공유하는 문화에 대해서도 깊은 관심을 가져야 합니다.

그저 말이 되고 읽히기만 하는 코드를 작성한다고 깨끗한 코드가 아닙니다.

위에서 말했던 유지보수와 디버깅에 용이하고 준수한 성능과 명확한 의도를 가진 코드를 쓸 수 있도록 더 많은 컴퓨터 지식과 개발자들과 소통하는 방법을 탐구해야 합니다.

나한테만 클린코드?

아무리 의도를 담고 노력해도 내가 쓴 코드가 나한테만 잘 읽히면 아무 의미가 없습니다.

이분도 사실 글에 자기가 담고 싶은 의도를 잘 담았다고 생각하실 수 있습니다.

세번째로 중요한건 Open 입니다.

내 코드를 혼자만 읽으려고 하지 마세요. 나한테만 잘읽히고 깨끗하게 써진 것 같은 코드는 아무런 소용이 없습니다. 이런 상황이 계속될 경우 내 코드가 옳다고 박박 우기는 코드 독불장군이 되어버리기 쉽상입니다.

부끄러워도 누구에게든 공개하고 피드백을 받으세요. 내 코드를 구구절절 설명해보세요. 그 다음엔 구구절절 설명하지 않아도 이해할 수 있도록 코드를 수정해가세요.

클린코드에 정답은 없습니다. 상황에 맞는 더 나은 코드만 있을 뿐입니다.

은빛 탄환은 없다

No Silver Bullet – Essence and Accidents of Software Engineering 은빛 탄환은 없다 - 소프트웨어 공학의 본질속성과 우발성

"소프트웨어 개발의 복잡성을 일거에 해소할 마법(은빛 탄환 - 괴물 늑대인간을 마법처럼 잠재울 수단) 같은 방법은 없다" 는 유명한 말이죠.

깨끗한 코드를 한 번에 달성할 수 있는 방법 같은건 없습니다.

클린 코드는 코드에 내 의도를 담는 것 입니다. 여러 방법론들은 그걸 더 쉽게하는 도구일 뿐입니다.

계속해서 내 코드가 어떻게 더 잘, 더 쉽게 읽힐 수 있는지 고민해야 합니다. 내 코드를 보는 사람이, 내가 만든 코드를 이용하는 사람이 이해하기 쉽도록 계속 노력해야 합니다.

계속해서 코드에 의도를 담고 내 코드를 설득시키기 위해 필요한 시간을 줄여보세요. 어느새 향긋한 냄새가 나는 페브리즈 코드를 바라보며 흐뭇한 미소를 짓는 여러분을 볼 수 있을겁니다.

오늘은 많은 코드가 향긋해지길 바라면서, 제가 클린 코드를 바라보는 관점과 클린코드를 위한 3가지 방법에 대한 이야기를 해봤습니다.

쓰다보니 두서없이 글이 길어지게 됐네요. 여기까지 읽어주신 많은 분들께 감사를 전합니다.

다음번 글은 더 좋은 주제, 더 재밌는 글로 찾아뵙겠습니다.

가볍게 읽히며 바로 적용될 수 있는 글을 쓰려고 노력합니다. 좋아요와 날카로운 피드백은 글쓴이에게 많은 도움이 됩니다. @better_mixed

[Why?] 어느 웹개발자의 Why 시리즈, 그 첫번째 글 (0)

Sat, 07 Jan 2023 16:26:21 GMT

2년 정도 웹개발자로 일하면서 많은 개발자 취준생과 신입 개발자들을 만나왔다.

2023년도 되었겠다. 지금까지 생각만 하고 미루고있었던 글을 써보려 한다.

2022년이 나에게 다독의 해였던 만큼 여러권의 책을 읽고, 많은 개발자들과 이야기를 나누며 중요하다고 생각했던 것들은 하나씩 정리해서 출간해보려고한다.

"2년 따리가 뭘 알아?" 라고 생각하기 보단 "부족하거나 틀린 점이 있으면 내가 고쳐줘야지." 의 관점으로 글을 읽어 주시면 좋겠다.

Why?

왜?, 왜 그렇게 되는데?

내가 웹개발자로 일하면서 항상 가지고 있던 마인드셋이다.

지금까지 만나온 배울점이 많은 개발자들은 거의 모든 행위에 “그냥?” 은 없었다. 코드에 의도를 담고 이유를 찾는 것이 내가 가장 중요하다고 생각하는 소양이다.

그렇기에 지금까지 내가 생각했던 "왜?" 에 대한 이야기를 담을 생각이고, 내 동년배들은 왜 시리즈 제목이 Why? 인지는 잘 알 것이라고 생각한다.

지금 생각하고 있는 주제는 이정도이고 연재 주기는 1주에 하나 정도로 생각하고 있다. 위 주제들은 일단 적어놓은 것이고 순서나 진짜 다룰지의 여부는 아직 확정이 아니다.

첫번째 글은 2023년 1월 16일 즈음 올라갈 것 같다. 주제는 "클린코드" 로 정했다.

나는 프론트엔드 진영에서 일을 했기 때문에 프론트엔드 쪽으로 치우칠 확률이 있다고 생각한다. 그래도 최대한 웹개발 안에서 범용적으로 적용될 수 있는 개념들을 위주로 다뤄보려고 한다.

내 지식의 깊이가 얕기때문에 중간중간 너무 어려운 개념은 다루지 못하거나 그저 남의 말, 글등을 인용 정리하는 정도일지도 모른다.

부족하지만 다뤘으면 좋겠는 주제가 있다면 댓글로 남겨주면 참고해서 열심히 써보겠다.

For Whom?

생각보다 많은 개발자들이 사수가 없는 환경에서 일을 하고 있었고, 성장에 목말라 있기 보단 “성장” 이라는 단어를 두려워 하고 있다고 느꼈다.

개발자 혹은 더 좋은 개발자가 되기를 꿈꾸는 사람들을 위한 글이 될 것 같다. 고독하고, 성장을 두려워하는 개발자들에게 미약하나마 힘이되는 컨텐츠를 목표로 하고있다.

이미 좋은 개발자인 사람들은 내 글을 읽고 콧방귀를 뀔지도 모른다. 내 생각과 경험을 토대로 작성하다 보니 부족하거나 틀린점도 물론 있을 것이다. 이럴때는 대신 메가폰을 잡아줄 개발자분들도 모셔볼 생각이다.

"많은 성원 부탁드립니다. 개쩌는 개발자분들!" 다루고 싶은 주제가 있거나 관심있으신 분들은 언제든 편하게 연락주세요. 댓글, 인스타 @better_mixed ~~가능하다면 소정의 리워드도 제공하겠습니다.~~

더 많은 개발자들이 더 좋은 개발자가 되길 바란다.

How?

"내가 궁금했던 것이 이런 내용이었구나!" 정도를 목표로 하고 있기 때문에 아주 심도있다기 보다는 가벼운 내용으로 진행될 것 같다.

그래도 이 글만 보고도 적용을 해보거나, 도움은 되어야 하기때문에 예시 레포 혹은 코드를 무조건 첨부하는 형식으로 진행할 예정이다.

어렵고 심도있는 내용 보단 쉽고 실용적인 내용이 되길 바란다.

너무 노후화가 되지 않도록 피드백을 지속적으로 반영해서 유지 보수도 진행할 예정이다.

지금 까지 읽어주신 분들에게 감사드리며 많은 응원 부탁드립니다. (_ _)