신입들이 그래도 나 개발좀 한다 어필될만한 것이 뭐가 있을까요?

토이 프로젝트나 학점정두 밖에는 없을까요??
근데 학점도…뭐랄까 그 보면 그냥 배운 내용 그대로 똑같이 잘 옮기는 사람들이
시험을 잘보거든요…그래서 흠…

코딩 테스트도 있긴 한데…이건 너무 내려갈수록 정말 그. 여기 계시는 굇수분들처럼 어셈블리어 단가지구 놀아야 될거 같구…
그냥 알고리즘 구현인 문제들이 너무 많아서요, 실무에서 dfs 30초안에 빠르게 구현하기 이런게 실무도 아닐테구… 레드블랙트리 안보고 짜기 이런게 실무는 아닐거 같은데요 흠//…
조오금 된 일인데 아는형이 대기업 인사채용담당자? (외주로 파견나가 일하다 보니) 뭐 사람 뽑을때
결국엔 얼굴보고 뽑는단 ㅡ,ㅡ;; 말도 있던데 갑자기 생각났네요 (군대에서 맨날 말하는 관상 이런게 아닐까 싶습니다, 차피 거기 후보 될정두면 다들 실력은 입증된거니…)

아 그리고

사실 이번에 조별과제 해보다 보니깐
어떤분은 실력은, 그러니깐 저는 좀 코드 더럽게 짜서 깔끔하게 짜는 연습해야되는데
다른 분 보니깐, 완전 정석에 다른사람이 이해하기 쉽게 짜시더라구요
뭐 세부적인것 말고, 뭉뜽그려서 얘가 뭘 한다 이런식으루요

그런데 그분 다른 과목 성적 보니깐, 생각보다 시험이 까다롭긴 했는데(전에 변별력 예기하던 그 교수님)
그런거 보면 시험 성적이 다는 아닌거 같아서 궁금해 졌습니다.

그런데 토이프로젝트나, 해본걸 요구하면 음… 그 회사에서 좋아하는 언어나 그런게 있을텐데
일단 제가 해본 언어를 다루는 회사쪽으로 방향을 잡는게 맞는거겠죠??

그런데 이런 유명한 말을 어디서 들었거든요

“앞으로 너가 사용할 프로그래밍 랭귀지는…너의 선임이 결정한다…” 아앗;;

고구마 같이 살려구 노력중입니다 행복한 고구마가 되자

1 Like

에이 어셈블리까지 안 만져도 코테는 가능해여
대회급이면 몰라도…

기술 스택은 원하는 직무의 공고에서 자주 언급되는걸로 고르시면 되고요
토이플젝도 기술 스택에 맞게 만들어보시면 됩니다

학점은 대학원 가는거 아니면 그닥…
C로 도배되거나 하지만 않으면 충분합니다

토이플젝에서 주의하실건 응용이에요

인터넷에 떠도는 예제 그대로 배끼거나, 남들 다 하는 클론코딩 같은건 메리트가 없죠
대신 그런 것들에 실무적인 기능을 하나 추가한다거나, 기술 스택에 맞게 추가하시면 됩니다

코딩 스타일에도 신경쓰셔야 하고요
자소서에는 객체지향에 가독성을 써도 코드가 개판이면 신뢰하기 어려우니까요

토이플젝에서 나올만한 면접 질문을 생각해보는 것도 좋은 방법입니다

@Neppen @pi40ni33dr

저도 궁금했던 내용인데, 역시 코드가 깔끔해야하는군요…

지금 해둔 것에도 제가 봐도 지저분한 부분이 많아서,

고치고 싶은데 어떻게 해야 할지 몰라 헤매는 중인데 뭔가 뜨끔합니다;

:sweat_drops:

뭐 포트폴리오도 좋고 다 좋은데요. 제 개인적인 의견으론 “왜?” 에대한 답을 확실하게 할수 있는가 없는가로 판가름 할 수 있지싶읍니다.

  • 왜 그렇게 하셨나요?
  • 왜 X를 사용했나요? Y도 있고 Z도 있는데

본인이 생각해 보고 짠건지. 가따 베낀건지 바로 나오죠 보통. 겉절이들은 2왜 못 넘어 가더라고요.

