Offcanvas

���������

블로그 | SW 개발과 관리, '관찰 가능성 도구'를 눈여겨볼 이유

혹시 레거시 소프트웨어를 떠올리면 메인프레임 같은 구식 기기에서 쓰이는 구닥다리 코드가 생각나는가? 다시 생각해보라. 몇 달 전에 쓴 코드도 개발자의 발목을 잡는 레거시 코드가 될 수 있다. 결국 코드의 관찰 가능성을 높이고 상세한 설명서를 남겨야 진짜 좋은 코드를 유지할 수 있다.    만약 레거시 소프트웨어가 자신과 무관한 다른 세계의 이야기라고 생각한다면, 다시 생각해보라. 아키타 소프트웨어(Akita Software) 창립자 겸 CEO 진 양은 “모든 코드는 쓰이는(ship의 뉘앙스와 크게 달라요) 순간 레거시 코드가 된다. 새로 짜는 모든 코드는 관리해야 하는 짐이 되며, 이는 불가피하다. 나도 지난주에 어떤 코드를 작성했는지 기억 못 한다. 대다수 개발자가 그럴 것이다”라고 말했다.  보통 어떤 소프트웨어를 레거시라고 부르려면 코볼(COBOL) 정도로 오래된 언어로 작성하거나, 메인프레임에서 구동되는 애플리케이션쯤 돼야 한다고 생각한다.  하지만 바로 이런 사고방식이 개발자가 코드를 근시안적으로 개발하는 원인이 된다. 나중에 그 코드를 이해해야 할 사람을 고려하지 않는 것이다. 양이 지적한 것처럼 개발자 스스로도 코드를 다시 이해해야 하는 상황이 올 수 있다.  그럼 어떻게 해야 레거시 코드를 잘 관리할 수 있을까?  코드가 네트워크를 만나면  코드의 까다로운 특성 중 하나는 바로 역동성이다. 코드는 절대 불변의 상태로 남지 않는다. 허니콤(Honeycomb) 창립자 겸 CTO 차리티 메이저스(Charity Majors)는 양과의 인터뷰에서 “코드가 네트워크에 들어서는 순간 신비의 세계에(mystery land)에 들어간다. 개발자의 통제권을 벗어나게 되는 것이다”라고 말했다.  이런 비유를 해볼 수도 있다. 개발자가 처음 개발한 애플리케이션은 마치 원시 상태의 에덴 동산에 있는 것과 같다. 그러나 유용한 애플리케이션 대부분은 대게 인터넷에 연결되는 데,...

레거시 시스템 레거시 소프트웨어 관찰가능성 디버깅

2022.07.29

혹시 레거시 소프트웨어를 떠올리면 메인프레임 같은 구식 기기에서 쓰이는 구닥다리 코드가 생각나는가? 다시 생각해보라. 몇 달 전에 쓴 코드도 개발자의 발목을 잡는 레거시 코드가 될 수 있다. 결국 코드의 관찰 가능성을 높이고 상세한 설명서를 남겨야 진짜 좋은 코드를 유지할 수 있다.    만약 레거시 소프트웨어가 자신과 무관한 다른 세계의 이야기라고 생각한다면, 다시 생각해보라. 아키타 소프트웨어(Akita Software) 창립자 겸 CEO 진 양은 “모든 코드는 쓰이는(ship의 뉘앙스와 크게 달라요) 순간 레거시 코드가 된다. 새로 짜는 모든 코드는 관리해야 하는 짐이 되며, 이는 불가피하다. 나도 지난주에 어떤 코드를 작성했는지 기억 못 한다. 대다수 개발자가 그럴 것이다”라고 말했다.  보통 어떤 소프트웨어를 레거시라고 부르려면 코볼(COBOL) 정도로 오래된 언어로 작성하거나, 메인프레임에서 구동되는 애플리케이션쯤 돼야 한다고 생각한다.  하지만 바로 이런 사고방식이 개발자가 코드를 근시안적으로 개발하는 원인이 된다. 나중에 그 코드를 이해해야 할 사람을 고려하지 않는 것이다. 양이 지적한 것처럼 개발자 스스로도 코드를 다시 이해해야 하는 상황이 올 수 있다.  그럼 어떻게 해야 레거시 코드를 잘 관리할 수 있을까?  코드가 네트워크를 만나면  코드의 까다로운 특성 중 하나는 바로 역동성이다. 코드는 절대 불변의 상태로 남지 않는다. 허니콤(Honeycomb) 창립자 겸 CTO 차리티 메이저스(Charity Majors)는 양과의 인터뷰에서 “코드가 네트워크에 들어서는 순간 신비의 세계에(mystery land)에 들어간다. 개발자의 통제권을 벗어나게 되는 것이다”라고 말했다.  이런 비유를 해볼 수도 있다. 개발자가 처음 개발한 애플리케이션은 마치 원시 상태의 에덴 동산에 있는 것과 같다. 그러나 유용한 애플리케이션 대부분은 대게 인터넷에 연결되는 데,...

