해외 사이트의 좋은 글을 퍼와서 번역한 내용입니다. :)

특히 중요한 부분 위주로 변역하여 올린 내용으로, 이제 막 개발에 흥미를 붙이신 분들이라면 도움이 될 만한 습관들과 방법들을 정리해보았습니다.

(원 출처 : http://studyorcrytrying.tumblr.com/post/141574889807/general-always-comment-your-code-commenting-your)



좋은 개발자가 되기 위한 습관들


항상 코드에 주석을 달자.

코드를 만들면서 주석을 다는 것은 머릿속으로 생각을 정리하는 것 뿐 아니라, 다른 사람들이 코드를 읽었을 때 의미를 좀 더 분명히 할 수 있는 좋은 방법이 됩니다. 물론 줄마다 주석을 달 필요는 없지만, 특히 복잡한 로직이 포함될 경우에 주석은 코드를 파악하기 위한 좋은 습관입니다.


메소드와 함수들에 대해서는 기록하세요.
당신이 정의하고 만든 메서드에 대해 문서화하는 것은 프로그램 전체 구조를 추적하는데 있어 좋은 방법이 됩니다. 메소드 이름들을 리스팅하고, 어떤 인자를 Argument 로 갖는지, 어떤 동작을 통해 어떤 값을 반환하는 지는 프로그램 구조를 생성할 때, 각 작업 단위를 명확히 하는데 큰 도움을 줍니다.  또한 이는 프로젝트에 새로운 멤버가 프로젝트를 빨리 파악하는 데 큰 도움이 되기도 합니다.


당신만의 코딩 스타일을 확립하세요.

아마 처음 코딩을 시작할 때, 많은 코딩 스타일들이 레퍼런스 등을 통해 당신에게 유입될 것입니다. 괄호는 중구난방일 것이고, 불필요한 공간을 만들거나 변수 네이밍이 제각각일 수 있습니다. 경험을 통해 자신만의 코딩 스타일을 찾게 된다면, 코드를 빨리 파악하고 작성하는데 큰 도움이 될 것입니다.


사용하는 언어에 대한 Official 사이트를 알아두세요.

당신이 사용하는 C++, Android, Java 등등 언어에 대한 공식 웹 사이트를 알고 있다면 꼭 참조해서 알아보는 것이 중요합니다. 새로운 정보를 지속적으로 습득하는 것 뿐 아니라, 학습 자체를 하는 것에 있어서도 공식사이트가 갖는 공신력은 큰 영향을 가집니다.


당신만의 코드를 실험하세요.

이 부분은 코딩 스타일의 확립과도 일치되는 내용입니다. 만약 궁금하거나 실험해보고 싶은 부분이 있다면 얼마든지 도전해보세요! 새로운 기술을 적용하고 당신만의 프로그램을 당신만의 방법으로 최적화 해보는 것은 코딩 실력향상에 있어서 큰 도움을 줍니다. 심지어 당신의 선생님 / 사수가 당신을 최고의 코드를 만들게 인도하는 것보다도 더 큰 향상을 이루어낼 수도 있습니다.


당신이 한 작업을 디버깅하세요.

문제가 생겼을 시, 당신이 만들어낸 코드의 작업을 쭉 따라가면서 디버깅을 해보는 것은 좋은 습관입니다. 중간중간 작업의 단위를 나누어 디버깅을 하는 습관을 들인다면, 디버깅의 단위가 커져서 감당할 수 없게 되거나, 전체 모듈을 다시 코딩하는 불상사를 방지할 수 있습니다.




좋은 개발자가 되기 위한 초보 개발자들의 과제


출력 결과를 읽는 시간을 충분히 가지세요.

중요한 부분이나 중요한 결과가 도출되는 부분에서 만들어내는 프로그램의 출력 결과를 무시하는 경우가 많습니다. 이 부분을 읽는 것을 불필요하다고 여기지 마시고 충분히 관찰해본다면 내부 구동 원리를 파악하고 학습에 도움이 될 수 있습니다.


코드 상단에 당신의 문서라는 걸 명시해보세요. 
많은 IDE 들은 author와 문서의 description 을 기입하는 기능을 제공하고, 이는 프로젝트 협업 시 어떤 파일에서 어떤 의도로 당신이 설계했는지 파악하는데 도움이 될 수 있습니다.

변수 들에 대한 리스트 만들기
당신이 사용하는 중요한 변수들이 있다면 리스트를 만드세요. 프로그래밍은 복잡한 작업이고, 시간이 지날 수록 예전에 사용하던 당신의 코드, 그 중에서도 변수들은 까먹기 쉽습니다. 훌륭하게 네이밍 하는 것은 이를 도와주지만, 훨씬 더 효과적인 방법은 Document 화하여 기록해보는 것입니다. 구식적인 방법이라고 볼 수도 있겠지만 초보 개발자에게는 프로젝트를 진행하는 데 있어서 큰 도움이 될 수 있습니다.

코드를 복잡하게 만들지 마세요.

초보 개발자 티를 조금 벗은 개발자들이 많이 하는 실수입니다. 할당받은 양이 있다면 그 만큼에 대해서만 코드를 작성하세요. 현금 결제 시스템을 만드는 데 있어서 신용카드나 보너스 등까지 고려할 필요는 없습니다. 


좋은 개발자가 있다면 언제든 도움을 구하세요.

Stack Overflow 에 의존하는 것은 좋은 방법이지만, 실제 더 나은 개발자가 있다면 직접 배우는 것이 더 도움이 될 수 있습니다. 문제를 해결해주는 답변에 당신은 좋아요를 누르겠지만 이해했다고 확신할 수 있나요?


페어 프로그래밍은 좋은 코드 향상 방법입니다. 하지만...

페어 프로그래밍은 좋은 협업 방법이지만 당신이 당신의 몫을 충분히 할 때 의미가 있습니다. 그렇지 않고서는 이는 지루한 1대 1 코딩 과외가 될 뿐입니다. 파트너에게 코드 작성을 기대지말고 스스로 독자적인 코드를 만들고 토론할 수 있을 때 페어 프로그래밍은 의의를 갖습니다. 


마지막으로 강조하지만 당신만의 코드를 만들어보세요.

깃허브나 다른 훌륭한 파트너에 의존하지말고, 구글에서 코드를 복사하지말고 당신만의 코드를 만들어보세요.

어려우면 어려운대로 처음부터 코드를 작성해보는 것이 굉장히 중요합니다. 남의 코드를 가져다만 쓰는 것은 결국 한계를 드러내기 마련입니다.



상당히 좋은 내용들이 많습니다. :) 