4 Likes

면접은 또 면접관이랑 케미가 중요해서요 ㅋㅋ… 그냥 정도를 걸으시면 될듯. 책이나 아티클로 배웠으면 연습 프로젝트 하고 자기 평가 하고 다시 하고 또 배우고… 이터레이션 돌려야죠

1 Like

그쳐
만들어도 왜 이렇게 만들었는지 답변을 다 준비할 수 있어야 합니다.

요런 것들을 항상 생각하면서 코딩하시길 권장합니다!

SRP를 따르기

  • 네이밍으로 클래스에 직관적인 역할 부여
  • 너무 많은 메소드(보통 5개 이상)를 가졌다면 클래스/인터페이스 분리

불변 클래스로 만들기

  • getter/setter 제거, 클래스 필드는 전부 const
  • 생성자 체이닝으로 객체 생성시의 유연성 확보
  • 메소드 체이닝 기법을 사용하기 위해, 새로운 객체를 생성해 반환하는 메소드 적극 활용

구조적인 설계로 천천히 바꾸기

  • API 레이어 :arrow_right: 도메인 레이어 :arrow_right: 구현 레이어 :arrow_right: 의존성 레이어 (화살표는 참조 방향)
    • 필요에 따라 도메인 레이어와 구현 레이어를 더 쪼갤 수 있다
  • 외부 의존성을 의존성 레이어에 속한 모듈로 래핑
    • 의존성 레이어가 외부 의존성의 API 레이어에 접근하는 형태
  • API로 제공하는 기능을 도메인 레이어에서 비즈니스 로직으로 구현
    • 구현 상세 및 의존성 레이어의 사용은 구현 레이어에서

견고한 코드를 위한 테스트

  • TDD, 커버리지 100%에 집착하지 않기
    • Bottom-Up의 TDD, Top-Down의 프로토타입
    • 인터페이스에 대한 커버리지는 100% 목표 @sh 님이 지적해주셨던 부분…
    • 테스트 대상의 의존성들을 의존성 주입을 통해 격리 :arrow_right: 테스트 대상에만 집중
  • 클래스간 직접 의존(결합도)을 줄이기 위해 인터페이스를 활용한 의존성 주입 사용
    • 의존성 주입이 있어서 Top-Down, Bottom-Up 어느 방식이라도 개발할 수 있다
  • 인터페이스는 항상 Fake 클래스를 함께 제공
  • 유닛 테스트, 통합 테스트, E2E 테스트를 모두 제공
    • 모든 의존성을 Fake 객체로 받는 유닛 테스트
    • Fake 객체가 아닌 실제 의존 객체를 받는 통합 테스트
    • 유저의 사용 방식처럼 API를 호출하는 E2E 테스트

이건 정말 바보같은 행동이죠. 개인적으로, 자기가짠 핵심 모듈의 중요부분만 제대로 커버하면 된다고 생각합니다.

그리고, 많은 사람들이 놓치는 부분이, 테스트 코드도 버그에서 자유로울수 없다는 점이죠.

경우에따라 mock이니 뭐니 가따 붙히느라, 테스트 코드가 더 긴경우도 많죠. 그럼, 그 테스트코드는 누가 뭘로 어떻게 커버하나요? ㅋㅋ

이쯤되면, 코드의 유지보수 면에서도, 일만 많아지는 결과를 초래 하게됩니다.

최대한 간단히, 최소한의 코드로, 반드시 필요한 부분만 집중해야합미다.

@pi40ni33dr @sh
조언 감사합니다. 메모해 뒀다가 틈틈히 보겠습니다.
:heartpulse:

그러네요… 그 부분을 빼먹었군요

말씀하신대로, 테스트는 코드의 모든 부분을 커버하려는 목적이 아니죠
너무나 작동방식이 당연한 코드는 테스트하지 않아도 충분합니다

각종 테스트 더블들도 테스트 대상에만 집중하기 위해 다른 요소들을 격리하는 목적에 있으니까요

특히나 TDD에서 모든 요소에 테스트를 붙이려는 생각을 경계해야 합니다