오늘은 평일
코드 스테이츠에서 수강생들의 근태(?) 관리를 위해 사용하는 앱
시프티를 사용하여 09시에 출근체크, 18시에 퇴근체크를 한다
오늘 배운 것, 그리고 기억에 남는 것은 두 가지
1. 문자열
2. 디버깅
3. pair programming 상호 평가
앞으로 평일의 TIL(Today I Learned) 은
Google Docs 에 강의 노트 차 적어놓은 내용들을 재활용 하는 위주로 쓸 것이다
1. 문자열
JS String by MDN
https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/String
String
String 전역 객체는 문자열(문자의 나열)의 생성자입니다.
developer.mozilla.org
String 전역 객체는 문자열의 생성자이다
작은 따옴표, 큰 따옴표로 만들어 내고 있다 → 즉, 구분하지 않는다
ECMAScript ‘15 이후엔 string litteral 은 template litteral 이 될 수 있다
eg. ‘hello ${who}’ tag ‘ <a>${who}</a>’
String - Length
https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/String/length
String.length
length 속성은 UTF-16 코드 유닛을 기준으로 문자열의 길이를 나타냅니다.
developer.mozilla.org
: 문자열의 길이를 구해주는 메서드
[ 예제 코드 ]
let name = ‘dog’; name.length;
// 이 경우 command line 에 3이 나온다
[ Q. 문자열이 비어있는 경우는 어떻게 될까? ]
let empty_string = ''
empty_string.length;
// 이 경우 비어있는 문자열이기에 0 값을 return 해 준다→ 빈 경우는 0 을 return 해 준다
charAt()
: python 의 string indexing 기능과 같음
: ‘문자열의 몇 번째 문자’ 를 리턴해줌
: python 과 마찬가지로, 0번째가 우리가 흔히 아는 1번째임
예제 코드
'dog'.charAt(0);
// 이 경우 0번째인 'd' 를 return 해 줌그러나 ECMAScript 5 이후, 문자열은 배열과 같은 오브젝트로 취급되어, 숫자 인덱스를 사용할 수 있다
예제 코드
'dog'[0];
// 이 경우도 마찬가지로 0번째인 'd' 를 return 해준다
* 아무래도 난 파이썬이 약간 익어서 그런지, 이게 더 편한 거 같다
* 문자열 원형과 String 객체의 차이
[ 문자열 원형 ]
string litteral : ‘1’
primitive literal : String(1)
→ 해당 경우 integer 1 이 아니라, string type 의 ‘1’ 로 형변환이 된다
* 이 두개가 같은 이유는, JS의 지원 때문이다
new 를 통해 객체 생성을 하지 않는 경우, String() method 로 primitive literal generation 이 가능하다
[ String as Object ]
new 키워드를 사용하여 만드는 object 를 의미함
예제 코드
var s_prim = "string";
//string primitive
var s_obj = new String(s_prim);
//making string primitive to string object
console.log(typeof s_prim);
// string
console.log(typeof s_obj);
// object
new 를 통해 object 로서 string 형 변환을 통해 생성해 준 경우는 object 취급을 받으나
primitive literal 의 경우 (위의 ‘’, 혹은 “” 을 통해 만든 문자열이나, 그냥 String 으로만 선언한 애들) 는
typeof 를 해도 그냥 string 으로 결과가 출력된다
2. 디버깅, 그리고 문제 해결
에러메시지 :
input 되는 test case 와 그 test case 를 통과하지 못 한 원인 등이 나오는 메시지
디버깅 :
에러메시지를 보고, 해당 버그를 잡아내는(de-bug) 과정을 의미함
디버깅의 과정과 유의사항 :
어떤 실험을 진행함에 있어서 ‘결과 논의’ 항목과 같이,
디버깅 또한 ‘왜 이 결과가 나오게 되었는가' 에 대해 논하는 과정이 필요하다
그러나 그 판단엔 반드시 근거가 있어야 하며, 공학의 일종인 ‘컴퓨터 공학' 또한 마찬가지이다
뭐가 문제인지부터 알아야 한다
단서 확보와 단서에 대한 분석
1. 문법 오류 :
에러 메시지를 보고 판단할 수 있으면 참으로 좋은 것
eg. SyntaxError : unexpected token / VM350:6
: 6번 라인에 문법 오류가 생겼다는 이야기임을 추측할 수 있다
2. 로직 오류 :
코드는 잘 돌아가는데, 내가 원하는 값이 안 나오는 경우
2- 1. 어느 부분에서 문제가 발생하였는가 생각해 봄 (가설 선정)
* 여기서 유의할 점은, 한 번에 여러개의 가설을 세우지 않는다는 점
* 여러개를 세우더라도, ‘독립적으로' 가설을 세우도록 하자
2-2. 그 부분 때문에 문제가 발생하였는지 검증해 봄 (가설 검증)
* console.log 나 alert 를 이용하여 눈으로 직접 확인하기 편하게끔 하자
* 가장 좋은 것은, 경우의 수를 정리하는 것
- unit test
- TDD (test-driven developing)
모르는 것을 검색할 때 :
일단 문제를 파악한다 : ‘이 문제는 어떤 것을 요구하는가'
잘 모르겠어 : 구글에 검색하는데, js 의 경우 ‘mdn’ 을 붙여 검색해 준다
MDN이 어려우면 : ‘영어로', ‘js’ 라는 키워드와 함께 자연어(natural language)로 표현하자
에러메시지가 어려우면 : 오류 메시지를 그대로 복붙해 보자 (stackoverflow, github 등 참고)
3. pair programming 상호 평가
개인적으로 생각하는 코드스테이츠의 페어프로그래밍이 마음에 드는 이유는 두 가지다
1. 파트너를 계속해서 바꿔감
2. 그리고 그 파트너마다 상호평가를 효율적으로 진행할 수 있는 내부 로직을 가지고 있음
그리고 오늘은 이 페어프로그래밍의 피드백을 들은 첫 날이었다
3점은 중간이고, 4점은 잘함, 5점은 매우잘함이다
(1, 2점은 4, 5점을 거꾸로 한 것이라고 생각하면 되고)
첫 후기는 확실히 내가 보지 못 한 부분이 보여서 너무 좋았고
나의 파트너 분께선 정말 관심을 가지고 정확히 봐 주면서, 아주 차분한 언어로 명확하게 피드백을 작성해 주셨다
특히, 이 분이 driver 역할을 할 때 코드를 짜는 걸 보면서 참으로 깔끔하다는 생각이 들었고
나도 '아, 코드 가독성을 올려야 겠다!' 라고 느꼈는데
파트너 분께서 그것을 깔끔하게 짚어주셨다는 게 참 감동이었다
이번 파트너 분께선 임베디드 쪽에서 실무 경험이 있으신 분이시고,
pair programming 말미 즈음에 본인이 어떻게, 무슨 일을 하게 되었는지에 대한 간략한 설명을 했는데
아무래도 그 어렵다던 임베디드 쪽에서 갈고 닦으셨는지 기본적인 코드를 쓸때도 굉장히 깔끔하게 코드를 만들었다
특히, 변수명을 깔끔하게 적고, 부호 간의 간격을 적절히 공백을 넣어 가독성을 올렸던 게 가장 인상깊었다
name.length; // 나는 이것을 그대로 사용한다, 딱히 의식을 안 했다 let name_n = name.length; /* 그러나 그 분께선 항상 driver 역할을 맡을 때 마다 전달하고자 하는 바가 더 명확한 변수명을 만드는 데 고민을 많이 하셨고 그리고 이런 식으로 코드의 서두 부분에 깔끔하게 선언을 해 주어 앞으로의 코드가 조금 더 가독성이 살아났다
코드로 예시를 들자면, 다음과 같다
name.length;
// 나는 이것을 그대로 사용한다, 딱히 의식을 안 했다
let name_n = name.length;
/* 그러나 그 분께선 항상 driver 역할을 맡을 때 마다
전달하고자 하는 바가 더 명확한 변수명을 만드는 데 고민을 많이 하셨고
그리고 이런 식으로 코드의 서두 부분에 깔끔하게 선언을 해 주어 앞으로의 코드가 조금 더 가독성이 살아났다
*/이런 부분을 명확하게 지적해 주셨다는 건 그만큼 navigator 역할을 하면서
나를 주의깊게 지켜봐 주셨다는 거다
사람에게 관심 쏟기 생각보다 쉽지 않은데 그걸 해 주시고 명확하게 적어주셔서 큰 도움이 되었다
그렇게 첫 pair programming 은 정말 깔끔하게 마무리 되었다
pair programming 이후 점검 차 가진 office hour 에서
해당 hour 를 주관하신 엔지니어분이 준비해 주신 교육 자료 중
굉장히 마음에 드는 구절을 인용 하는걸로 오늘의 개발일지를 마무리 하고자 한다
이 사람은 나에 대해서 '왜 이렇게 생각하지' 가 아니에요
나와의 관계가 나빠질 수 있음에도 불구하고,
내 성장을 위해서, 나에게 관심을 가지고 솔직하게 말 해준 것에
피드백을 받은 사람은 정말로 감사하게 여겨야 해요
code-states 교육 자료 중 발췌
내일도, 내일의 내일도,
수료하는 그 날까지도, 그 이후의 취업까지도 쭉 정진하도록 하자
3일차 개발일지, 끝!
