Post

A반 12조 1년 12달 개발하조 KPT 회고

Posted Updated
By
views 14 min read
A반 12조 1년 12달 개발하조 KPT 회고

스파르타 내일 배움 캠프 A반 12조 내배캠 수강생 관리 프로그램 KTP 회고입니다.

1년 12달 개발하조 팀 프로젝트 기획 🐶🐾

  • 프로그래밍 기초에 대해 학습하고 Java언어를 기반으로 팀 과제를 진행하였습니다.

  • 프로그래밍 기초 수업에서 자바의 역사와 연산자, if문 및 switch문, for문, while문, 컬렉션 List, Stack, Queue, Set, Map 그리고 클래스란 무엇인가? 등의 클래스 책임 분리에 대한 이해, 클래스 하나에 책임을 가지고 외부에서는 요청만 하기, 추상 클래스, 다형성, 제네릭, 예외처리, Stream 등에 대해 학습했고 최대한 프로젝트에 녹여보려고 노력했습니다.

  • 2024.05.03 ~ 2024.05.09일까지 7일의 기간이 주어졌기에 원활한 의사소통과 좋은 협업에 중점을 두었습니다.

    • 좋은 협업 : 예쁜 말로 소통, 팀원에게 도움 제공 및 받기

1

  • 저희 팀은 모든 아이디어 회의는 브레인스토밍을 통해 ‘생각나는대로’ 다양한 아이디어를 자유롭게 제시하고 취합·수정·보완을하는 방식으로 진행하였습니다.

수강생 관리 프로그램 🎮

  • 프로그램의 주제는 내일배움캠프 스프링 수강생들을 관리하는 프로그램입니다.

  • 요구사항 정의

    • 캠프에는 필수 과목과 선택 과목이 존재합니다.

    • 필수 과목 : Java, 객체지향, Spring, JPA, MySQL

    • 선택 과목 : 디자인 패턴, Spring Security, Redis, MongoDB

    • 조건

      • 최소 3개 이상의 필수 과목, 2개 이상의 선택 과목을 선택합니다.

      • 캠프 기간동안 선택한 과목별로 총 10회의 시험을 봅니다.
      • 캠프 매니저는 수강생을 등록 및 관리할 수 있습니다.
      • 캠프 매니저는 수강생들의 과목과 시험 점수를 등록 및 관리할 수 있습니다.
      • 점수 데이터 타입 : 정수형
      • 점수에 따라 등급이 매겨집니다.
    • 등급 산정 기준

      • 필수 과목 A : 95 ~ 100, B : 90 ~ 94, C : 80 ~ 89, D : 70 ~ 79, F : 60 ~ 69, N : 60점 미만

      • 선택 과목 A : 90 ~ 100, B : 80 ~ 89, C : 70 ~ 79, D : 60 ~ 69, F : 50 ~ 59, N : 50점 미만

  • 필수 요구 사항

    • <수강생 관리="">
      • 주의 : 수강생 고유번호는 중복될 수 없습니다.
        1. 수강생 정보를 등록할 수 있습니다.
        1. 수강생 목록을 조회할 수 있습니다. 조회 형식은 자유입니다.
    • <점수 관리="">
      • 등록하려는 과목의 회차 점수가 이미 등록되어 있다면 등록할 수 없습니다. 과목의 회차 점수가 중복되어 등록될 수 없습니다.
      • 회차에 10 초과 및 1 미만의 수가 저장될 수 없습니다. (회차 범위: 1 ~ 10)
      • 점수에 100 초과 및 음수가 저장될 수 없습니다. (점수 범위: 0 ~ 100)
        1. 수강생의 과목별 시험 회차 및 점수를 등록할 수 있습니다.
          • 점수를 등록하면 자동으로 등급이 추가 저장됩니다.
        1. 수강생의 과목별 회차 점수를 수정할 수 있습니다.
        1. 수강생의 특정 과목 회차별 등급을 조회할 수 있습니다.

  • 추가 요구 사항

    • <수강생 관리="">
        1. 수강생 상태를 관리할 수 있습니다.
        1. 수강생 정보를 조회할 수 있습니다.
        1. 수강생 정보를 수정(이름, 상태)할 수 있습니다.
        1. 상태별 수강생 목록을 조회할 수 있습니다.
        1. 수강생을 삭제할 수 있습니다.
    • <점수 관리="">
        1. 수강생 과목별 평균 등급을 조회할 수 있습니다.
        1. 특정 상태 수강생들의 필수 과목 평균 등급을 조회합니다.


와이어프레임 🧩

1


클래스 설계도 ✍🏻

1


ERD DIAGRAM 🧬

1


API 명세서 🔨

1


역할 분배 📤

  • 유환님 🕵🏻‍♂️ :
    • Score 담당
      • 학생들이 수강중인 과목에 대한 점수 CRUD
      • 점수 CRUD가 원활하게 작동되기 위한 Main 클래스 내부 작동 코드
      • 팀의 광대(가 되고싶었던 I…)
  • 균한님 👨🏻‍💻 :
    • Main 담당
      • DataStroe 클래스 설계 및 구현
      • AutoIncrement 클래스 설계 및 구현
      • main 메서드 코드 병합
  • 태순님 👨🏻‍🏫 :
    • subject 및 발표 담당
      • subject 클래스 설계 및 구현
      • 발표 영상 및 자료 작성
  • 나영(나) 🧙🏻‍♀️:
    • Student 담당
      • Student 클래스 설계 및 구현
      • StudentList 설계 및 구현
      • main 함수에 Student 관련 내부 작동 코드
      • 디자인


