분류 전체보기

요구사항 명세는 프로젝트를 진행하는 데 있어서 가장 중요하다고 할 수 있는데요. 그리고 개발자는 요구사항이 적힌 명세를 보고 그에 맞는 개발을 하는 것이 가장 중요합니다. 하지만 이러한 요구사항은 프로젝트 중간에도 변경이 될 수 있는데요. 이때 변경은 일부만 변경하는 세부 구현사항이 변경될 수도 있는 반면에 전체적인 구조가 변경되는 경우도 있기 때문에 주의해야 합니다. 또한 테스트 케이스를 작성(TDD)할때도 요구사항을 반영해야 합니다. 클라이언트의 요구에 따라서 요구사항을 도출을 하는데 그것이 바로 프로젝트의 시작이 됩니다. 요구사항 명세서 요구사항 명세서를 작성하는 방식으로는 기본적으로 아래 방식을 이용하는데요. Software Requirement Specification(SRS) 구현물의 기능/비..

수업이 어느새 절반이 지나고 2월을 마무리하였습니다. 그 사이에 조원이 바뀌었으며, 이전에 작업했던 도서API 프로젝트의 프런트 부분도 시작을 했습니다. 우선 도서 API 프론트 부분에서 이전에 수업시간과 다르게 백엔드를 설정해 놨기 때문에 타입에러가 발생하여 수업진행이 어려워 백엔드 부분 일부를 수정하는 시간을 가졌습니다. 수업을 100% 똑같이 진행하지 않아도 되지만 주관적으로 코드를 작성하다 보면 앞으로의 수업에도 100% 똑같이 진행을 할 수가 없을 거라는 판단을 했고, 앞으로의 수업에서 최대한 생각을 배재하고 수업을 따라가는 방향으로 진행하고 주관적인 생각을 넣는 것은 개인 프로젝트를 하면서 진행해야겠다 생각했습니다. 또한 도서 API 서버 부분도 기존에 받은 피드백 내용과 더불어 타입스크립트를..

Contribution 프로젝트는 크게 네이버와 같은 사이트, 혹은 간단한 로그인 기능과 같이 요구사항대로 결과물을 만드는 걸 프로젝트라고 합니다. 프로젝트를 만들 때 우리는 과연 코드 작성만 하는 걸까요? 프로젝트를 만들기 위한 기획, 테스트, 배포, 가이드 등등 다양한 작업도 프로젝트가 될 수 있는데요, 기여 활동도 마찬가지입니다. 코드뿐만 아니라 프로젝트에 다양하게 의견을 어필하는 것도 기여활동이 될 수 있는 것입니다. 코드 외 적 기여활동 코드 기여활동 오타수정 번역 문서 설명추가 배너 문구 수정 제안 UI/UX 제안 버그 픽스 기능 추가/수정/삭제 리팩토링 버전, 외부모듈(업데이트 / 교체) 에러메세지 리소스 테스트 케이스 추가 이렇게 기여활동에는 다양한 것들이 존재하는데요 이 기여활동에 해당되..

