알고리즘 코드카타 정수 제곱근 판별
주어진 문제 정리 : n의 제곱근이 양의정수라면 제곱근+1 의 제곱반환 이외에 모든 경우 -1반환
처음 설계 : 반복문을 이용하여 n까지 순회한 후 제곱근은 항상 그안에 있으므로 찾을경우 정답조건반환 아닐경우 -1 반환
코드 구현
long long n = 임의로 주어짐
long long answer = 정답
for(int i = 1, i <= n; i++)
{
if(n == (i * i))
{
answer = (i + 1) * (i + 1);
break;
}
else
{
answer = -1;
}
return answer;
}테스트 케이스 모두 통과
제출시 시간초과 및 실패 발생확인
원인 분석 : 주어진 n의 수가 매우 커졌을 경우 반복문을 도는데 매우 큰 시간이 소모됨 시간복잡도 상승
다른 해결방안 파악 : 라이브러리에 제곱근관련된 함수 있는지 검색
c++에서 제공하는 cmath 라이브러리에 제곱근을 구해주는 sqrt()함수 제곱을 구해주는 pow()함수 존재 확인
코드수정 :
if( sqrt(n) % 1 == 0)
{
answer = pow(sqrt(n) + 1, 2);
}
else
{
answer = -1;
}
return answer;테스트 결과 컴파일 문제 발생
발생내용 : sqrt(n) 은 소수 1은 정수형이라 %연산자 사용 불가능
문제풀이 제한시간 1시간 초과 튜터님께 도움 요청
해답방안 : sqrt(n) 을 int형에 저장할 경우 나누어 떨어지는 제곱근이 아닐경우
int형으로 형변환이 일어나 소수점 아래가 버려짐 이후 다시 sqrt(n)을 제곱을 하면 버려진 정수형 기준으로 제곱이되기때문에 값이달라짐 이를 이용하여 조건문을 작성
해답방안 이후 코드수정 :
int x = sqrt(n);
if( n == pow(x,2))
{
answer = pow(x + 1, 2);
}
else
{
answer = -1;
}
return answer;테스트 결과 :
문제제출 결과 :
해결완료
문제풀이 기록 : 라이브러리에 대한 지식 부족으로 시간복잡도 관련된 문제를 해결하는데 해결방안이 떠오르지 않았다. 하지만 오늘의 경험으로 더이상 제곱과 관련된 문제가 나올 경우 cmath 라이브러리를 잊지 않을것이라고 생각한다.
복잡한 switch 문 분리하기 2일차
std::function과 std::map struct를 사용하여 문제 해결해보기
문제가 발생한 부분 :
해당함수는 SpawnMob 함수, 호출시 랜덤으로 인덱스를 추출해서 해당 케이스에 맞는 이름으로
switch 문이 동작하게 되어있다.
원하는 구현설계도 : SpawnMob 함수 호출시 Switch 문이 아닌 일반함수 한번만 호출하여 인덱스에 맞는 값을 전부 넣고 싶음
헤메이던 부분 : "함수 호출 한번만, std::function map 사용해서 해결가능하다" 라는 초점에 사로잡혀서 기본적인 부분을 전부 무시한채 생각의 초점이 고정됨
구현목표 구체적으로 수정 및 정리 : 해당 함수에서 공통적인 부분들을 묶어 불필요한 작업들을 없애고싶음
0단계 : 함수내부에서 공통적으로 사용하고 있는 부분 묶기
Logger::Add(LogType::INFO) 스트링 내용과 출력하는 값들이 전부 동일함
SetStatBoss, SetStat 같은함수를 케이스별로 호출중
해당 공통부분을 따로 묶어서 뺄 수 있는지 생각해보기
1단계 : 보스별로 가져야하는 대사나 데이터를 분류해야 해서 따로 클래스 하나를 만들어 주었다.
몬스터의 정보를 담고있는 클래스를 생성하여 내부에 벡터로 데이터들을 저장하고 해당 데이터를
해당 클래스가 생성될때 초기화 할 수 있도록 생성자에서 초기화를 해주었다.
2단계 : 모아놓은 데이터들을 사용할 클래스에서 멤버변수로 사용하기위해 동적할당 객체화를 하고 상속받는다.
생성자로 객체생성을 하게되면 해당 데이터값들이 활성화 되고
몬스터 생성할경우 정해지는 인덱스를 이용하여 번호에맞는 데이터변수 인덱스에 접근하면 이름에 맞는 해당 객체의 데이터를 불러와서 사용할 수 있다.
검증단계 : 내가 설계하고 작성한 코드가 전에 사용했던 코드대비 얼마나 효율적인지 튜터님께 검사를 받기
검증결과 : 전에사용하던 switch case 문에 비해 훨씬더 보기 편해졌다. 잘 만들어서 사용했다.
해당 방식으로 클래스가 필드 위주로 데이터만 담아 전달/보관하는 클래스를 DTO 라고 한다.
구현하면서 느낀점 : 사실 구현하면서 라기보다는 근래에 코딩을 하면서 항상 가장 크게 느끼는것은 내가 지금 구현한 방법이 최선인것같은데, 라는 생각에서 벗어날 수 가 없었다. 하지만 코딩에 정답은없고 튜터님들의 시선에서 더나은 코드가 보이는데, 스스로가 그런것을 느낄 수 없다는 점이 요즘들어서 가장 성장하고싶은 부분이 된것같다. 이번에는 튜터님의 조언 덕분에 내가 짠 코드가 더욱 개선될 수 있다는 것을 알게되었지만 다음번에는 내가 직접 몸으로 느끼고 부딫힐 벽을 직접 만들어서 이겨내고싶다. 이번에도 벽에 부딫히는 과정은 만족스럽지 못했지만 벽을깨고 한발 나아가는 과정은 생각보다 만족스러웠던것같다.
KPT 회고록 작성
스스로의 시점에서 작성하는 KPT 회고록 -2조팀프로젝트-
Keep : 팀프로젝트를 진행하면서 스스로가 좀 유지할만하다고 느낀점은 내가 맡은역할에대해 끝까지 놓지않고 의심한점, 나의 성과보단 팀위치에서의 나의 역할 인것같다.
Problem : 협업을하면서 내가 맡은 일을 진행하면서 어느정도 조율과 상의를 하였지만 결국 변수이름이나 컴포넌트 클래스의 작동원리 등 애매하고 모르는것들이 남아있었다. 내가 모르는것을 모르지 않았더라면 조금더 수월하고 원활하게 진행을 할 수 있었을것같아서 아쉬웠다 이런점은 개선해야한다.
Try : 기회가된다면 다음 팀프로젝트나 협업이 온다면 내가 주도적으로 진행을 맡는것을 시도해보고 싶다
Feel : 내향적인 사람이라 걱정이 많았었는데 이끌어주시는 분이 계셔서 마음이 많이 편했다 각자 맡은역할도 잘 했던거같아서 벨런스가 좋았다고 느꼈다.
