공부와 프로젝트는 구분지어야 한다...
제 친구들도 그렇고... 개발자 단톡방에 있는 사람들도 그렇고 너무 안타깝게 프로젝트 하고계신 분들이 많아서 이렇게 글을 남깁니다.
많은 분들이 정말 착각하시는게... 프로젝트와 공부의 선을 구분짓지 못하신다는 겁니다.
프로젝트와 공부는 엄연하게 선을 그으셔야 하는 영역입니다.
공부에는 시간 제약이 없지만.. 프로젝트에는 분명하게 시간 제약이라는게 존재합니다.
이 시간제약이라는 것은 절대적으로 지켜야 하는 사항입니다.
물론 한번에 프로젝트 개발할때 좋은 방법으로 완벽하게 만드는것 좋습니다.
하지만 여러분들은 초보 개발자 입니다.
한번에 완벽하게 동작하고 좋은 솔루션으로 개발을 하실수 없으십니다...
그렇다면 결국 기능을 개발하기 위해 공부를 해야한다는 소리인데...
나에게 얼마만큼의 시간이 주어졌고 해당 기능을 구현하는데 얼마만큼의 시간을 쏟을수 있나?
이런 판단을 빠르게 내리셔야 합니다.
그렇지만 인터넷에서는 좋지 않은 솔루션이라고 했단 말이예요...
제가 항상 시간의 중요성과 현재 할수있는 방법을 하라! 라고 말했을때 매번 들었던 말입니다.
네 맞습니다. 그 방법은 ~~~ 이유 때문에 좋지 않은 방식이다...
이해가 갑니다.
그런데 말입니다. 왜 그방법이 좋지 않은 솔루션이 되었는지는 알고 바꾸 시려는 겁니까...?
그저 인터넷에 이 방법은 좋지 않은 방법이예요!!! 그래서 쓰면 안됩니다!! 라고 되있어서 안 쓰는 겁니까...?
죄송하지만 저렇게만 되어있는 글은 아 그렇구나 하고 넘기세요... 개발에는 정답이 없습니다. 구글 Docs에서도 이 방법을 권장함. 이라고만 써놓지 이 방법 빼고는 전부다 잘못된 방법임 쓰면 안됨. 이렇게 안써놓습니다.
뭐 성능의 차이가 있어서요, 메모리 누수가 있어서요...
이런거 다 거르세요... 성능의 차이? 얼마만큼 다이나믹하게 차이가 납니까? 그 성능이라는게 0.1초 미만이라면 전혀 의미없는 수치입니다.
사람의 인지 영역 밖이예요...
메모리 누수요? 얼마만큼의 누수가 납니까? 요즘 컴퓨터, 핸드폰의 램이 몇 GB인데요...
그런것 때문에 OOM이 나서 프로그램이 강제 종료되거나 하지 않습니다...
적은 메모리를 사용하는 임베디드, 하드웨어 영역에서는 민감하지만 고용량의 메모리를 사용하는 소프트웨어 영역에서는 어느정도 허용할만한 수치입니다.
다만 deprecated 쳐져있는건 한번쯤 고민을 해볼수 있습니다.
언제 없어질지 모르는 메서드니까요. 하지만 이것마저도 사용하면 안된다!! 이뜻은 아닙니다.
deprecated 되었지만 기능들은 돌아가는게 많습니다.
그러니 일단 해당 기능을 구현을 해놓고 동작하는것을 확인한후 시간이 남으면 개선을 한번 해보시는것을 추천합니다.
개선을 시도하다가 도저히 안되겠으면 일단 그냥 해당 방법 사용하세요.
프로젝트는 결과물만 찍어내려고 하는게 아닙니다.
대단히 착각하시는 분들이 많습니다. 프로젝트를 결과물만 찍어내고 끝내려고 하시는 분들이 많아요..
이런것을 보면 조금 당황스럽습니다.
프로젝트가 결과물을 만들어 내는건 맞지만 그 결과물을 만들어 내는 과정이 중요하다고 생각하거든요.
그렇기 때문에 제가 일정을 중요시 한다는겁니다.
프로젝트의 기간 설정, 해당 프로젝트 기능들의 우선 순위 결정, 한정된 시간내 어느정도의 기능을 완성시켰는지,
기간내 해결하기 위해 어떻게 일을 했는지, 기간이 모자랐을때 어떻게 타협을 했는지 이 모든 과정이 중요한 겁니다.
솔직히 말씀드려서 초보 개발자 들이 만들어 내는 프로젝트는 거기서 거기입니다...
기업에서 중요하게 보는건 그 프로젝트 과정에서 어떤 경험을 쌓았는지를 눈여겨 보는겁니다.
그래서 면접자리에서 프로젝트 기간은 얼마로 잡았는지, 어느정도 완성을 했는지, 프로젝트를 하면서 어떤 문제점이 있었는지, 추가 업데이트를 해봤는지, 해봤다면 어떤 업데이트를 해봤는지 등을 집중적으로 물어보는겁니다..
위쪽에서 제가 말씀드린게 있었죠. 일단 기능부터 먼저 구현하라고.. 해당 기능의 개선은 이 업데이트를 통해 하는겁니다.
괜히 1.0.0ver 같이 버전 관리를 하는게 아닙니다... 먼저 큰 뼈대를 만들고 나중에 사후 업데이트를 통해 살점들을 붙여나가는 겁니다..
세상 어느 기업도 1.0.0 ver 부터 완벽하게 모든것을 다 개발해서 출시하지 않습니다..
먼저 필수기능들을 모두 개발하고 출시를 한후 추후 업데이트를 통해 디자인을 개선하든, 소스를 수정해서 버그를 줄이든, 성능을 향상시킨든, 기능을 추가하든 하는겁니다.
이런 부분이 중요한겁니다.
따라서 프로젝트할때 기간내 못한것들을 따로 기록해두시고... 나중에 추후 업데이트를 할때 해당 부분 수정하거나 추가해서 업데이트를 하시면 됩니다.
결론
결론을 말하자면 프로젝트에서 정한 시간제한은 절대적으로 지켜야할 전제 조건입니다.
그렇기 때문에 절대 전체 기간의 일정을 함부로 조절하시면 안됩니다.
정말 피치 못하게 조절해야할 경우는 프로젝트 종료 2일전 필수기능 80%미만이 개발되었을때 입니다.
첫프로젝트의 퀄리티는 중요하지 않습니다.. 가장 중요한건 기간내 기능들을 완성해 해당 프로젝트를 성공했냐 못했냐 인것이죠...
경험이 중요한것입니다. 첫술부터 절대 배부를수는 없습니다.
아니 오히려 배부르시면 안됩니다. 그곳에서 더 성장하기 힘들다는 뜻이니까요.
개발자 사이에서 유명한 짤
위 짤은 개발자 사이에 유명한 짤이죠.. 이 짤은 누구를 비난하는게 아닙니다.
오히려 내가 과거의 나보다 더 성장했다고 나타내는 긍정적인 짤인겁니다.
저런 상황이 일어나는게 오히려 긍정적인 상황이라는 겁니다.
'개발관련 > 정보' 카테고리의 다른 글
| 개발관련 npm WARN config global --global, --local are deprecated. Use --location=global instead. (0) | 2023.07.04 |
|---|---|
| 개발관련 - VSCode(Visual Studio Code) 한국어 패치 (0) | 2023.07.04 |
| 개발관련 - Postman (포스트맨) (0) | 2023.07.03 |
| 개발관련 - 코딩 테스트 사이트 추천 / 기업 코테용 프로그래머스 (0) | 2023.07.03 |
| 개발관련 - C언어 프로토타입(Prototype) (0) | 2023.07.03 |