개발자의 코드관리에 대한 나쁜 습관

 

 

 

 

 

 

사소한 버그는 나중에 고칠게요~

사소한 버그가 일으키는 나비효과 후폭풍이 크다.

바로바로 고치자

 

 

코드는 짧은게 최고지!!

간결하지만 가독성이 낮다면 오히려 안좋다.

가독성을 해치지 않는 선에서 간결하게 만들자.

나 혼자만 보는 코드가 아니기 때문에~!

 

 

최적화에 미친자

웹사이트 크기를 줄이는 것이 현재 얼마나 필요한지 다시 한 번 더 생각해보자.

크기를 줄이는 데에 집중하기 보다 더 중요한 요구사항은 없는지?

최적화는 프로젝트 마지막에 신경써주면 된다.

왜냐하면 요구사항이 중간에 바뀌게 되면 이전에 신경써주었던 최적화는 무용지물이 되어버리기 때문.

 

 

너무 이른 최적화는 만악의 근원이다 
- <컴퓨터 프로그래밍의 예술>의 저자 도널드 커누스 -

 

 

 

코딩 스타일이 꼭 필요한가? 나는 나의 개성대로 코딩한다!

코딩 스타일을 지키지 않으면 유지보수가 어려워진다.

정확한 가이드라인을 따르지 않는다면 미래의 내가 현재의 내 코드를 알아볼 수 없는 상황도 벌어진다.

 

 

내 맘대로 변수명 짜야지~~

코드 내의 다른 변수/함수와 구분되는 정보를 이름으로 담으면 가독성이 확실히 올라간다.

이름만 잘지어도 코드를 알아보는데 걸리는 시간을 1시간에서 10초로 줄일 수 있다.

 

 

개발자 툴과 IDE사용법 미숙..

핫키, 단축키, 환경세팅은 생각보다 더 중요.

배우는데 얼마 안걸리니 반드시 초반에 숙지해두자.

이것들을 익힘으로서 코딩읜 context를 바꾸는게 중요.

툴과 IDE사용에 익숙해져야 비로소 코드 자체에 집중할 수 있게된다.

 

 

소신있게 하나의 개발자 툴킷만 사용?

개발 스타일에 따라 잘 맞는 IDE가 있다.

Vscode, Sublime text, Eclipse, Intellij등 좋은 IDE는 많고 특정 언어에 전문화된 IDE도 있다.

본인에게 잘맞는 IDE를 찾는 것도 관건!

 

 

소스코드 복붙 복붙 복붙

완전히 나쁜 습관이라 하기 힘들지만 코드 재사용 전에는 꼭 한번은 꼼꼼히 읽어보자.

안 읽고 복붙했을 땐 장애가 발생할 수 있다.

재사용코드를 읽어보는 것은 비슷한 문제 해결에 도움된다.

 

 

완벽한 라이브러리를 찾았다고 착각

예제 몇 개 보았다고 새 라이브러리를 마스터할 수 없다.

직접 써보고 분서하며 익혀야하는 것들이 많다.

 

 

나쁜코드는 절대 안돼!!

나쁜코드란, 프로젝트 마감일에 쫓겨 작동만 할 수 있도록 급조하여 만든 엉망인 코드

나쁜코드라도 빠르게 짤 수 있는 능력도 필요하기도 함.

실제로 현업에서는 자주 일어나는 일.

매우 바쁘나면 나쁜코드로라도 일단 작성하고 보자! 

기술적인 빛(Technical Debt)을 졌다고 생각하고 나중에 다시 체크해보면 된다.