규도자 개발 블로그

무슨 값들을 상수(constant)로 지정해야할까? 정답은 간단하다. 바로 프로그램 시작부터 종료때까지 바뀌지 않아야 하는 값들을 상수로 지정해야 한다. 보조기억장치에 있는 프로그램을 실행시켜 주기억장치인 메모리에 올라가면 그것은 프로세스가 된다. 이런 프로그램의 생애주기에 있어서 프로세스가 종료되기 전까지 같은 값을 갖고 있어야만 하는 것들, 그것을 곧 상수(constant)로 지정해야 한다. 어쩌면 같은 어플리케이션이라 할지라도 실행환경이나 작동환경, 그리고 작동 조건에 따라 값들이 달라질 수는 있다. 하지만 값이 달라질 수 있을 지언정 그 프로그램이 프로세스가 되어 종료되기 직전까지 같은 값을 갖고 있어야 하는 것이라면 상수로 지정해야 한다.

개발자라면 개발을 모르는 사람들의 탓을 해선 안 된다. ※일단 개발자와 비개발자가 협업하여 어떤 어플리케이션을 만들어야 한다는 상황을 가정한다. 개발자와 비개발자의 협업은 필연적이다. 어차피 세상 거의 모든 어플리케이션은 실세계의 반영일 뿐더러 개발자가 세상 모든 도메인지식을 습득할 순 없기 때문이다. 하지만 그렇게 개발자와 비개발자의 협업이 이뤄진다면, 그 과정에서 불협화음이 발생할 수밖에 없다. 서로 다른 세계를 보고 있는데 아무런 마찰이 없다는 것 자체가 어불성설이다. 그럼에도 불구하고 협업의 목적이 어플리케이션 개발이라면 개발자는 아무리 답답하다고 하더라도 비개발자의 탓을 해선 안 된다. 어찌보면 당연한 얘기를 왜 그렇게 구구절절 써놨나 했겠지만 예를 들어서 설명하면 어느정도 와닿을 것이다. 당신..

정책은 코드에 종속되어선 안 된다. (Policies should not be subordinate to the code.) 예전에 실용주의 프로그래머의 서평을 쓴 적이 있다. 거기에서 가장 깊게 와닿았던 부분이 정책과 코드에 대한 부분이었는데 사실 서평에도 써있다시피 실제 책에 나온 표현은 그냥 정책은 수시로 바뀐다 가 전부였다. 하지만 너무 포괄적인 문장이지 않은가. 해서 정책은 코드에 종속되어선 안 된다라는 의미로 혼자 받아들였고 또 실제 구현에 있어서도 굉장히 도움이 되는 말인지라 스스로에게 상기시키기 위해 포스트잇에 써서 모니터에 붙여놨는데 동료분도 굉장히 좋은 말인 것 같다고 말씀해주셨다. 그래서 많은 사람들이 보면 좋을 것 같아 조금 더 공개된 장소에 적어두는 것이다. 실용주의 프로그래머에 ..

내가 코드를 작성할 때 중요하게 생각하는 것이 있다. 정확성은 프로그램이 가져야할 필수요소이고 애초에 정확성이 없다면 프로그램으로서의 가치가 없으므로 딱히 강조하지 않겠다. 그밖에 중요하게 생각하는 건 바로 간결성과 가독성이다. 그 중에서도 특히 중요한 건 가독성이라고 생각한다. 코드는 결국 사람이 읽기 때문이다. 코드는 결국 다시 읽힌다. 그사람은 당신의 팀원일 수도, 또 당신 자신일 수도 있다. 만약 옛날에 무아지경으로 마구마구 작성해놓은 코드가 다시 필요하다고 할 때 마구잡이로 조사놓은 변수이름들과 코드를 보면 어떤 느낌일까. 예전의 당신이 원망스러워질 것이다. 나는 이러한 경험을 몇 번 겪고 나서 나만의 일정한 규칙을 정해서 변수를 작성하기 시작했다. 그 이후로는 다른 클래스나 다른 파일에서 어떠..

깨끗한 프로젝트 코드를 위한 규칙. 5S 깨끗하게 유지된 프로젝트 코드는 아무리 강조해도 지나치지 않다. 실제로 수많은 프로젝트들이 해당 프로젝트를 개발하는 것보다 유지보수에 더 많은 인력과 자원을 소모하게 되지 않는가. 깨끗한 코드와 디렉터리 구조로 프로젝트를 유지하기 위한 5S규칙은 아래와 같다. 정리(Seiri) : 적절한 명명법 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 한다. 전산화가 이뤄지지 않았던 시절에도 수많은 캐비닛과 파일철, 그리고 정리 규칙들로 수많은 문서들을 체계적으로 분류하여 쉽게 찾아낼 수 있었듯이 말이다. 정돈(Seiton) : ​ 단정함, 또는 체계화라고도 한다. 코드는 누구나 예상하는 위치에 있어야 한다. 당신이나 누군가가 찾는 것이 있을 때 이것은 응당 이곳에 ..

