개발 이야기 안하는 개발자

금토를 합쳐서 로 했고미식회의 를 따서 이번주는 솥뚜껑 삼겹살을 다녀왔습니다 # 식사 _ 정가네 솥뚜껑 삼겹살https://naver.me/xMjDGSrJ 네이버지도정가네솥뚜껑삼겹살map.naver.com 삼겹살 2인분이랑 갈매기살, 소주, 사이다 이렇게 해서 60,000 원 나왔습니다 솥뚜껑에 구워먹는 삼겹살을 처음 먹어본것 같아요 뭔가 이미지가 굉장히 새로웠습니다.고기가 좀 좋은 고기였던것 같아요 주위에 주신 버섯이랑 파무침이나 김치 굽는것도 그렇고 다 너무 좋았어요. 아쉬운게 고기가 좋은 거였는지 기름이 별로 안나와서 생각보다 김치라던가 볶음밥에 그 돼지고기기름이 잘 안묻어났습니다. 고기는 맛있는데 그 김치랑 버섯이 안어울려서 속상했습니다. - 별점블로그 주인장 - 3.5 (고기 자체는 ..

이사를 온지 1년이 넘었는데, 집밥만 먹고 외식을 잘 안하다보니 날을 잡고 외식하기로 했슴다금토를 합쳐서 로 했고미식회의 를 따서금토에 외식하자를 줄여서 고미로 했습니다!집근처에 맛집이 참 많거든요그래서 주에 식당하나 카페하나 이렇게 돌아다녀 보며 리뷰를 할 예정임다 # 식사 _ 전통춘천닭갈비https://naver.me/x0UP7oNT 네이버지도전통춘천닭갈비map.naver.com 정말 가까운데 항상 사람이 많았던 식당이다.웨이팅하고 입장했다. 닭갈비 2인분치즈사리, 우동사리소주, 사이다 등등 해서 45,500원저희가 주문한건 순한맛이였고, 그래도 적당히 매콤한 정도였고 매운걸 못드시면 치즈추가는 꼭 하시길 바래요. 정말 맛있었습니다 비교를 하자면 보통 우리가 생각하는 닭갈비 맛이 납니다. 당연..

백준 11723문제를 보면 x의 값은 항상 1부터 20사의 값만 추정된다.그래서 처음부터 20개의 값을 셋팅하고 있으면 true로 바꾸는 trigger 형식의 배열을 미리 설정해두었다. 코드에는 문제가 없는것같은데 계속 시간초과가 나길래 찾아보았다. ios::sync_with_stdio(false); cin.tie(NULL);이 두줄을 넣으니 성공했다.ios::sync_with_stdio(false);C++ 스트림(cin,cout)과 C 스트림(stdin,stdout)의 동기화를 끔C와 C++이 같은 버퍼를 공유 → 동기화 비용 발생 끄면 C++만 독립 버퍼 사용 → 오버헤드 대폭 감소scanf/printf와 cin/cout을 섞어 쓰면 안 됨 (예측 불가능한 결과 나올 수 있음)cin.ti..

백준 2309번 9개의 숫자는 고정되어 있고, 7개의 숫자를 추출해야한다.정확하게 합이 100이 되는 숫자를 요청했고, 실패하는 경우는 없다. 그렇다면 2개의 숫자만 알면 되지않을까를 역으로 추적해보았다. 모든 합에 2개의 숫자를 뺐을때 100이되면 정답이라는 생각으로 문제를 풀었다. #include #include #include #include #include #include #include #include #include #include using namespace std;int N[9] = {};int TotalSum = 0;void GetExceptNumber(int& Index_1, int& Index_2){ for (int i = 0; i > N[i]; TotalSum +..