2022.07.29

비주얼 스튜디오 2022 프리뷰 4 출시··· “개발자 생산성 향상”

비주얼 스튜디오 2022 IDE의 최신 프리뷰가 출시됐다. 이는 개인 및 팀 생산성 향상을 목표로 더 빨라진 검색 및 기타 UI 관련 성능 개선 등을 제공한다.  지난 9월 14일(현지 시각) 마이크로소프트 플래그십 IDE의 64비트 버전 프리뷰 4(또는 비주얼 스튜디오 2022 버전 17.0 프리뷰 4)가 공개됐다. 이는 비주얼 스튜디오 웹 사이트에서 액세스할 수 있다.    회사에 따르면 비주얼 스튜디오 2022 프리뷰 4는 개인 및 팀 생산성 향상을 목표로 이를테면 ‘파일에서 찾기(Find in Files)’와 같은 기능의 성능 개선에 초점을 맞췄다. 이에 따라 오차드 코어(Orchard Core) 애플리케이션 프레임워크 및 웹 콘텐츠 관리 등 대규모 솔루션 검색 시 그 속도가 3배 이상 빨라졌다고 마이크로소프트는 말했다. 또 C++ 인텔리센스 및 기호 데이터베이스 처리 성능이 향상됐다. 디버깅도 개선됐다. 예를 들면 개선사항 중 하나인 종속 중단점을 통해 개발자는 다른 중단점이 처음 발생한 후 트리거되는 추가 중단점을 구성할 수 있다. 그 결과 공통 경로(예: 게임 루프 또는 유틸리티 API)에서 코드를 디버깅하는 게 훨씬 쉬워졌다고 회사 측은 설명했다.  최신 앱 개발을 지원하기 위해 프리뷰 4에서는 블레이저(Blazor) 및 레이저(Razor) 편집기가 업데이트됐다. NPM GUI를 사용하면 누겟(NuGet) 패키지 다운로드와 동일한 방식으로 NPM 모듈을 다운로드할 수 있다.  또한 파일 저장 시 핫 리로드 및 CSS 파일에 변경사항을 실시간으로 적용하는 것을 포함해 ASP닷넷 코어(ASP.NET Core)에 핫 리로드를 지원하는 새로운 기능이 추가됐다. 다른 핫 리로드 개선사항에는 C++의 핫 리로드가 이제 씨메이크(CMake) 및 오픈폴더(OpenFolder) 프로젝트를 지원하고, 닷넷 마우이(.NET MAUI)용 XAML 핫 리로드 지원이 개선됐다.  마이크로소프트는 개발자가 ...

마이크로소프트 비주얼 스튜디오 개발자 소프트웨어 개발 생산성 디버깅 핫 리로드 통합개발환경 IDE

2021.09.17