API 설계 🔨

1


협업 🐱‍💻

  • Github를 사용했고 팀원들 각자 브랜치에서 개발 후 main 브랜치에서 pull request하는 방식을 사용했습니다.

1

  • 현재는 팀원들의 개별 이름으로 Class를 나누어 개발했지만 다음에는 Class 기능별로 분류하는 것이 더 바람직하다는 결론을 회의를 통해 도출했습니다.


KTP 회고 📌

Keep

💡 현재 프로젝트 진행 과정 중 다음 프로젝트에서도 유지했으면 하는 부분

  • 기본 템플릿을 제공해도 사용하지 않고 처음부터 설계를 시작한 것

  • 바로 구현에 들어가지 않고 계획을 세운 뒤에 개발을 진행한 것
  • 팀원들과 의사소통을 지속적으로 한 것
  • 쉽게 풀리는 문제도 다양한 방법을 시도한 것
  • 튜터님께 피드백을 받고 그 부분을 팀원들과 대화를 통해 리펙토링 과정을 거친 것
  • 에러를 해결하려고 포기하지 않고 노력한 점
  • 객체지향적 개발을 위해 고민을 끊임없이 한 것

💡 현재 만족하고 있는 부분(Good)

  • 역할 분배를 정확히 나누어 상대적으로 짧은 시간에 프로젝트를 마무리한 것

  • 의견 제시에 두려움 없이 다양한 의견을 제시한 것

💡 계속 이어갔으면 하는 부분(Keep)

  • 주기적으로 회의를 진행한 것

  • 다른 팀과 차별화를 두려고 하는 것
  • 예외처리를 다양하게 진행한 것(취약점 분석에 대해 날카로운 질문을 하는 것)

Problem

💡 문제점 : 이번 프로젝트에서 발생한 문제점을 객관적으로

  • branch를 기능으로 구분하지 않고 이름으로 설정한 것

  • Java언어에 대한 이해 미숙
  • 코드 convention 사용하지 않은 것(변수명, git commit 등)
  • 트러블에 대해 따로 메모해 두지 않은 것
  • enum 사용하지 않은 것
  • MVC 패턴을 사용하지 않은 것
  • SOLID 원칙을 지키지 않은 것

Try

💡 잘하고 있는 것을 더 잘하기 위해, 그리고 문제가 있는 점을 해결하기 위해 우리가 시도해 볼 것들

  • Git-flow를 정하고 이해하기

  • 유튜브 등을 활용하여 Java 언어에 대해 이해하기
  • 프로젝트 진행 전 코드 convention 계획하기
  • 트러블 발생 시 github Issues를 사용하기
  • 클래스들의 책임을 분리하여 MVC 패턴 사용하기
  • 객체지향 설계에서 지켜줘야 할 소프트웨어 개발 원칙 지켜보기


느낀점 🛫

  • 나영 🧙🏻‍♀️ : 이번 프로젝트를 통해 클래스란 무엇인가에 대해 학습했습니다. 이전에는 클래스 책임 분배에 대해 이해하지 못해서 main 함수에 다른 클래스에서 만든 기능 메서드를 많이 작성했는데 클래스는 하나의 책임을 가지고 책임이 분리되게 외부에는 요청만 해야되는 중요한 사실을 공부하게 되었습니다. 즉, 클래스는 내가 새로운 타입을 만드는 것으로 이해하고 그 클래스에는 본인이 만든 기능만 있어야 하며 이 기능이 외부에 있으면 이상하게 생각하여 고민해 봐야 된다는 사실을 깨닫게 되었습니다. 다시말해 클래스는 내가 만드는 타입으로 내가 만든 기능만 있어야 된다는 것을 프로젝트 중에 이해했고 이해한 순간 main 책임 전가에 대해 고민해 보려는 연습을 많이 한 거 같습니다. 그리고 에러처리 등 트러블이 많이 발생했는데 수정할 때 따로 메모해 두지 않아서 다음에는 메모해 놓아서 트러블 슈팅 과정 또한 진행하는 게 좋다고 생각했습니다.

  • 유환 🕵🏻‍♂️ : 욕심을 부리지 않는다면 쉽게 할 수도 있지만 객체지향의 기본을 지키려면 어려워질 수 밖에 없는 것을 느꼈다.
    이 어려움이 당연하다고 느껴질 수 있도록 좋은 코드 예시를 찾아보고 직접 구현해보는 과정이 중요하다는 것을 느꼈다.

  • 균한 👨🏻‍💻: 이번 프로젝트를 진행하면서 객체 지향적 사고가 부족하고 절차 지향적으로 설계하고 코드를 작성한다는 걸 알게 되었습니다.
    객체 지향 언어를 배우는 만큼 객체화하는 설계를 많이 해보는 연습을 해야겠다고 느꼈습니다.
    또한, 설계 단계에서 귀찮다고 넘기는 습관을 버리고 팀 프로젝트인 만큼 더 좋은 결과를 얻을 수 있게 적극적으로 의견을 말해야겠습니다.

  • 태순 👨🏻‍🏫 : 아직 Java공부가 부족해서 주어진 주제로 코드를 작성하는데 많이 어려움을 느껴서 시간이 될 때마다 Java코드를 짜는 연습을 더 많이 해야 될 거 같습니다. 그리고 설계가 얼마나 중요한지 느껴서 앞으로 코드 작성을 하게 되면 설계부터 하는 연습을 더 해야 될 거 같다


추가 ⏳

1

  • github 💟 : https://github.com/LeeNaYoung240/student_management_project
sparta
sparta
This post is licensed under CC BY 4.0 by the author.