가정을 주의하라 데이터가 있는지 항상 확인해야 한다.주석으로 알려줘야 가정이 있는 경우엔 메소드의 명명이나, 기능을 제한해서 명시해야 한다.또는 호출하는 쪽에서 강제로 알 수 있도록 Assert 같은 에러 메세지를 띄우는 방식을 추가해야한다. 전역 상태를 주의하라 코드를 재사용하기 때문에 데이터가 변질될 가능성이 높다.재사용될 가능성이 있다면 정적을 지우고 공유 상태에 의존성을 주입해야 한다.static 을 사용했던 이유는 대부분 해당 인스턴스를 가지고 있지 않았을 가능성이 있다. 그래서 필요한 곳에 인스턴스를 필요로 하는 메소드를 제작하고, 거기에 주입을 하게하는 방식으로 해결하면 된다.class ShoppingBasket{ static void AddItem(Item item) { ..

의존성 주입의 사용을 고려하라하드코딩된 의존성은 확장성을 저해한다.class TestB{}class TestA{ TestB TestB}위 상태에서 TestA 클래스의 기능이 확장되어서 TestB가 아닌 TestC가 필요로 하게 되는 상황이 온다면?따라서, 위 같은 경우 보단 아래같은 경우를 추천한다. class TestB : public Test{}class TestA{ Test Test TestA(Test InTest) { Test = InTest; }}TestA(new TestB());의존성을 주입하는 방식으로 해야 코드를 확장하기 쉽다. 인터페이스에 의존하라구체적인 구현에 의존하면 적응성이 제한된다.따라서 가능한 경우 인터페이스 의존해야 한다. 클래스 상속에 주의하라기능확장을 위한 마구잡이..

클래스를 인스턴싱하고 데이터를 수정하는 행위는 생각보다 빈번하게 일어날 것이다.이 행위가 내가 방금 로직을 작성하고 바로 사용한다면 괜찮을 거다. 이후에 누군가가 내 코드를 수정한다거나, 아니면 내가 제작한 인스턴스를 가져와서 참고하게 된다면 해당 데이터가 어디서 바뀌었는지, 어떤 의도로 바뀌었는지 찾아보기 어려울 것이다. 따라서 해당 쳅터에서는 클래스의 역할을 어떻게 규정하고 코드를 오용하지 않게 하는 방법을 소개한다. 오용하기 힘들게, Set 함수는 최대한 자제할것.기존에 있던 Text 클래스가 있고 SetFont 와 SetSize 가 있다고 가정하자.만약에 Text 인스턴싱을 얕은 복사를 통해 여러곳에서 사용하게 된다면 문제가 생긴다. A 위치에 A 텍스트가 있다.B 위치에 얕은 복사를 진행한 A ..

열심히 해야하는데...더 열심히 살아야 하는데.... 공부도 하고 게임도 하고 운동도 하고 재태크도 하고 친구도 보고 돈도 벌어야해24시간이 부족하단 말이지......이놈의 쇼츠만 없었어도... 다 했을탠데 ㅎ 매직값을 반환하지 말라 (-1 같이 잘못된 값을 받은 경우)- 대신, 널이나 오류를 반환하는게 좋다- 배열같은 컨테이너 형식은 널 대신 비어있는 값을 반환해라- 문자열은 비어있는 상태에서 문제가 될 수 있으니, 널로 반환해라 예상치 못한 부수효과는 피해라- 부수 효과 : 어떤 함수의 호출이 함수 외부에 초래한 상태 변화를 뜻한다.- 예) 값을 변경하는 함수 내부에 과거 값을 기록 한다( 과거 값을 기록하는게 부수효과 )class UserDisplay{ void getPixel(int x, i..

서술형 명칭쓰기- 가능하면 주석보다는 서술형 명칭을 사용할 것.- 명사나 함수, 클래스 등의 이름만 보고도 어떤 것인지 이해할 수 있게 명명할 것. 주석문의 적절한 활용- 주석문으로 가독성 높은 코드를 대체할 수 없다.- 주석문은 코드의 이유를 설명하는데 유용하다. (작업 이유, 테스크 넘버, 버전에 따른 이유 설명 등등)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장인데 벌써 머리아프다 머리로는 이해하는 내용들이었다.이걸 지금 프로젝트에 적용한다고 생각하면 너무너무 큰 일이다.일단 오늘 배운거 부터 기록해보자. 코드문제 해결을 위해 어떻게 해결하는가도 중요하지만 해결하는 코드를 어떻게 구성하는가도 중요하다. 우리가 하는 코드 작성복잡한 문제를 계속해서 더 작은 하위 문제로 세분화 하는 작업이 바로 코드 작성이다.계층을 만들면서 같은 층위 내에서는 쉽게 이해할 몇 개의 개념만 다루기 때문에, 개별 코드는 복잡해 보이지 않게 한다. - 상위 수준의 문제- 알고 있어야 하는 하위 문제- 알 필요 없는 하위 문제 간단하게 내가 이해한 바로 설명한다면, 만약 인벤토리를 제작해야 한다고 할때.인벤토리를 열어서 보여준다 가 상위 문제로 둔다.여기서 연다라..