비주얼 스튜디오 2022 IDE의 최신 프리뷰가 출시됐다. 이는 개인 및 팀 생산성 향상을 목표로 더 빨라진 검색 및 기타 UI 관련 성능 개선 등을 제공한다.  지난 9월 14일(현지 시각) 마이크로소프트 플래그십 IDE의 64비트 버전 프리뷰 4(또는 비주얼 스튜디오 2022 버전 17.0 프리뷰 4)가 공개됐다. 이는 비주얼 스튜디오 웹 사이트에서 액세스할 수 있다.    회사에 따르면 비주얼 스튜디오 2022 프리뷰 4는 개인 및 팀 생산성 향상을 목표로 이를테면 ‘파일에서 찾기(Find in Files)’와 같은 기능의 성능 개선에 초점을 맞췄다. 이에 따라 오차드 코어(Orchard Core) 애플리케이션 프레임워크 및 웹 콘텐츠 관리 등 대규모 솔루션 검색 시 그 속도가 3배 이상 빨라졌다고 마이크로소프트는 말했다. 또 C++ 인텔리센스 및 기호 데이터베이스 처리 성능이 향상됐다. 디버깅도 개선됐다. 예를 들면 개선사항 중 하나인 종속 중단점을 통해 개발자는 다른 중단점이 처음 발생한 후 트리거되는 추가 중단점을 구성할 수 있다. 그 결과 공통 경로(예: 게임 루프 또는 유틸리티 API)에서 코드를 디버깅하는 게 훨씬 쉬워졌다고 회사 측은 설명했다.  최신 앱 개발을 지원하기 위해 프리뷰 4에서는 블레이저(Blazor) 및 레이저(Razor) 편집기가 업데이트됐다. NPM GUI를 사용하면 누겟(NuGet) 패키지 다운로드와 동일한 방식으로 NPM 모듈을 다운로드할 수 있다.  또한 파일 저장 시 핫 리로드 및 CSS 파일에 변경사항을 실시간으로 적용하는 것을 포함해 ASP닷넷 코어(ASP.NET Core)에 핫 리로드를 지원하는 새로운 기능이 추가됐다. 다른 핫 리로드 개선사항에는 C++의 핫 리로드가 이제 씨메이크(CMake) 및 오픈폴더(OpenFolder) 프로젝트를 지원하고, 닷넷 마우이(.NET MAUI)용 XAML 핫 리로드 지원이 개선됐다.  마이크로소프트는 개발자가 ...

2021.09.17

비주얼 스튜디오 코드 1.53, 사용자 지정 가능한 검색 모드 지원

마이크로소프트의 오픈소스 코드 편집기 ‘비주얼 스튜디오 코드(Visual Studio Code)’ 최신 버전이 지난 2월 4일 공개됐다. 사용자 지정 가능한 검색 모드를 지원하고 자바스크립트 디버깅을 개선하는 등 새로운 기능 및 개선 사항을 제공한다.    2월에 발표되긴 했지만 2021년 1월 릴리스라고 칭하는 ‘비주얼 스튜디오 버전 1.53’은 이곳(visualstudio.com)에서 다운로드 받을 수 있다. 이번 릴리스에서는 search.mode 설정이 도입됐다.  이를 사용하면 ‘검색: 파일에서 찾기(Search: Find in Files)’, 탐색기의 ‘폴더에서 찾기(Find in Folder)’, ‘작업 공간에서 찾기(Find in Workspace)’ 컨텍스트 메뉴 항목과 같은 UI 검색 명령에 관한 옵션을 구성할 수 있다. 옵션은 다음과 같다.  • view: 사이드바 또는 패널의 검색 보기를 사용하여 검색한다.  • newEditor: 새 검색 편집기(Search Editor)에서 검색한다.  • existingEditor: 기존에 열려 있는 검색 편집기가 있는 경우 다시 사용하고, 그렇지 않으면 새 편집기를 만든다.  이전에는 키 바인딩을 편집해 기본 검색 UI를 구성하도록 권장했다. 이는 더 이상 필요하지 않으며, 이러한 키 바인딩은 해당 설정에 맞게 제거할 수 있다. 이 밖에 비주얼 스튜디오 코드 1.53의 새로운 기능 및 개선 사항은 아래와 같다.  • 자바스크립트 디버거에서 조건부 예외 중단점이 활성화된다. Node.js worker_threads 또한 지원된다.  • workbench.editor.wrapTabs 설정을 사용하면 스크롤 막대를 표시하지 않고 편집기 탭을 줄 바꿈 할 수 있다.  • 새로운 두 가지 설정을 사용해 편집기 탭에 깃(git) 상태 또는 진단과 같은 데코레이션을 표시할지 여부를 구성할 수 있다. workbenc...

