시뻘건 개발 도전기

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

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