본문 바로가기

기타

[190226] 삼성SDS 프로그래밍 멘토링

이번 포스트에서는 2019년 2월 26일 삼성SDS타워에서 진행된 삼성SDS 프로그래밍 멘토링의 내용을 각 Section별로 간단히 정리하고자 한다.

 

Section 1. 삼성SDS 개발문화

Agile Software Development: 문서를 통한 개발방법(document-oriented)이 아닌 실질적 코딩을 통한 개발방법(code-oriented). 앞을 예측하기 보다 짧은 주기(short development cycle)를 가지고 끊임없이 프로토 타입을 만들어내며 그때그때 필요한 고객의 요구를 더하고 수정(user centric).

DevOps: Development(개발)+Operation(운영). 계획, 개발, 검증, 배포, 모니터링 프로세스의 자동화. 프로그램의 새 버전을 동일한 환경의 별도의 인프라에 배포하여 테스트를 거쳐 검증이 완료되면 Router의 타겟을 해당 인프라로 바꿔주는 방식(green-blue deployment)를 통해 배포 주기가 빨라지고(rapid delivery) 롤백 또한 쉬워져 프로그램의 안정성이 증가.

 

Section 2. 인싸 개발자, 너도 할 수 있어!

Conway’s Law: 소프트웨어의 구조는 개발 조직의 커뮤니케이션 구조를 닮는다.

시간은 돈이다: 개발 시간을 줄여줄 수 있는 각종 툴(Spring Initializr )들을 활용하는 능력 또한 중요.

 

Section 3. 삼성SDS IT 개발자! 이렇게 일한다!

수학이 코더(coder)와 프로그래머(programmer)를 가르는 기준.

무엇을 배웠는지, 계획했지만 하지 못한 것, 어려웠는데 극복한 것, 팀원과 무엇을 가지고 싸웠는가, 다시 해본다면 해보고 싶었던 것들 등 성공 또는 실패에 도달하는 과정을 포트폴리오로 정리.

 

Section 4. 짧고 쉽고 빠르게! Code Refactoring

 

우리가 알고있던 매우 간단한 이진탐색(Binary Search) 알고리즘에도 버그가 존재하였다. 여섯번째 라인에서 변수 low와 high의 값이 거대할 때(합이 int 자료형의 양의 최대 범위인 2^31-1을 초과할 때) 둘을 더하는 과정에서 Integer Overflow가 발생할 수도 있다는 것이다. 당연하고 자명하다고 생각했던 알고리즘에도 20년간 발견되지 못했던 버그가 존재했다는 사실은 매우 신선한 충격이었다.

 

Clean Code? elegant, efficient, simple, direct, never obscures the designers’ intent. 개발자가 코드를 읽는 시간이 10이면 작성하는 시간이 1이므로 가독성이 중요.

Code Refactoring: Naming(의미 있는 이름 사용), Style(개념은 빈행으로 분리, 행 길이와 들여쓰기 유지), 주석(주석으로 나쁜 코드를 보완하지 말고 코드로 의도를 표현), Dead Code(사용하지 않는 코드X), Method(인수의 개수를 객체를 활용해 최소화(3개 이하), 한 개의 메소드는 한 개의 역할만)

Clean Code를 위해서는 비자아적 프로그래밍이 중요! 내가 만든 코드는 코드일 뿐, 오픈마인드로 조언 긍정적으로 수용하기.

프로그래머 어떻게 준비할 것인가? github, slack, UML 등 기업 비즈니스 어플리케이션 개발 환경 경험, 내가 짠 코드 자동으로 점검 받기(sonarcloud), 개발관련 meetup 적극적 참여.