마이크로소프트 코드 편집기 오픈소스 비주얼 스튜디오 코드 검색 모드 자바스크립트 디버깅 에밋

2021.02.08

마이크로소프트의 오픈소스 코드 편집기 ‘비주얼 스튜디오 코드(Visual Studio Code)’ 최신 버전이 지난 2월 4일 공개됐다. 사용자 지정 가능한 검색 모드를 지원하고 자바스크립트 디버깅을 개선하는 등 새로운 기능 및 개선 사항을 제공한다.    2월에 발표되긴 했지만 2021년 1월 릴리스라고 칭하는 ‘비주얼 스튜디오 버전 1.53’은 이곳(visualstudio.com)에서 다운로드 받을 수 있다. 이번 릴리스에서는 search.mode 설정이 도입됐다.  이를 사용하면 ‘검색: 파일에서 찾기(Search: Find in Files)’, 탐색기의 ‘폴더에서 찾기(Find in Folder)’, ‘작업 공간에서 찾기(Find in Workspace)’ 컨텍스트 메뉴 항목과 같은 UI 검색 명령에 관한 옵션을 구성할 수 있다. 옵션은 다음과 같다.  • view: 사이드바 또는 패널의 검색 보기를 사용하여 검색한다.  • newEditor: 새 검색 편집기(Search Editor)에서 검색한다.  • existingEditor: 기존에 열려 있는 검색 편집기가 있는 경우 다시 사용하고, 그렇지 않으면 새 편집기를 만든다.  이전에는 키 바인딩을 편집해 기본 검색 UI를 구성하도록 권장했다. 이는 더 이상 필요하지 않으며, 이러한 키 바인딩은 해당 설정에 맞게 제거할 수 있다. 이 밖에 비주얼 스튜디오 코드 1.53의 새로운 기능 및 개선 사항은 아래와 같다.  • 자바스크립트 디버거에서 조건부 예외 중단점이 활성화된다. Node.js worker_threads 또한 지원된다.  • workbench.editor.wrapTabs 설정을 사용하면 스크롤 막대를 표시하지 않고 편집기 탭을 줄 바꿈 할 수 있다.  • 새로운 두 가지 설정을 사용해 편집기 탭에 깃(git) 상태 또는 진단과 같은 데코레이션을 표시할지 여부를 구성할 수 있다. workbenc...

2021.02.08

앵귤러 11.1.0 출시··· 오류 코드 및 디버깅 가이드 추가

앵귤러(Angular) 버전 11.1.0 포인트 릴리스가 공개됐다. 이번 업데이트는 표준화된 오류 코드와 온라인으로 제공되는 오류 설명 및 디버깅 가이드를 추가했다.  자바스크립트 프레임워크 앵귤러 개발팀이 플랫폼에 표준화된 오류 코드 및 디버깅 가이드를 지원한다고 발표했다. 개발자가 문제를 더 빠르게 해결할 수 있도록 하는 한편 디버깅을 개선하기 위해서다.  오류 코드는 지난 1월 20일 공개된 앵귤러 11.1.0 릴리스에 적용됐다. 개발팀에 따르면 앵귤러 오류 메시지에는 이제 표준화된 오류 코드, 세부 정보, 형식이 포함된다.    구체적으로 설명하자면, 앵귤러 오류 메시지는 NG로 시작해 앵귤러 특정 오류를 타입스크립트 오류 및 브라우저 메시징과 구분한다. 그다음에 오는 숫자는 유형을 나타낸다. 런타임 오류는 0으로 시작하고, 컴파일러 문제는 1부터 9까지 기존 넘버 스페이스를 유지한다. 이는 개발자로 하여금 프레임워크 오류를 더욱더 쉽게 인지하고 검색할 수 있도록 하는 데 그 목적이 있다고 개발팀은 전했다.  또한 angular.io/errors 링크가 오류 메시지에 추가됐다. 여기서는 일반적인 오류에 관한 설명과 이를 디버깅하는 방법을 알려주는 동영상 가이드를 확인할 수 있다. 개발팀은 이제 일련의 앵귤러 디버깅 동영상을 유튜브에서 볼 수 있다고 언급했다.  현재 깃허브에서 다운로드 받을 수 있는 ‘앵귤러 11.1.0 포인트 릴리스’는 이 밖에 성능 개선, 컴퍼일러 및 언어 서비스 강화, 다양한 버그 수정 등을 지원한다. 한편 2021년 5월에 출시될 것으로 예상되는 ‘앵귤러 12’는 오류 메시징과 더불어 NPM에 아이비(Angular Ivy) 라이브러리를 배포할 수 있는 ng-링커(ng-linker)를 더욱더 개선할 계획이다. ciokr@idg.co.kr  