방문해주시는 분들 읽고 도움이 될 수 있었으면 좋겠습니다.




 Java에서는 Static 변수의 Non static 초기화를 위해 Static Initializer를 지원한다.

이는 static final 변수를 주로 예외를 throw하는 함수의 return 값으로 초기화하는데 사용된다.


다음과 같이 사용하면 된다.


(ex)



public class Example {

private static final Lib val;

static{
Lib tmp = null;
try{
tmp = new Lib();
}catch(UnknownHostException e){
//생성자가 이 예외를 반환하므로 일반적인 방법으로는 선언과 동시에 초기화가 불가능하다.
}
}

}



 이는 Lazy Initialization 의 예시로, 이러한 테크닉을 이용하면 Lazy Instantiation 과 유사하게 디자인 패턴 내의 코드를 작업하는 데 있어서 유연성을 가져올 수 있다.


 위의 예제에서 val 이라는 멤버변수는 final 인데다가 static 변수이면서 유효한 Lib 형의 객체이다. 안전하면서도 효율적이다.

위의 코드는 심지어 Thread-safe 하기 때문에 멀티 스레드 환경에서도 문제 없다.

 또한 위의 주석에 설명이 달려있듯, 생성자 자체가 예외를 발생시키는 경우 위와 같이 바깥에서 Try Catch 로 감싸줌으로써 안전한 초기화가 가능하다.


 다만, 이런 형태에서 위의 변수 val, 즉, Static Initialized Variable 은 클래스로더에 종속되기 때문에, 매번 객체 생성 시, 서로 다른 클래스 로더에서 Static 코드 블록을 호출하게 된다. 


 만약 하고자하는 바가 싱글턴이거나, 외부 코드에 종속적이라면 추천되지 않는 패턴이다. (물론 그렇게 쓰이는 경우는 흔치 않다.)





RAII는 C++ 진영에서 자주 쓰이는 Idiom으로 자원의 안전한 사용을 위해서 객체가 쓰이는 Scope를 벗어나면 자원을 해제해주는 기법이다. 메모리 누수를 관리하는 효과적인 기법이며, 제대로만 사용하면 오히려 별도의 관리 모듈이 붙는 것보다 안정적이다.


이는 C++ 에서 자원을 얻을 때 초기화가 되어야 하며, 유효한 객체 형태가 반환되어야하는 것을 의미한다. 반대로 객체가 사라질 때에는 가진 자원을 전부 반환해야 하며 객체가 유효하지 않은 형태가 되어야 한다.


 그리고 이것은 C++ 의 메모리 누수를 관리하는 철학이며, 이를 Scope 단위로 관리하고자 한다.


 그렇기 때문에 C/C++ 과 같은 통칭 .NET 등에서 Unmanaged 라 불리는 언어들을 다룰 때에는 메모리를 사용하는 각 변수들의 유효한 Scope 를 정확히 파악하는 것이 아주 중요하다.


 heap의 자원은 명시적 해제 이전에 해제되지 않지만 Stack 변수의 경우 Scope를 벗어나면 Destructor가 호출되는 것을 이용한 것이다.


 Exception 등 Control Flow Breaking 시에도 RAII를 이용하여 자원관리를 할 수 있으며 C++의 제작단계에서 스트로스트룹이 finally를 굳이 고안하지 않은 이유이기도 하다.



물론 이러한 특성들이 많은 개발자들의 C++의 진입 장벽을 높이는데에 포인터와 같이 큰 몫을 차지하고 있기 때문에 C++11 등 모던 C++에서는 여러 가지 장치들을 통해 메모리를 관리해주려는 노력을 하고 있다.


'Programming Language > C&C++' 카테고리의 다른 글

Stdafx.h 란?  (0) 2018.09.25
[Old] C++Type Casting 정리  (0) 2018.09.25

+ Recent posts