튼튼발자 개발 성장기🏋️

소스를 볼 때면 "이 변수에 뭐가 담겨 있는겨?" 혹은 "이 함수는 뭐하는 겨?"혹은 "이 클래스는 뭐여?" 등과 같은 의문을 품곤 한다. 나의 소스건 남의 소스건 "개떡같이 이름 지었네.."라고 마음 속으로 한 마디 하고 열심히 코드분석을 시작한다. 네이밍이 말은 쉽지만 정말 어려운 부분이 될 수 있다. [읽기 쉬운 코드]를 작성하기 위한 첫 걸음이 아닌가 싶다. 항상 어떤 function, 변수, Object, DB field, table 등을 만들 때 네이밍에서 시간을 한참 잡아먹는다. 네이밍 센스가 없기 때문이다. 하지만 시간을 많이 들여도 괜찮으니 최대한 좋은 이름일 짓도록 투자해보는 것이 우리 모두가 이로운 일이 될 수 있다! 내가 취업한지 2년도 채 되지 않았지만 이런 경험이 가장 많다. "..

좋은코드라는게 참 말은 쉽다. 우아하고💃 효율적인👍 코드. 단순하고😄 직접적인☝️ 코드. 다른 사람이 고치기 쉬운 코드. 자고로 이런 코드를 짜려면 단호한 프로그래머가 되어야 한다!(?) Memory leak, Race conditional, 명명법의 일관성 등을 소홀히 하면 안된다. 아무리 가독성이 높고 우아한 코드임에 틀림없어도 테스트 케이스가 없으면 무용지물. (그래서 TDD가 중요한 것..!!!!🤔) 그래서 깨끗하고 좋은 코드를 보면 마치 영화보듯이 느낀다고....(ㄹㅇ?) 의외로 좋은코드는 명쾌한 추상화와 제어문으로 가득 차 있다고 한다. 사실 나는 개인적으로 제어문이 가득한 코드를 싫어한다. 그만큼 복잡하고 얽혀있다는 생각이 들기 마련이기 때문. 그래서 어떻게 해야하는데?😥 ☝️중복을 줄이자!..

[왜 Clean Code?] 로직을 기가 막히게 짜고, 문제해결 능력이 뛰어난다고 한들 해당 코드가 쉽게 읽히지 않는다면 그것은 좋은 코드일까? 약 9년 동안 코딩을 하면서 단 한 번도 "읽기 쉬운 코드"에 대해 생각해본 적이 없다. 대학생 때 까지만 해도 나는 다음 리스트를 만족하는 코드가 좋은 코드라고 생각했다. 예외 처리가 잘 된 코드 메모리를 절약한 코드 각 언어 특성을 잘 이용한 코드 운좋게 취업에 성공하고 "학생"이 아닌 "개발자"로서 꽃이 필 무렵 주석과 변수 혹은 Object 명, 함수명 등과 같은 네이밍 이야기를 할 수 있는 기회를 얻었다. 나의 팀장님께서는 이렇게 말씀 하셨다. "가장 좋은 코드는 주석이 없고 변수 명만 봐도 뭐하는 녀석인지 알 수 있는 코드야." 위 조건을 만족하면서 ..