개발 이야기 안하는 개발자

서술형 명칭쓰기- 가능하면 주석보다는 서술형 명칭을 사용할 것.- 명사나 함수, 클래스 등의 이름만 보고도 어떤 것인지 이해할 수 있게 명명할 것. 주석문의 적절한 활용- 주석문으로 가독성 높은 코드를 대체할 수 없다.- 주석문은 코드의 이유를 설명하는데 유용하다. (작업 이유, 테스크 넘버, 버전에 따른 이유 설명 등등)string Generate(string data){ //data[0]은 유저의 이름이고 data[1]은 성이다. //"{이름}.{성}"의 형태로 ID를 생성한다. return data[0] + "." + data[1];} 다음 코드는 주석이 있지만 이해하기 어렵다.string Generate(string data){ return FirstName(data) + "." + Last..

명시적 오류...암시적 오류...?이 두개가 계속 번갈아 나오는데 잘 모르겠넹클라 개발자는 엔진에 의존을 많이하니까 당연히 명시적 방법이 맞는거 같은데 엔진에서 크래시 내버리면 그건 암시적 방법을 쓰는거 같기도 하고..? 일단 오류 레츠고 신속하게 실패하라신속한 실패는 정확하게 어디서 에러가 났는지 알 수 있게,문제가 된 부분에서 에러를 띄워야 한다는 뜻이다. 에러가 발생한 부분, 뭔가 잘 못된 부분에서 바로 에러라고 띄워야 하는게 옳다는 의견이다.상황에 따라서는 기본값(default value)를 넘기는 방식도 존재하겠지만, 상황에 따라 다르며 에러인 상황에서 바로 인지 가능하도록 하는게 좋다는 의견이다. 요란한 실패수정이 불가능한 경우라면 에러를 내는데, 요란하게 실패해야 한다.언리얼로 따지면 C..

이번 3챕터는 다른 사람들이 나의 코드를 어떻게 바라보는지, 그래서 어떻게 해야하는지 생각해보는 챕터이다. 우리가 코딩을 할땐 해야하는 작업에 대해 생각하고,어떻게 할지 구조를 짜고 설계를 한다. 즉, 내 일도 바쁜데 다른 사람 코드를 보기엔 피곤하다. 그래서 다음을 고려하며 코드를 작성해야 한다. - 자신에게 명백하다고 해서 다른 사람에게도 명백한 것은 아니다. 작업을 진행하다보면 내가 작성한 코드 위에 동료의 코드가 위에 층층이 쌓이는 일이 빈번하다.그렇게 하다보면 내가 작성한 코드의 명명이 다른사람들에겐 명백하지 않아 혼란을 줄 수 있다.최대한 명백하게 해야하고, 만약 혼란을 줄 것을 고려한다면 주석을 다는 것도 좋은 방법이다. - 다른 개발자는 무의식중에 여러분의 코드를 망가뜨릴 수 있다.작업을 ..

큰일났따 큰일났어2장인데 벌써 머리아프다 머리로는 이해하는 내용들이었다.이걸 지금 프로젝트에 적용한다고 생각하면 너무너무 큰 일이다.일단 오늘 배운거 부터 기록해보자. 코드문제 해결을 위해 어떻게 해결하는가도 중요하지만 해결하는 코드를 어떻게 구성하는가도 중요하다. 우리가 하는 코드 작성복잡한 문제를 계속해서 더 작은 하위 문제로 세분화 하는 작업이 바로 코드 작성이다.계층을 만들면서 같은 층위 내에서는 쉽게 이해할 몇 개의 개념만 다루기 때문에, 개별 코드는 복잡해 보이지 않게 한다. - 상위 수준의 문제- 알고 있어야 하는 하위 문제- 알 필요 없는 하위 문제 간단하게 내가 이해한 바로 설명한다면, 만약 인벤토리를 제작해야 한다고 할때.인벤토리를 열어서 보여준다 가 상위 문제로 둔다.여기서 연다라..

예전에 샀던 책인데.사실 리펙터링 책 사면서 같이 산건데,리펙터링 읽고나서 코딩 개고수가 된 느낌 받아서 안읽었던 책이다. 에휴 퇴근하고 와서 쓸 거라 목차가 한 12개 쯤 되는데 하루에 하나씩 한다 치면2주 걸리겠지? 책에서 말한 고품질 코드란- 신뢰할 수 있다- 유지 보수가 쉽다- 버그가 적은 소프트웨어를 생상한다 본 책의 주 내용 6가지1. 코드는 읽기 쉬워야 한다.2. 코드는 예측 가능해야 한다.3. 코드를 오용하기 어렵게 만들라.4. 코드를 모듈화 하라.5. 코드를 재사용 가능하고 일반화할 수 있게 작성하라.6. 테스트가 용이한 코드를 작성하고, 제대로 테스트 해라. 1. 코드는 읽기 쉬워야 한다.책을 읽으면 엄청 가독성 떨어지는 장문의 글을 예시로 든다.문제는 내가 이걸 읽으면서 이게 뭐..