앵귤러 자바스크립트 프레임워크 오류 코드 오류 메시지 디버깅

2021.02.02

앵귤러(Angular) 버전 11.1.0 포인트 릴리스가 공개됐다. 이번 업데이트는 표준화된 오류 코드와 온라인으로 제공되는 오류 설명 및 디버깅 가이드를 추가했다.  자바스크립트 프레임워크 앵귤러 개발팀이 플랫폼에 표준화된 오류 코드 및 디버깅 가이드를 지원한다고 발표했다. 개발자가 문제를 더 빠르게 해결할 수 있도록 하는 한편 디버깅을 개선하기 위해서다.  오류 코드는 지난 1월 20일 공개된 앵귤러 11.1.0 릴리스에 적용됐다. 개발팀에 따르면 앵귤러 오류 메시지에는 이제 표준화된 오류 코드, 세부 정보, 형식이 포함된다.    구체적으로 설명하자면, 앵귤러 오류 메시지는 NG로 시작해 앵귤러 특정 오류를 타입스크립트 오류 및 브라우저 메시징과 구분한다. 그다음에 오는 숫자는 유형을 나타낸다. 런타임 오류는 0으로 시작하고, 컴파일러 문제는 1부터 9까지 기존 넘버 스페이스를 유지한다. 이는 개발자로 하여금 프레임워크 오류를 더욱더 쉽게 인지하고 검색할 수 있도록 하는 데 그 목적이 있다고 개발팀은 전했다.  또한 angular.io/errors 링크가 오류 메시지에 추가됐다. 여기서는 일반적인 오류에 관한 설명과 이를 디버깅하는 방법을 알려주는 동영상 가이드를 확인할 수 있다. 개발팀은 이제 일련의 앵귤러 디버깅 동영상을 유튜브에서 볼 수 있다고 언급했다.  현재 깃허브에서 다운로드 받을 수 있는 ‘앵귤러 11.1.0 포인트 릴리스’는 이 밖에 성능 개선, 컴퍼일러 및 언어 서비스 강화, 다양한 버그 수정 등을 지원한다. 한편 2021년 5월에 출시될 것으로 예상되는 ‘앵귤러 12’는 오류 메시징과 더불어 NPM에 아이비(Angular Ivy) 라이브러리를 배포할 수 있는 ng-링커(ng-linker)를 더욱더 개선할 계획이다. ciokr@idg.co.kr  

2021.02.02

'뜻밖의 선물'같은 팁··· '깃(Git)' 고급 명령어 5가지

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

개발자 커밋 디버깅 리포지토리 브랜치 머지 풀 리퀘스트 깃 리베이스 스쿼시 버그 코드 체리픽 서브모듈

2020.06.12

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

2020.06.12

'몰래 하는 맛' 비밀스럽게 즐기는 10가지 나쁜 프로그래밍 습관

