스걱스걱

※ 개인적으로 이해한 대로 정리한 글 오류 처리 오류 처리 코드로 인해 프로그램 논리를 이해하기 어렵다면 깨끗한 코드가 아니다. 오류처리를 프로그램 논리와 분리하므로써 독립적인 추론이 가능하고 코드 유지보수성도 높인다. - 오류 코드보다 예외를 사용 오류 플래그나 호출자에게 오류를 반환하는 방법은 호출자 코드가 복잡해지므로 오류를 발견하면 예외를 던진다. - Try-Catch-Finally 문부터 작성 try블록은 어떤 면에서 트랜잭션과비슷하다. try블록에서 무슨일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 하므로 예외가 발생할 코드를 짤 때는 try-catch-finally문으로 시작하는 것을 권장한다. - 미확인(unchecked) 예외를 사용 확인된 예외는 OCP(Open ..

※ 개인적으로 이해한 대로 정리한 글 객체와 자료구조 - 자료의 추상화 변수 사이에 함수라는 계층을 넣는다고 구현이 감춰지지 않는다. 조회 함수(get)와 설정 함수(set)로 변수를 다룬다고 클래스가 되지 않는다. 그보다 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. - 자료 / 객체 비대칭 객체와 자료구조는 근본적으로 양분된다. (자료구조를 사용하는) 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다. 절차적(자료구조) 코드 -> 함수 추가 효율 || 객체지향 코드 -> 클래스 추가 효율 절차적인 코드는 새로운 자료구조를 추가하기 ..

※ 개인적으로 이해한 대로 정리한 글 주석 - 주석은 나쁜 코드를 보완하지 못함, 코드로 의도를 표현 불필요하거나 업데이트가 안된 주석은 보기 나쁘고, 오히려 코드를 더 이해하기 어렵게 한다. 주석을 쓰지 않고, 대부분 코드로 의도를 표현할 수 있다. - 좋은 주석 가장 좋은 주석은 주석을 달지 않을 방법을 찾아낸 주석이다. 법적인 주석 회사의 구현 표준에 맞춰 저작권 정보다 소유권 정보를 주석화 모든 사항을 열거하는 대신 표준 라이선스나 외부 문서 참조가 더 바람직하다. 정보를 제공하는 주석 반환값, 정규식 설명같은 기본적인 정보를 주는 주석 함수 이름을 수정하거나 클래스를 만들어 코드를 옮기면 더 깔끔하고 주석이 필요 없어진다. 의도를 설명하는 주석 구현 이해를 도와주는 선을 넘어 코드를 짠 의도까지..

2020년 7월 10일부터 7주간 boostcourse에서 진행한 코딩 뉴비 챌린지에 참여했다. 리더로 선정되어 팀을 이끌게 되었다. 팀끼리 소통은 slack으로 진행했고, 처음 코딩을 배우시는 분들, 코딩을 배웠지만 기초를 다지고 싶은 분들과 함께 매주 과제를 해결해 제출했다. 리더로써 팀원들이 문제해결에 있어 막히는 부분을 설명해주었고, 각자의 풀이방식이 다 달라서 비교해 보며 공부가 됐다. 챌린지에서 진행했던 컴퓨터 과학 수업도 강의가 쉽고 재밌어서 이론을 다시 익히는 경험이었다. 매주 내주는 과제가 수준별로 되어있어서 어려운 문제도 풀어볼 수 있어서 재밌는 챌린지였다. 마지막 주에는 우수 팀으로 선정되어 금요일에 하던 현직자분의 라이브에 질문할 수 있는 기회도 주어졌다. 추가로 리더 리워드로 스타..

※ 개인적으로 이해한 대로 정리한 글 함수 - 작게 만들기, 한가지만 하기, 부수효과 일으키지 말기 한 눈에 함수의 코드를 볼 수 있도록 작게 만들고, 들여쓰기 수준은 1단이나 2단을 넘으면 안된다. 함수는 한가지 일만 해야한다. 이름에서 알 수 있는 일 한가지만 해야지 다른 일도 같이 하면(log 삭제같은) 해당 함수를 가져다 쓰는 사람에게 의도치않은 피해를 줄 수 있다. 한가지 일만 하는 함수는 자연스럽게 섹션이 구분되기 어렵다. - 함수 당 추상화 수준은 하나로 코드를 읽는 사람에게 근본 개념인지 세부사항인지 어렵게 하기때문에 한 함수 내에 추상화 수준이 다르면 안된다. 위에서 아래로 코드를 읽을 때(내려가기 규칙) 자연스럽게 읽혀야 한다. - switch 문 switch문은 작게 만들기 어렵다. ..

※ 개인적으로 이해한 대로 정리한 글 의미 있는 이름 - 의도를 분명히 하기 변수나 함수, 클래스의 이름을 길더라도 의미있는 이름으로 바꾸고, 상수는 final로 선언하여 이름을 주어 사용하기 배열을 클래스로 바꾸거나(필요 하에), 상수를 함수로 감추어도 좋음 - 그릇된 정보를 피하기 약어라도 이미 프로그래머들 사이에서 의미가 있는 약어는 사용하지 않는다. ex) hypotenuse(삼각형 빗변) -> hp 왜냐하면 hp는 유닉스 플랫폼을 가리키는 이름이기 때문 List가 아닌데 AccountList로 만든다거나 하지 않기 -> 그릇된 정보! Accounts라고 하거다 다른 방법을 찾는다. 한번에 구분되지 않는 흡사한 이름도 피한다 유사한 개념은 유사한 표기법을 사용한다(hot key 조합을 사용할 수 ..

1. Github 협업 방법 gmlwjd9405.github.io/2017/10/27/how-to-collaborate-on-GitHub-1.html [GitHub] GitHub로 협업하는 방법[1] - Feature Branch Workflow - Heee's Development Blog Step by step goes a long way. gmlwjd9405.github.io 2. readme.md markdown 작성법 m.blog.naver.com/jooeun0502/221956294941 [Git, 깃] README.md 작성하는 방법, 예시 | markdown (마크다운) 사용법, 문법 안녕하세요 쥰입니다!오늘은 Git 에서 README.md 파일을 작성할 때 사용하는 Mark Down 문법..