이력서 작성시
1. 지원하는 회사 이름을 명확하게 써라.
'귀사'나 '당사' 같은 단어를 사용하면 지원한 회사에 대한 애정이 없거나 이력서 돌려막기 처럼 보인다.
매우 성의 부족이다.
2. 향후 포부는 너무 거창하게 제시하지 마라.
'회사에 입사해 충성하겠다'는 흉내는 기본적인 예의이다.
다른 회사들을 언급하지 않는다.
3. 사진은 전형적인 사진이 좋다.
4. 이모티콘을 사용하지 마라.
5. 적절한 연봉을 제시해라.
연봉 기준을 따르겠다는 이야기는 안 적는게 현명하다.
적정한 수준의 연봉을 제시하는 사람이 자신의 역할과 능력, 지원하는 자리에 대해 어느정도 고민한 사람으로 보인다.
6. 단점을 너무 나열하지 마라.
그것은 솔직한 것이 아니라 떨어뜨려 달라고 하는 것이다.
회사는 동료를 구하는 것이지, 단점을 고쳐주거나 지적하는 곳이 아니다.
7. 쓸데 없는 스펙은 나열하지 마라.
8. 동료와 직원을 뽑는 것이지 노예가 필요한 것이 아니다.
읍소하지 말아라. 회사는 노예를 뽑는 것이 아니다.
9. 논리의 비약을 넘나들지 마라.
오락실에서 근무했다고 게임을 잘만드는 것이 아니다.
10. 반말하지 마라.
거만하고 반말로 이야기하는 것은 큰 실수다.
11. 전 직장이나 동료에 대한 험담을 하지 마라.
실제 같이 일하면서 이야기 하는 것과 첫 대면에 그런 이야기를 나누는 것은 전혀 다른 것이다.
12. 실제 능력을 이야기해라.
채용자는 이력서를 수십 장을 읽으므로, 과장됐다거나 헛소리가 적혀있다 싶으면 이력서 자체를 건너 뛰게 된다.
13. 쓸데 없는 미사여구를 사용하지 마라.
14. 어려운 단어나 단어를 설명하지 마라.
읽는 쪽이 더 잘 안다.
제출한 자기소개서는 최소 20년된 전문가가 읽는다고 생각해라.
15. 너무 겸손한 것도 탈락이다.
자신이 아는 것은 최대한 이야기해라.
아무것도 모르는 사람은 필요 없다.
개발자가 이직해야 할 때
1. 자신의 전문성에 대해서 고민하기 시작할 때
자기 개발에 충실한 사람은 자신이 제대로 된 전문성을 확보하고 있는지에 대해서 의문점이 생기는 시점에 이직을 고민하게 된다. 이 일을 계속 하는 것이 미래에 '전문성'을 가질 수 있느냐에 대해서 의문을 가지기 시작할 때부터이다.
2. 조직원들 간에 문제가 발생하거나, 말도 안 되는 상사의 권위에 질렸을 때부터이다
3. 프로젝트가 종료되었을 때
하나의 프로젝트가 종료되면서 소프트웨어 품질이나 개발에 대한 연속성이 제대로 이어지지 않을 때이다.
안 좋은 회사를 피하는 방법
1. 고급 개발자가 있는가?
CTO나 개발실장이 고급 개발자인가?
내부에서 '존경'받으며 '대우'를 받는가?
2. 개발자들이 오랫동안 근무한 사람들이 있는가?
경험이 풍부한 사람들이 많이 존재하는 개발조직과 회사는 발전 가능성이나 시장을 가지고 있는 경우가 많다.
3. 사무실의 환경을 살펴라.
공간은 있지만 빈 책상에 사용되지 않는 물품만 있다면 처우가 그다지 좋진 않을 것이다.
4. 신입직원 연수나 트레이닝 프로그램이 있는지 확인하라.
자체적인 솔루션이 있거나 지배력이 있는 회사는 '사전에 교육'할 것이 많다.
없다면 그저 적당한 인력을 구해 적당하게 사용한다고 보면 된다.
코드 리뷰 가이드라인
리뷰 필수 내용
1. 코드 검토는 1시간 이내에 끝낼 분량으로 검토한다.
2. 코드는 200라인 이상을 한 번에 검토하지 마라.
검토 사항
1. 시스템의 요구사항이 제대로 반영되었는가?
2. 시스템 설계 규격대로 구현되었는가?
3. 과도한 코딩을 하고 있지 않은가?
4. 같은 기능 구현을 더 단순하게 할 수 있는가?
5. 함수의 입출력 값은 명확한가?
6. 빌딩블록들(알고리즘,자료구조,라이브러리등)이 적절하게 사용되었는가?
7. 좋은 패턴과 추상화를 사용해서 구현하고 있는가?
8. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해서 별도 기술하고 있는가?
9. 함수의 반환은 한 곳에서 이루어지고 있는가?
10. 모든 변수는 사용 전에 초기화하고 있는가?
11. 사용하지 않는 변수가 있는가?
12. 하나의 함수는 하나의 기능만 수행하고 있는가?
코딩 스타일
1. 코딩 스타일 가이드를 준수하고 있는가?
2. 각 파일의 헤더 정보가 존재하는가?
3. 각 함수의 정보를 코드에 대해서 설명하기에 충분한가?
4. 주석은 적절하게 기술되어 있는가?
5. 코드는 잘 구조화(가독성,기능적 측면) 되어 있는가?
6. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가?
7. 변수와 함수의 이름이 일관되게 기술되어 있는가?
8. 가이드를 통한 네이밍 규칙을 준수하고 있는가?
9. 숫자는 단위에 대해서 기술하고 있는가?
10. 숫자를 직접 서술하지 않고 상수를 사용하고 있는가?
11. 어셈블리 코드를 사용했다면 이를 대채할 방법은 없는가?
12. 수행되지 않는 코드는 없는가?
13. 주석 처리된 코드는 삭제 되었는가?
14. 간결하지만 너무 특이한 코드가 존재하는가?
15. 설명을 보거나 작성자에게 물어봐야만 이해 가능한 코드가 있는가?
16. 구현 예정인 기능이 있다면, Todo 주석으로 표시되어 있는가?
아키텍처 검토
1. 함수의 길이는 적당한가?
2. 이 코드는 재사용이 가능한가?
3. 전역변수는 최소로 사용하였는가?
4. 변수의 범위는 적절하게 선언되었는가?
5. 클래스와 함수가 관련된 기능끼리 그룹화가 되었는가?
6. 관련된 함수들이 흩어져 있지 않은가?
7. 중복된 함수나 클래스가 있지 않은가?
8. 코드가 이식성을 고려하여 작성되었는가?
9. 데이터에 맞게 타입이 구체적으로 선언되었는가?
10. If/else 구분이 2단계 이상 중첩되었다면 이를 함수로 더 구분하라
11. Switch/case 문이 중첩되었다면 이를 더 구분하라
12. 리소스에 lock이 있다면 unlock은 반드시 이루어지는가?
13. 힙메모리 할당과 해제는 항상 짝을 이루는가?
14. 스택변수를 반환하고 있는가?
15. 외부/공개 라이브러리 사용하였을 때 MIT 라이선스를 확인했는가? GLT의 경우에는 관련된 영역에서만 사용해야 한다.
16. 블락킹 api 호출 시에 비동기적인 방식으로 처리하고 있는가?
예외처리 체크
1. 입력 매개변수의 유효범위는 체크하고 있는가?
2. 에러 코드와 예외의 호출 함수는 분명하게 반환되고 있는가?
3. 호출함수가 에러와 예외처리 코드를 가지고 있는가?
4. Null pointer와 음수가 처리되는 구조인가?
5. 에러 코드에 대해서 명쾌하게 선언하고 처리하고 있는가?
6. switch 문에 default가 존재하고 예외처리를 하고 있는가?
7. 배열 사용시에 index 범위를 체크하는가?
8. 포인트 사용 시에 유효한 범위를 체크하는가?
9. 가비지 컬렉션을 제대로 하고 있는가?
10. 수학 계산 시에 overflow, underflow가 발생할 가능성이 있는가?
11. 에러 조건이 체크되고 에러 발생 시 로깅 정보를 남기는가?
12. 에러 메시지와 에러 코드가 ㅔ러의 의미를 잘 전달 하는가?
13. Try/Catch 에러 핸들링 사용방법은 적절하게 구현되었는가?
시간의 흐름
1. 최악의 조건에 대해서 고려하였는가?
2. 무한루프와 재귀함수는 특이사항이 아니라면 없어야 한다.
3. 재귀함수 사용 시에 call stack 값의 최댓값이 고정되어 있는가?
4. 경쟁 조건이 존재하는가?
5. 스레드는 정상 생성, 동작하는 코드를 가지고 있는가?
6. 불필요한 최적화를 통해서 코드 가독성을 희생하였는가?
테스트 자동화
1. 코드는 시험하기 쉽게 작성되었는가?
2. 단위 테스트가 쉽게 될 수 있는가?
3. 에러 핸들링 코드도 잘 테스트 되었는가?
4. 컴파일, 링크 체크 시에 경고 메시지도 100% 처리하였는가?
5. 경계값, 음숫값, 0/1등의 가독성이 떨어진느 코드에 대해서 충분하게 경계하고 있는가?
6. 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가?
7. 모든 인터페이스와 모든 예외 조건에 대해서 테스트 코드가 있는가?
8. 최악의 조건에서도 리소스 사용은 문제가 없는가?
9. 런타임 시의 오류와 로그에 대비한 시스템이 있는가?
10. 테스트를 위한 주석 코드가 존재하는가?
하드웨어 테스트
1. I/O 오퍼레이션 코드에 대한 테스트로 하드웨어가 정상적인 동작을 보장하는가?
2. 최소/최대 타이밍 요구사항에 대해서도 하드웨어 인터페이스가 충족하는가?
3. 멀티바이트 하드웨어 레지스터가 read/write 오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가?
4. 시스템이 잘 정의된 하드웨어 상태로 리셋하는 것을 S/W가 보장하는가?
5. 하드웨어의 전압이 떨어지거나 전원이 차단되는 경우에 잘 처리하는가?
6. 대기모드 진입 시와 빠져나올 때에 시스템이 옳게 동작하는가?
7. 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결되어 있는가?
8. 데이터 깨짐을 막기 위한 메커니즘이 있는가?
'도서 > IT' 카테고리의 다른 글
| 게임 프로그래밍 패턴 (0) | 2022.09.17 |
|---|---|
| C++ 최적화 (0) | 2022.09.16 |
| 실용주의 프로그래머 (0) | 2022.02.14 |
| [도메인 주도 설계란 무엇인가] (0) | 2021.11.27 |
| C/C++ 프로그래머가 몰랐던 프로그램의 동작 원리 (0) | 2021.10.30 |