엄마 몰래 쿠키를 먹고, 저녁에 와인을 다소 과하게 마시고, 요금 미터기 시간이 지난 다음에도 주차장에 차를 세워 두고, 급커브 구간을 너무 빠르게 돌아 나간 경험은 모두가 있을 것이다. 물론 프로그래밍의 기본적인 이런저런 규칙도 위반한다. 나쁜 행동이라는 사실은 모두가 알고 수긍한다. 그러나 비밀스럽게 그 나쁜 행동을 즐긴다. 우리는 좋은 프로그래밍 규칙을 조롱하는 나쁜 코드를 쓰고도 아무렇지도 않게 잘 살고 있다. 프로그래밍의 신이 내리는 벼락을 맞지도 않았고 책상이 폭발하지도 않았다. 사실 코드는 컴파일되어 이미 전달됐고 고객도 만족한 것 같다.    나쁜 프로그래밍은 예를 들어 전기 철조망을 혀로 핥거나 호랑이의 꼬리를 잡아당기는 수준의 행동은 아니기 때문이다. 대부분의 경우에는 아무 탈없이 넘어간다. 규칙이라 해도 위반 시 코드가 사망하는 엄중한 명령이 아니라 가이드라인 또는 스타일 제안에 가깝다. 물론 코드가 비웃음의 대상이 될 수도 있고 경우에 따라서는 공개적인 망신을 당하기도 한다. 그러나 규약에 저항한다는 사실은 이른바 사회적인 좋은 코드의 관습을 어기는 데서 오는 스릴을 느끼게 해준다. 게다가 때로는 규칙을 어기는 편이 더 좋을 때도 있다. (쉿!) 그렇게 나온 코드가 더 깔끔하고 더 빠르거나 간소할 수 있다. 규칙은 일반적으로 지나치게 광범위한데, 재주가 있는 프로그래머는 그 규칙을 어김으로써 코드를 더 개선할 수 있다. 상사에게 말하면 안 되지만 가끔은 자기만의 방법으로 코딩하는 편이 더 좋다. 무조건 지켜야 하는 확고한 규칙이라고 생각하는 사람들도 있지만, 실제로는 많은 프로그래머들이 자주 어기고 그 결과로 성공과 즐거움을 얻는 10가지 규칙을 살펴보자.   나쁜 프로그래밍 습관 1 : 베끼기 학교에서는 분명 잘못된 행동이다. 그러나 직장의 경우 명확하지 않다. 물론 훔치면 안 되는 코드 블록도 있다. 출처가 독점 코드인 경우, 특히 저작권 메시지까지 붙어 있다면 가져와서는 안 된다. 자기만의 코드를 ...

습관 프로그래밍 디버깅 함수 무한루프 연산자

2019.12.10

엄마 몰래 쿠키를 먹고, 저녁에 와인을 다소 과하게 마시고, 요금 미터기 시간이 지난 다음에도 주차장에 차를 세워 두고, 급커브 구간을 너무 빠르게 돌아 나간 경험은 모두가 있을 것이다. 물론 프로그래밍의 기본적인 이런저런 규칙도 위반한다. 나쁜 행동이라는 사실은 모두가 알고 수긍한다. 그러나 비밀스럽게 그 나쁜 행동을 즐긴다. 우리는 좋은 프로그래밍 규칙을 조롱하는 나쁜 코드를 쓰고도 아무렇지도 않게 잘 살고 있다. 프로그래밍의 신이 내리는 벼락을 맞지도 않았고 책상이 폭발하지도 않았다. 사실 코드는 컴파일되어 이미 전달됐고 고객도 만족한 것 같다.    나쁜 프로그래밍은 예를 들어 전기 철조망을 혀로 핥거나 호랑이의 꼬리를 잡아당기는 수준의 행동은 아니기 때문이다. 대부분의 경우에는 아무 탈없이 넘어간다. 규칙이라 해도 위반 시 코드가 사망하는 엄중한 명령이 아니라 가이드라인 또는 스타일 제안에 가깝다. 물론 코드가 비웃음의 대상이 될 수도 있고 경우에 따라서는 공개적인 망신을 당하기도 한다. 그러나 규약에 저항한다는 사실은 이른바 사회적인 좋은 코드의 관습을 어기는 데서 오는 스릴을 느끼게 해준다. 게다가 때로는 규칙을 어기는 편이 더 좋을 때도 있다. (쉿!) 그렇게 나온 코드가 더 깔끔하고 더 빠르거나 간소할 수 있다. 규칙은 일반적으로 지나치게 광범위한데, 재주가 있는 프로그래머는 그 규칙을 어김으로써 코드를 더 개선할 수 있다. 상사에게 말하면 안 되지만 가끔은 자기만의 방법으로 코딩하는 편이 더 좋다. 무조건 지켜야 하는 확고한 규칙이라고 생각하는 사람들도 있지만, 실제로는 많은 프로그래머들이 자주 어기고 그 결과로 성공과 즐거움을 얻는 10가지 규칙을 살펴보자.   나쁜 프로그래밍 습관 1 : 베끼기 학교에서는 분명 잘못된 행동이다. 그러나 직장의 경우 명확하지 않다. 물론 훔치면 안 되는 코드 블록도 있다. 출처가 독점 코드인 경우, 특히 저작권 메시지까지 붙어 있다면 가져와서는 안 된다. 자기만의 코드를 ...

