Puppy's paw

투자자 - 시행사 - 하청업체 

시행사와 하청업체는 협력업체 관계

이런 구조에서 시행사에서 PM이 나오고

하청업체 개발자들(나)과 일을 한다.

하나의 일에만 전념한다면 프로젝트가 성공적으로 가겠지만

두 업체 모두 개발이 체계적으로 잡혀있지 않은 경우 참 힘들다.

만1년이 되가는 개발자(나) 매일 야근하면서 피곤에 쩔어 개발중

프로그램 전체 구조를 볼 수가 없다.

자꾸 뭔가 새로운게 생기지 않길 기도하고 걱정하면서 개발한다.

PM과 하청업체 관리자는 개발에 대한 관심보다 자기일 하기 바쁘다.

개발은 늦어지지고 본인들 생각과 결과물은 점점 거리가 멀어진다.

해야 할게 너무 많다. 개발 직접 도와줄거 아니면 나한테 아무말 안시켰으면 하는 마음

결국 시험테스트날 문제가 터진다.

시행사와 하청업체는 서로 말이 달라 티격태격

예상 했던 일이다.

어떻게 하면 이일을 막을 수 있었을 까

나한테는 어느정도 책임이 있는 걸까

어째든 다음에 내가 이런 일을 막으려면

아무리 개발할 시간이 부족해도 요구사항에 대한 우선 순위를 표를 만들어서

매일 보고하는 수 밖에 없을 것 같다.

내 실력이 어느정도 위치인지 계속 눈치를 봐왔지만 이제 그럴 필요 없는 것 같다.

그냥 지금 상황은 내가 주도해서 다 하는게 차라리 낫다.

개발일정이 조금이라도 늦어지면 철저히 보고를 해야 겠다.

답답하면 사람 더 뽑겠지

그리고 늦어지는 이유를 설명하고 야근은 배째야겠다.(하지만 그럴 수 있을까?)

물론 내 삽질로 늦어진거면 마무리 지어야한다.

답답하면 직접 개발하던가~

프로퍼티를 쓰는 것도 좋겠지만

왠지 enum이 멋져보인다.

javascript에서도 따로 네임스페이스를 둬서 관리하는 것이 좋은 것 같다.

javascript는 package가 없다

하지만 package.json 이라는 파일을 많이 본적이 있다.

아마도 프레임워크에서 쓰는 것으로 추측된다.

아는 프레임 워크는 없지만

javascript트도 package관리의 필요성이 절실히 느껴졌고

namespace를 package처럼 쓰기로 했다.

클래스 패키지는 아니지만

여러 사이트의 api를 짬뽕해서 쓰다보니(이런 프로젝트는 최대한 피하도록 합시다.)

관련 url 주소들을 패키지화해서 관리하는 것도 괜찮다.

값들을 final로 주고 싶지만 json 내부 요소들은 const지정을 할 수 없다.