항해 99 5기 TIL_48

▶ Today I Learned

 

<알고리즘>

 

[삼각형]

 

소요 시간: 30분

 

해결 여부: 해결

 

https://www.acmicpc.net/problem/1448

 

/*
삼각형 만들기
세준이는 N개의 빨대를 가지고 있다. N개의 빨대 중에 3개의 빨대를 선택했을 때, 이 빨대로 삼각형을 만들 수 있다면, 세 변의 길이의 합의 최댓값을 구하고 싶다.
*/


// 세 변의 길이를 알 때 (가장 긴 변의 길이는 다른 두 변의 길이의 합보다 작아야)
// 성립하지 않으면 -1, 성립한다면 주어진 빨대들의 길이 중 가장 긴것 3가지

// 두번째로 큰 값과 세번째로 큰 값의 합이 가장 큰 값보다 작다면
// 세번째로 큰값과 네번째로 큰 값을 두번째로 큰값과 비교하는 방식!
// 조건에 성립하지 않는 것은 pop

const path = process.platform === 'linux' ? '/dev/stdin' : 'input.txt'
const input = require("fs").readFileSync(path).toString().trim().split('\n')

let arr = []

for(let j = 1; j < input.length; j++) {
    arr.push(input[j].trim()/1)
}

let straws = arr.sort((a, b) => a - b) // 큰 값이 맨뒤에 나오게 오름차순으로 정렬

let answer = 0

while(true) {

  if (straws[straws.length - 1] < straws[straws.length - 2] + straws[straws.length - 3]) {
    answer = straws[straws.length - 1] + straws[straws.length - 2] + straws[straws.length - 3]
    break;
  } 

  if(straws.length - 3 < 0){
    answer = -1
    break;
  }
  
  straws.pop()
}

console.log(answer)

 

그리디 알고리즘에 속하는 문제이다.

보통 스택이나 큐로 해결되는 경우들이 있기 때문에 스택의 기능 pop을 사용해 풀어보았다.

가장 큰 수부터 해결해 나가며 해결되는 순간 반복문이 멈춰버리기 때문에 낮은 값에서 부터 비교하는 것 보다

시간 복잡도가 낮은 선택지라 할 수 있다.

 

 

<실전 프로젝트>

 

[Zoom 클론 코딩]

 

이번 프로젝트에 필요한 Web RTC와 socket.io를 구현하기 위해 노마드 코더님의 Zoom 클론 코딩 강의를 듣기로 했다.

해당 강의 시작 전에는 몇 가지 사전 지식이 필요한데 그 중 babel이 무엇인지 몰라 찾아보았다.

 

Babel이란 ES6 이후 버전의 ECMASCript를 ES5로 바꿔주는 toolchain이다.

브라우저별로 최신 자바스크립트가 작동하지 않을 수 있기 때문에 그런 경우에 구 버전으로 작동시켜주는 것이다.

cf) toolchain이란 출력 값을 그다음 입력 값으로 사용하게 해주는 소프트웨어 툴 세트를 말한다.

 

 

설치는 npm을 통해서 하며 설치코드는 아래와 같다.

npm i @babel/core @babel/cli @babel/node -D

 

설치를 마쳤다면 아래 코드가 package.json에 들어가 있을 것이다.

"@babel/cli": "^7.17.6",
"@babel/core": "^7.17.5",
"@babel/node": "^7.16.8",
"@babel/preset-env": "^7.16.11",

 

 

별도로 프로젝트 폴더 내 최상위 경로에 babel.config.json 이라는 폴더를 만들어 아래 코드도 삽입하여야 한다.

 

{
    "presets": ["@babel/preset-env"]
}

 

이렇게하면 기본적인 설정은 완료되었다.

노마드 님의 강의를 따라 차근 차근 구현해보도록 해야겠다.

 

[와이어 프레임]

 

오늘 역시 회의에 대부분을 사용하였다.

전날 회의를 통해 바뀐 부분을 디자이너님들과 소통하기 전에 업데이트 할 필요가 있었다.

팀원 분들께 말씀드려 우리의 기능 Docs와 피그마 와이어 프레임을 바꾸고 통일시켜 두었다.

회의가 시작되고 디자이너 님들이 제시해주신 현재 프로젝트 방향성에 대한 의문점에 우리는 답변해 나가면서

방향성을 조금 더 조정하였다.