오픈소스를 만들기 위해 작성하는 문서들은 종류가 다양한데요. 대부분 문서들은 md 파일이나 txt 파일로 생성을 합니다. 오픈소스를 생성한다면 기본문서는 필수로 작성을 해야 하고 추가적인 문서는 선택에 따라 작성을 하면 되는 것 같습니다. LICENSE(기본) 오픈소스 라이선스 전체문서 명시를 하는 문서로 이 파일이 존재한다면 해당 프로젝트는 라이선스를 갖고 있다는 의미를 내포합니다. 보통 위치는 최상의 디렉토리에 있습니다. 관리하는 라이선스가 많다면 따로 관리하는 경우도 있습니다. READEME(추가) 보통 사용설명서로 작성되는 README에도 라이선스 관련 문서를 작성하기도 합니다. 일반적인 프로젝트 코드 목적 뿐만아니라 사용 시 주의사항도 적을 수 있기 때문이라 생각됩니다. COPYRIGHT (추가..

오늘 배운 내용 📚 오픈소스를 구성하는 구성원 Contributor와 Contribution 오픈소스 커뮤니티 discussions 오늘은 오픈소스를 구성하는 구성원에 대해서 먼저 이야기를 시작해 보겠습니다. 오픈소스를 구경하다 보면 다양한 구성원을 마주 할 수 있습니다. 저작자 : 프로젝트를 만든 사람이나 조직 사용자 : 프로젝트를 가져다 쓰는 사람 이 외에도 다른 구성원이 존재하는데 아래에 작성된 구성원들은 필수 구성원이 아니기 때문에 존재할 수도 있고 없을 수도 있습니다. Maintainer : 프로젝트를 관리하는 사람으로 보통 프로젝트의 방향을 알고 있거나, 직접적으로 설정한 사람을 말하며, 책임자입니다. Committer : Contributor가 contribution을 했을 때 리뷰를 하는 ..

오늘 배운 내용 📚 오픈소스 라이선스 표기법과 분쟁사례 라이선스 문서 구조 오픈소스를 기여하기 위한 issue와 pull request 어제에 이어서 라이선스와 관련된 수업을 들었습니다. 일단 라이선스를 지키지 않았을 때 발생할 수 있는 분쟁사례로 시작을 했는데요. 앞으로 우리가 작업을 하면서 가장 많이 신경 써야 하는 일이라고 생각을 했습니다. 그래서 어떻게 오픈소스를 어떻게 사용하는지 라이선스를 사용한다면 어떻게 작성을 하는지에 대해서 예시로 구글 크롬으로 보여주셨는데 크롬에서 사용한 라이선스들을 특정 링크에 연결시키고 해당 라이선스와 깃허브/사이트로 연결이 되게 설정을 해놓은 것을 보고 많은 참고가 됐던 시간이었습니다. 그리고 프로젝트를 하다보면 오픈소스로 만들 수도 있는데 그때 참고하면 좋을 깃허..

개발자들의 문화중에 지식을 공유하는 문화가 있는데요. 우리가 코드를 작성하다 막히는 부분 혹은 에러 난 것을 해결하기 위해 검색을 통해 해결할 수 있는 것도 바로 이 지식을 공유하는 문화 덕분이라고 생각합니다. 이러한 개발자들이 지식을 공유하는 플랫폼에는 여러가지가 존재하지만 stackoverflow, github, open source가 대표적이라고 할 수 있습니다. 그중 오늘은 오픈소스에 대해서 이야기를 해보려고 합니다. 오픈소스란? 오픈소스는 제한없이 누구에게나 공개된 소스 코드를 말하는데요, 이렇게 공개된 소스 코드를 통해 검사해주기도 하고, 수정해주기도 하는 기여자가 생기기도 합니다. 그렇다면 왜 우리는 소스코드를 공개하는 걸까요? 그 이유는 내 눈에 보이지 않던 버그나 아이디어가 다른 개발자의..

오늘 배운 내용 📚 오픈소스와 라이선스 퍼블리셔로 일하면서 해당 부분에 대해서 따로 생각해보지 않았고 진짜 끽해야 font 정도의 라이선스에 맞춰서 작성할거라 생각했는데 앞으로 계속 일을 할 생각이라면 조금 더 진중하게 찾아보고 작업을 해야하지 않는가 생각을 했던것 같습니다. 처음 든 생각은 배포한다는 전제하에 사용하는 오픈소스의 라이선스를 기본적으로 미리 체크를 해놓고 나중에 배포할때 어떤 라이선스가 존재했는지, 한눈에 알수 있게 정리해놓자 였습니다. 그 이유는 배포할때 어떤 오픈소스를 사용했는지 package.json통해서 확인할수도 있지만 놓친게 있을수도 있기 때문에 사용하는 미리 찾아놓으면 후에 놓치지 않고 작성할수 있을것 같았기 때문입니다. (사실 대부분의 오픈소스들은 MIT 라이선스를 사용하기..

react는 일반적으로 사용하는 HTML, CSS, Javascript로 만드는 사이트와는 다르게 배포하기 위해서는 build라는 작업을 해야 합니다. build는 쉽게 말해서 react에서 작성한 코드들을 압축하여 용량을 낮춘 것인데요. 보시다시피 빌드 전후로 용량이 줄어든 것을 확인할 수 있습니다. 이렇게 build로 압축한 파일을 그대로 사용하기보단 node에서 각 경로에 맞게 response를 전달해 주어야 하는데요. app.use(express.static(path.join(__dirname, '폴더/build'))); app.get('/', (req,res)=>{ res.sendFile(path.join(__dirname, '폴더/build/index.html')) }) 이제 app에 맞는 m..