2019.12.10

좋은 코드를 작성하고 있다는 징후 11가지

빌 소러는 윤리적 관점에서 스스로 부끄러움을 느낀 코드에 대한 좋은 글을 미디엄(Medium)에 올린 적이 있다. 그러나 기술적인 측면에서도 소프트웨어를 부끄러워해야 이유는 많다. 부끄러워하지 않을 소프트웨어를 나타내는 11가지 단어를 살펴보자. 사용하는 언어 또는 기술 스택이 무엇이든 코드를 다음 단어로 설명할 수 있다면 좋은 코드일 가능성이 높다. 자신의 코드에 몇 개나 적용되는지 확인해 보라. 1. 디버그 가능(Debuggable) 대부분의 현대 런타임에서는 일종의 디버거를 연결할 수 있다. Node.js조차 비주얼 스튜디오로 디버그할 수 있다. 언젠가 무슨 일이 벌어지는지 알아내야 할 때 디버거를 연결해야 한다는 생각을 갖고 코드를 써야 한다. 그 의미를 정확히 설명하기는 어렵지만 이렇게 하면 때로는 데이터의 구조를 설계하는 데 영향을 미치기도 한다. 구조를 파나갈 필요가 없도록 더 많은 임시 변수를 사용할 수도 있다. 다행히 대부분은 결과적으로 좋은 습관이다. 가장 좋은 시작 방법은 문제가 없을 때 디버거 사용을 연습하는 것이다. 단계별로 진행하면서 할당을 살펴보고, 잘못된 값이 있을 경우 어떻게 할지 생각해 보라. 2. 로그 가능(Loggable) 런타임에 연결해서 코드를 단계별로 진행하기 위한 현대적 디버거가 있다 해도 세상은 그렇게 돌아가지 않는다. 즉, 코드가 실행되는 환경은 다양하다. 서버리스일 수도 있고 멀티스레드 환경이거나 분산 환경 또는 어딘가의 클라우드에서 실행되는 경우도 있을 것이다. 이러한 환경에서 코드는 개발자가 컴퓨터에서 실행할 때와 다르게 동작할지도 모른다. 따라서 로그가 필요하다. 그 말은 로깅 프레임워크가 필요하다는 의미다. 코드를 쓰고 로그를 읽을 수 있도록, 또는 최소한 일종의 로그 리더에서 소화가 가능하도록 로깅을 설정해야 한다. 소프트웨어에 로그 기능을 넣어야 한다. 이 부분을 못할 경우 프로덕션 배포에서 프로덕션 문제를 디버그하기 위해 로깅 코드를 배포하는 상...

코드 문서화 디버깅 로그 프로그래머블 네트워크 멱등적

2018.04.17

