캡스톤 디자인/추천 가중치 알고리즘

푸른하늘·2021년 12월 19일

2021.03.02 ~ 2021.12.18

1년간의 졸업 작품 (캡스톤 디자인)이 작업이 끝났다.

<과거 회상>
개발자에 대한 길에 대한 갈피를 잡지 못하던중에 이제 졸업까지 곧 1년 밖에 남지 않았다는 사실을 알게 되었다. 학교에서 교수님은 1주일 안에 팀원을 선정하여 개발할 아이템을 가져오라고 하셨다.
항상 개발에 대해서는 무지했던 나에게는 큰 시련이였다. 정확히 말하자면 어떤 방식으로 개발을 하는 절차 및 방법을 몰랐다. 그래서 팀원을 구할려고 찾아봤지만 아싸였던 나는 부랴부랴 사람들을 불러모와서 각자 포지션 파트를 정하게 했다. 그 때
백앤드 개발자 / 프로그래밍 개발자 / 프런트 개발자 3명으로 나눴고 나는 프로그래밍 개발자 역할 맡았다. 거의 3~4주간 아이디어 기획하고 설계했지만 교수님의 마음에 들기에는 쉽지가 않았다. 그래도 1년간 열심히 해서 내가 원하는 앱을 개발해야지 하면서 이악물고 했던거 같다. 그렇게 시스템 전체를 구축하고 팀원을 조율하면서 덕분에 크게 성장할 수 있었던거 같다.

💪🏻 내가 얻어 간 것

기획, 설계 등 모든 단계에 직접적으로 참여한 경험.
이슈, sync async 관리
기술력, 검색능력, 끈기력 , English

Zoom / AnyDesk & Git버전 관리

코로나로 인하여 자주 만날수 없는 상황 및 이슈에 대해서 정확히 의사소통을 하기 위해서는 Zoom & AnyDesk 가 필요하다. 그리고 기획 및 협업을 할 때 이슈가 있을시에 Slack/ Notion을 활용하여 해결하였다.
앱의 기획자 역할을 맡게되니까 , 기획/ 디자인 / 개발 / 테스트 / 배포 까지 자연스럽게 공부하게 되었고 무엇보다 Git버전 관리의 중요성을 깨달았다. 그래서 TODO List 및을 주간공정표에 그려서 주마다 기능구현을 어디까지 해야하는 목표치를 정하였다.

굴러기긴 하는데...

비동기 /동기

앱이 만들다 보니 불안정한 부분과 유지보수 할 것이 많았다.
창이 넘겨질 때 java null exception 이슈 때문에 골머리를 앓았는데 예외처리를 해줬다고 생각했지만 못한 부분에서 10%/ 네트워크 송신속도 문제에서 90% 였다.
그래서 안정화를 위해 Call Back 함수와 Handler를 추가해서 비동기 /동기 처리부분을 나눴다

데이터를 많이 받야하는 UI

개발을 하다보면 사용자의 정보 및 방 리스트를 생성할 때 데이터 정보 입력을 필요로 하게 된다. 물론 xml을 여러개 만들거나 혹은 scrollview를 활용하여 하나의 창안에서 해결 할 수 있다. 하지만 사용자는 빠르게 데이터를 입력해서 넣기를 원하고
직관성과 유연성이 중요하여 Expanable 를 활용하여 한 화면에서 데이터가 처리되는 느낌을 주었다.
그리고 여러개의 xml을 하나의 Activity와 하나의 xml으로 관리하기 위해서
include 함수를 사용하였다.
JAVA에 대한 Chip에 대한 내용은 부족해서 직접 Chip Chip을 Custom을 하여 배열 작업을 처리해 사용자의 버튼을 누를때 Switch Case()를 넣어 만들었다.
넌

아쉬웠던 점

초보자였던 만큼 아쉬웠던 점도 많을 수 밖에 없었다.

클린 코드 작성에 규칙을 정하지 못하였었다. 부랴부랴 작업을 프로그래밍을 하고 작업을 하다 보니까 Package/ Activity / layout / id 값 들을 각각 나눠서
파스칼 / 스네이크 / 카멜 표기법을 규칙성 있게 했어야 했는데
개발을 하다 보면 처음에는 의욕이 샘솟지만 벽을 만날 때 지치고 스스로에 대한 자질의 의심을 하게 된다. 구현할려는 기능은 중요하지만 한 번에 많은것을 멀티 태스킹 처럼 구현하게 되면은 논리적 회로에 문제가 생기고 이해보단 개발을 하게되는 상황이 된다 . 그래서 기능을 갈아 엎기도 했고 UI 및 요구사항에 대한 방식이 부실할 수 밖에 없었다.
침작하지 못했다. 개발방향과 코드 참작 가이드 해주는 경험이 많은 개발자가 주위에 없어서 주먹구구식으로 검색에만 의존했다. 문제가 발생하면 오류 부분을 찾고 고치는 부분이 있었지만 리팩토링 작업을 후반에 해주었기에 시간적으로 아쉬웠다.

나중은 없다

오늘 하루 생겼던 오류가 내일이 되면 자연스럽게 해결되는 경우가 없다.
즉, 최대한 빨리 해결한다기 보다는 오류가 생긴 부분의 문제를 찾고 적어 놓는 습관을 가져야한다. 그렇지 않으면 이틀 뒤 오류를 봤을때는 하얀 백치가 된 상태이다.
만약, 정 모르겠다면 롤백을 하는 상황이 오겠지만, 구현한 기능에 대한 시간의 노력은 날라가버리게 된다.

개발은 취업할려는 목적이 아니다

당신이 면접관이라면 레벨 99Level 캐릭터를 가지고 있는 사람 / 레벨 1 Level 99개를 가지고 있는 사람 둘 중에 누구를 선택할 것인가?
당연히 레벨 99Level인 사람을 선택할 것이다. 그만큼 이해도가 높다는 것이고
남들과 다른 차별성인 깊이에 대한 이해가 생기기때문에 채용하는 것이다.
취업할려고 개발을 하게되다 보면 "왜 내가 이런 개발을 하고 있지" 스스로의 대한 자괴감에 빠지거나 생산성있는 목표를 달성하기가 어렵다. 더 나아가 취업을 하더라도 개발에 대한 스트레스만 가중되어질 뿐이다.
일단 태어난거 하고자 하는 일을 최선을 다하고 / 직장은 자신의 원하는 목표를 이루기 위한 수단이다.