백준 프로그래머스 알고리즘 문제라는게 결국 어려운건 비문학 문제라 대체 뭘 원하나 내용 파악이 어렵고...
시간 복잡도 개발도 요새는 거의 쓰지도 않고.
소트 정렬 알고리즘, 이진, 그래프 등등 다 기억도 잘 안나는데 예전엔 열심히 풀었는데
솔직하게 말하자면 정렬 같은거 LinQ 쓰는게 낫고
기본적으로 자료 정리 이런것들 보면 대외적으로 잘 쓰이는 라이브러리가 있어서 그거 쓰는게 틀렸을때 에러 대처가 편함.
물론 모든 이런 범용적인 라이브러리는 오버헤드를 가지기때문에 최적화 위해서는 결국 자기가 알고리즘 맞춰야해서 빅오 표기법 배워야하니 하는데
까놓고 이야기하면 현대 컴퓨터의 발달로 그냥 게임의 경우엔 3D는 기본적으로 버텍스 이런게 문제라 오히려 저런 오버헤드 정도는 충분히 감내 가능함.
오히려 어떤 문제에 대한 범용적인 솔루션등이 지금은 인터넷상에 굉장히 많음.
그럼 알고리즘을 써야할때라는 건 저런 문제등을 응용해야할때인데,
오히려 개인이 알고리즘을 풀어서 가져왔을때 버그 처리나 이런거 생각하면 오히려 수지타산에 안맞음
나는 A* 알고리즘을 직접 계산해서 변형했는데, 막상 생각해보면 오히려 유니티 전용 A* 무료 에셋 쓰는게 사고쳤을때 인터넷에 질문하기에 편함.
쿼드 트리 알고리즘도 내가 직접 구현했는데, 이것도 결국 범용적으로 쓰이는게 있어서 그거 쓰면 질문하는게 더 편함.
그래프도 매한가지. 내가 직접 구현하는 건 일종의 바퀴의 재발명 같음.
결국 유지보수를 하기 위해선 범용적인 라이브러리를 택하는게 훨씬 나은 선택인거 같고, 차라리 어떤 정렬과 유형별로 자주 쓰이는 라이브러리, 프레임 워크 쓰는 법 이런거 알려주는게 더 나은거 같단 생각도 듬.
오버헤드 때문에 자기가 맞게 변형 해야하고...이러는데 요즘 컴퓨터들이 옛날 컴도 아니고... 휴대폰만봐도 성능 개좋은데 그래야하나 싶고. 게임 개발에서 대체로 주요 자원 쳐먹는거보면, 대부분은 매시 렌더링에서 대부분 잡아먹음. 범용 라이브러리의 오버헤드가 그정도인가도 솔직히 모르겠고.
알고리즘을 씀으로써 응용력이 올라가고, 문제 해결 능력에 대한 향상이 있다 하는데, 막상 시간 지나면 그 문제 유형을 까먹어서 그냥 문제 유형마다 보편적인 라이브러리 쓰는게 더 나은거 같고.
절차적 생성만해도 BSP 직접 계산해서 지랄 했지만 결국 남이 자주 쓰는거 썼으면 이럴 일도 없었고.
디자인 패턴도 결국 패턴 안쓰고 내 식대로 개발하면서 질문하다 막히기 시작하면 어려워지니까 결국 어느정도 부하 포기하고 리팩토링해서 패턴 맞추듯이
결국 내가 이 문제를 유지보수 할 수 있는가에 대한 초점으로 봤을때, 알고리즘을 내가 직접 적용한다는게 좀 시간 아깝단 생각이 많이듬.
오히려 유지보수만 힘들어지는 경향이 있는듯.
알고리즘을 쓰면 코테에서 유리하다는 건 익히 들어 잘 알겠는데, 그거랑 별개로 내 식대로 만들어 쓰는거랑 범용 라이브러리, 프레임워크 쓰는거랑
유지보수에서 난이도가 달라져서 알고리즘 직접 푸는게 좀 손해같단 생각 많이함..
왜냐하면 회사에서는 사용엔진만 쓰지 않거든 언리얼에서는 기존 구조를 이해하고 수정할 수 있어야하거나, 레거시 코드에서는 stl을 쓰지 않는 플젝도 있고 언어 버전업도 쉽지 않기 때문에 기능 하나 하나 구현할때마다 더 좋은 알고리즘과 자료구조를 찾게됨
그런가 회사 들어가봐야 알 수 있는 문제가 있는건가
직접 구현하는 능력은 당연하고 예외 케이스를 항상 생각하며 코딩해야함 이건 알고리즘 문제 풀다보면 익힐 수 있는 것이기 때문에 코테를 많이보는것
근데 내 케이스는 존나 레거시라 그런거지 다른 곳에선 모름
솔직히 직접 구현하면 단순한 구현도 버그 처리나 예외 처리 이런거 너무 많아서 그냥 범용 라이브러리 쓰는게 낫단 생각 많이함. 특히 Linq 익숙해지니까 더 그런 생각듬\
범용 라이브러리를 쓰기 어려운 환경에서 개발하는 입장에선 쉽게 공감하기 어렵네오... 성능이나 제약사항을 고려하지 않는다면 틀린말 아니기도 하고 도구를 잘 쓰는게 중요한게 트렌드인건 맞는데 결국 그런 트렌드도 변화하는거고, 지식을 아는 것과 도구를 잘 쓰는 것은 병행 가능한 일이라고 봄. 보통은 기성 라이브러리로는 나의 지엽적인 모든 문제를 커버하기 어려운 경우도 많고. - dc App
역시 엉님이십니다..
그래서 내가 실무에서 개발하게 되는 레이어가 어느정도인지, 회사에서 요구하는 개발 사양과 개발 기간이 얼마나 되는지에 따라 네 말이 맞을 수도 있고 아니게 될 수도 있는 것 같음, 그리고 가르치는 입장에선 그걸 가늠할 수 없으니까(=학생이 어떠한 성격의 업장으로 취직할지 모르니까) 이론 위주로 가르칠 수 밖에 없는 것도 있을 것 같고? - dc App
역시 가르치시는 입장이었군요. 저는 개인 개발자다보니 잘 모르겠습니다. 오히려 범용 라이브러리를 쓰면 GPT쪽에 질문하기도 편해서.형님이 말씀하시는 환경이 어떤진 모르겠네요
음... 저도 개발자고 가르치는 입장은 아닙니다. 뭐랄까, 예시를 들고 싶은데 구체적인 예시가 떠오르질 않아서... 라이브러리를 부정하는 입장은 아닌데 개발 사양이 높아질 수록 라이브러리의 커버영역보다 문제 발생영역이 더 커진다고 봐서요. 그러한 경우도 있는거고... 개발 사양이 그렇게 높지 않은 케이스의 경우에는 말씀하신 대로 적절한 라이브러리를 잘 활용해서 보다 빠르게 구현하는게 의미가 있겠죠. 시간이 참 중요한 자원인 것도 맞고요. 어느 한 쪽을 등한시 하는 것 보다는 분야와 요구조건이 그만큼 천차만별이기 때문에 내가 활용할 수 있는 많은 도구를 가지고 있는게 중요하다고 하고 싶네요... - dc App
해당 댓글은 삭제되었습니다.
ㄹㅇ 그런 느낌...