결론적으로 기존 프로젝트의 정체성을 약간 수정함으로써 우리는 원만한 협의에 도달할 수 있었다.

개발적으로도 핵심 기능을 구현해내는 것은 변함이 없고, 핵심 키워드를 약간 수정함으로써

디자이너 분들도 납득할 만한, 어느 정도 사용성과 아이디어의 기발함, 사업성을 고려한 우리만의 와이어 프레임을 도출해내었다.

빠른 시일 내에 이런 협의에 도달할 수 있었던 것은 서로의 차이를 인정하고

맞춰갈 수 있는 부분은 맞추고자 노력한 것이라고 생각한다.

 

▶ 느낀 점

 

소통과 협업이 실무에 있어서 중요하다는 것은 알고 있었지만 왜인지 까지는 사실 항해에 들어오기 전까지 체감해보지 못했다.

항해를 하면서 있었던 미니 프로젝트에서 백엔드와 백엔드 간의 협업, 백엔드와 프론트 간의 협업, 개발자와 디자이너 간의 협업,

모두 제 각기 느낌이 달랐다.

 

백엔드 간의 협업은 서로의 역할을 잘 나누고 누군가의 코드에 문제가 생기면 이를 같이 해결해나가는 방식으로도 대부분 잘 진행되었다.

 

그러나 백과 프론트의 협업은 조금 달랐다. 서로의 기술 스택에 대한 이해가 매우 부족한 상황이었기 때문에 누군가의 일을 대신 해줄 수도 없었고 문제가 발생했을 때 서버와 클라이언트 사이드 중 어느 쪽의 문제인지 분간이 쉽지 않았다. 하지만 모두가 프로젝트의 문제는 모두의 문제라는 인식을 가지고 계셨고, 이해할 수 없는 코드여도 같이 들여다보고 구글링 하며 찾아보기도 했다. 또 백엔드에 문제가 없다고 판단되어도 내가 짠 코드에 문제가 있을 수 있다는 점을 언제나 상기하였기에 프론트 팀원께서 '문제가 있다'고 하실 때 마다 관련된 내 코드를 같이 들여다 보았다. 실제로 그렇게 발견한 백엔드의 문제점도 있었고 그것을 고침으로써 프론트 분들의 고생이 덜어지게 되었다. '우리의 문제가 아니야.'라는 마인드 보다는 '나의 문제일 수도 있겠다.'라는 마인드는 정말 중요한 것 같다.

 

개발자와 디자이너 간의 소통은 서로에 대한 이해 부족에 더해 서로 중요시 하는 부분이 다르다는 점이 있었다. 우리로서는 어떤 기능을 왜 사용할 것인지가 더욱 중요했고 디자이너 분들께서는 사용 편의성과 디자인, 기발한 아이디어, 사업 흥행성이 좀 더 중요한 듯 했다. 하지만 디자이너 님들께서 먼저 특정 기능의 구현이 얼마나 걸릴지 여쭤봐 주셔서 우리는 자체적인 고려 후 개발 기간에 대한 조율이 가능했다. 우리 역시 디자인에 대해 필요한 것은 구체적으로 요청 하기로 하되 대부분은 전문가이신 디자이너님께 전적으로 맡기기로 했다. 아이디어도 짧은 기간과 적은 예산, 개발 난이도 등을 고려해 기존 계획에서 크게 벗어나지 않은 채 방향성을 약간만 바꾸었다.

바꾸게 된 방향성은 개발과 디자인, 기획 모두의 중요성 기준을 어느 정도 충족한 것이기에 우리는 웃으며 세부적인 계획 구상으로 나아갈 수 있었다. 이는 서로에 대한 양보와 배려, 이해를 하려는 노력이 있었기에 가능했다. 디자이너 님들과 개발 팀원분들께 감사드린다 :)

 

앞으로도 협업과 소통을 원만히 할 수 있도록 서로의 입장을 생각하고 상충되지 않는 방향으로 나아가보아야 겠다.

 

 

▶ 공부 시 참고 링크들

 

 

https://dydals5678.tistory.com/91

NODE JS - PUG 설치와 사용법

 

 

https://backend-intro.vlpt.us/1/03.html

1-3. Nodemon 사용하기 · GitBook

 

https://defineall.tistory.com/646

[Node.js] Babel (바벨) 이란? / 사용법

 

https://babeljs.io/docs/en/

Babel · The compiler for next generation JavaScript