빌 소러는 윤리적 관점에서 스스로 부끄러움을 느낀 코드에 대한 좋은 글을 미디엄(Medium)에 올린 적이 있다. 그러나 기술적인 측면에서도 소프트웨어를 부끄러워해야 이유는 많다. 부끄러워하지 않을 소프트웨어를 나타내는 11가지 단어를 살펴보자. 사용하는 언어 또는 기술 스택이 무엇이든 코드를 다음 단어로 설명할 수 있다면 좋은 코드일 가능성이 높다. 자신의 코드에 몇 개나 적용되는지 확인해 보라. 1. 디버그 가능(Debuggable) 대부분의 현대 런타임에서는 일종의 디버거를 연결할 수 있다. Node.js조차 비주얼 스튜디오로 디버그할 수 있다. 언젠가 무슨 일이 벌어지는지 알아내야 할 때 디버거를 연결해야 한다는 생각을 갖고 코드를 써야 한다. 그 의미를 정확히 설명하기는 어렵지만 이렇게 하면 때로는 데이터의 구조를 설계하는 데 영향을 미치기도 한다. 구조를 파나갈 필요가 없도록 더 많은 임시 변수를 사용할 수도 있다. 다행히 대부분은 결과적으로 좋은 습관이다. 가장 좋은 시작 방법은 문제가 없을 때 디버거 사용을 연습하는 것이다. 단계별로 진행하면서 할당을 살펴보고, 잘못된 값이 있을 경우 어떻게 할지 생각해 보라. 2. 로그 가능(Loggable) 런타임에 연결해서 코드를 단계별로 진행하기 위한 현대적 디버거가 있다 해도 세상은 그렇게 돌아가지 않는다. 즉, 코드가 실행되는 환경은 다양하다. 서버리스일 수도 있고 멀티스레드 환경이거나 분산 환경 또는 어딘가의 클라우드에서 실행되는 경우도 있을 것이다. 이러한 환경에서 코드는 개발자가 컴퓨터에서 실행할 때와 다르게 동작할지도 모른다. 따라서 로그가 필요하다. 그 말은 로깅 프레임워크가 필요하다는 의미다. 코드를 쓰고 로그를 읽을 수 있도록, 또는 최소한 일종의 로그 리더에서 소화가 가능하도록 로깅을 설정해야 한다. 소프트웨어에 로그 기능을 넣어야 한다. 이 부분을 못할 경우 프로덕션 배포에서 프로덕션 문제를 디버그하기 위해 로깅 코드를 배포하는 상...

2018.04.17

개발자 좌절의 순간들 '악몽 톱10'

잘 모르는 사람들은 개발자라는 직업이 꽤 편해 보일지도 모른다. 일자리도 많고, 연봉도 많이 받으며, 최근에는 각종 혜택까지 누리니 말이다. 그러나 개발자 역시 하나의 직업일 뿐이며, (그나마 몇 가닥 남지도 않은) 머리를 쥐어뜯고 싶은 순간들이 있게 마련이다. 온라인 포럼에서 현직 프로그래머들이 달아준 댓글과 투표를 통해 소프트웨어 개발자로 살면서 가장 힘든 일 10 가지를 꼽아 보았다. 이 글을 다 읽고 나서도 개발자가 되고 싶다면? 나중에 가서 왜 그때 안 말렸냐고 원망하지는 말길 바란다. ciokr@idg.co.kr

개발자 코드 애플리케이션 개발 프로그래머 디버깅 코더

2015.09.21

잘 모르는 사람들은 개발자라는 직업이 꽤 편해 보일지도 모른다. 일자리도 많고, 연봉도 많이 받으며, 최근에는 각종 혜택까지 누리니 말이다. 그러나 개발자 역시 하나의 직업일 뿐이며, (그나마 몇 가닥 남지도 않은) 머리를 쥐어뜯고 싶은 순간들이 있게 마련이다. 온라인 포럼에서 현직 프로그래머들이 달아준 댓글과 투표를 통해 소프트웨어 개발자로 살면서 가장 힘든 일 10 가지를 꼽아 보았다. 이 글을 다 읽고 나서도 개발자가 되고 싶다면? 나중에 가서 왜 그때 안 말렸냐고 원망하지는 말길 바란다. ciokr@idg.co.kr

2015.09.21

윈도우 8 충돌 원인 파악과 해결방법

모든 컴퓨터 운영체제가 그렇듯, 윈도우 8도 문제가 발생한다. 다행히도 대부분의 충돌의 원인을 진단하는 간편한 방법이 있다. 간단히 대부분의 윈도우 충돌의 흔한 원인인 말썽을 일으키는 서드파티 드라이브들을 진단해주는 윈도우 디버그 무료 툴인 WinDbg를 사용하면 된다. editor@itworld.co.kr

윈도우 8 오류 디버깅 충돌

2013.04.18

모든 컴퓨터 운영체제가 그렇듯, 윈도우 8도 문제가 발생한다. 다행히도 대부분의 충돌의 원인을 진단하는 간편한 방법이 있다. 간단히 대부분의 윈도우 충돌의 흔한 원인인 말썽을 일으키는 서드파티 드라이브들을 진단해주는 윈도우 디버그 무료 툴인 WinDbg를 사용하면 된다. editor@itworld.co.kr

2013.04.18

IDG 설문조사

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.6