이 게시물은 스티브 맥코넬이 쓴 CODE COMPLETE2에 나온 내용이며 다른 사람들에게도 변수 이름의 중요성과 그 이름을 정하는 데 도움을 주기 위해, 그리고 나 자신도 필요할 때마다 참고하기 위해 쓴다는 것을 알린다. 피해야 할 변수 이름 다음은 피해야 할 변수 이름에 대한 몇 가지 가이드라인이다. 오해의 소지가 있는 이름이나 축약어를 피한다. 이름이 모호하지 않은지 확인한다. 예를 들면 FALSE는 일반적으로 TRUE의 반대말이며 "Fig and Almond Season"에 대한 축약어로는 좋지 않을 것이다. 유사한 의미가 있는 이름을 피한다. 프로그램에 해를 주지 않고 두 변수의 이름을 교환할 수 있다면 이름을 다시 만들 필요가 있다. 예를 들면 input과 inputValue, recordNu..

이 게시물은 스티브 맥코넬이 쓴 CODE COMPLETE2에 나온 내용이며 다른 사람들에게도 변수 이름의 중요성과 그 이름을 정하는 데 도움을 주기 위해, 그리고 나 자신도 필요할 때마다 참고하기 위해 쓴다는 것을 알린다. 표준 접두사의 장점 표준 접두사는 이름 규약이 갖는 일반적인 장점을 모두 제공할 뿐만 아니라 다른 장점도 제공한다. 매우 많은 이름이 표준화되어 있기 때문에 단일 프로그램이나 클래스에서 기억해야 하는 이름이 적어진다. 표준 접두사는 모호해지기 쉬운 이름 영역을 정확하게 만든다. min과 first, last, max사이의 정확한 구분은 특히 도움이 된다. 표준 접두사는 이름을 더욱 간결하게 만든다. 예를 들면 단락의 수를 나타내기 위해서 totalParagraphs대신 cpa를 사용할..

이 게시물은 스티브 맥코넬이 쓴 CODE COMPLETE2에 나온 내용이며 다른 사람들에게도 변수 이름의 중요성과 그 이름을 정하는 데 도움을 주기 위해, 그리고 나 자신도 필요할 때마다 참고하기 위해 쓴다는 것을 알린다. 상수 이름 상수 이름은 상수가 가리키는 숫자보다는 상수가 표현하는 추상적인 대상을 나타내야 한다. FIVE는 상수의 이름으로는 나쁜 이름이다(상수가 표현하고 있는 값이 5.0이든 아니든 상관없이). CYCLES_NEEDED는 좋은 이름이다. CYCLES_NEEDED는 5.0일 수도 있고 6.0일 수도 있다. FIVE = 6.0은 말도 안 된다. 마찬가지로 BAKERS_DOZEN은 잘못 지은 상수 이름이며 DONUTS_MAX는 좋은 상수 이름이다.

이 게시물은 스티브 맥코넬이 쓴 CODE COMPLETE2에 나온 내용이며 다른 사람들에게도 변수 이름의 중요성과 그 이름을 정하는 데 도움을 주기 위해, 그리고 나 자신도 필요할 때마다 참고하기 위해 쓴다는 것을 알린다. 열거형의 이름 열거형을 사용하면 Color_나 Planet_, Month_와 같은 접두사를 사용하여 해당 타입의 멤버가 모두 같은 그룹에 속한다는 것을 보장할 수 있다. 다음은 접두사를 갖는 열거형의 요소를 규명하는 몇 가지 예제다. 접두사 이름 규칙을 사용한 열거형을 작성한 예제 Public Enum Color Color_Red Color_Green Color_Blue End Enum Public Enum Planet Color_Earth Color_Mars Color_Venus E..

전의 게시물에서도 밝혔다시피 이 게시물은 스티브 맥코넬이 쓴 CODE COMPLETE2에 나온 내용이며 다른 사람들에게도 변수 이름의 중요성과 그 이름을 정하는 데 도움을 주기 위해, 그리고 나 자신도 필요할 때마다 참고하기 위해 쓴다는 것을 알린다. 불린 변수 이름 전형적인 불린 변수의 이름을 기억한다. 다음은 전형적으로 유용하게 사용되는 변수의 이름이다. done : 무언가 수행되었다는 것을 가리키기 위해서 done을 사용한다. 이 변수는 반복문이 수행되었거나 다른 연산이 수행되었음을 가리킬 수 있다. 무언가가 처리되기 전에 done을 거짓으로 설정하고 완료되고 난 후 참으로 설정한다. error : 오류가 발생했음을 가리키기 위해서 error를 사용한다. 오류가 발생했을 때 이 변수를 참으로 설정하..