[공통개발] 개발 더 잘하는 방법 [나만의 팁] [추가중]

📝비난이 아닌 사실을 이야기해라

 

📝프레임워크에 맞는 기술을 써라

• 스프링프레임워크를 쓰며 스프링프레임워크에서 만든 걸 쓰는게 좋다 (스프링이 아니라 그 안에서 서블릿을 쓴다는 등에 행위는 지양하는 게 좋음) 그리고 웬만해서 유명한 걸 써라

 

📝개발자는 자기 영역에만 최선을 다한다

• 개발은 기본적으로 잘해야(다양한 기술 선택지)하며 같이 협업하는 기획자, 디자이너 등… 다양한 직군 존중을 해야한다 만약 정말 필요한 의견을 낼 때는 상대방의 허가 또는 조심스럽게 양해를 구하며 이야기를 한다

 

📝라이브러리를 활용할 때 공식버전의 라이브러리를 사용하고 의존적이지 않는게 좋다

• 예를 들어서 Oracle DB에서 제공하는 테스트 함수가 있고 Java표준인 Javax의 테스트 함수가 있는데 Oracle DB에서 제공하는 테스트 함수를 사용할 경우 여러가지 Side Effect가 생길 수 있다길 수 있다. 만약 MySQL로 변경했을 때 MySQL에 있는 테스트 함수는 Oracle이나 다르거나 없을 경우 모든 코드를 수정해야할 수 있다 그리고 스프링의 의존적이면 스프링 프레임워크가 구축되어야 테스트나 할 수 있기 때문에 제약사항이 많이 생긴다 [스프링 점유율이 어마무시해서 이 부분은 거의 Trade off 가 없긴 하다]

 

📝공부는 복리이다

• 빨리 배우는게 좋다 앞서 배운 내용으로 다음 공부를 하기 수월해진다

 

📝사용하는 제품의 호환성을 따져라

• 어떤 버전을 쓰느냐는 정말 중요하다 여러 프로그램을 쓸텐데 그 프로그램들 끼리 버전호환이 안 되면 잘 만들었어도 안 돌아간다
• 예) jdk 버전이 다른 경우 , 톰캣 버전이 다른 경우 등...

 

📝API 등 비즈니스 로직을 만들 때 다른 이상한 값을 못 넣게 아예 사전에 차단하도록 설계해라

1. 예를 들면 Code를 String으로 선언한 경우 01, 02 이렇게 넣어야하는 경우 어떤 사람이 04 이런식으로 넣어서 문제를 일으킬 수 있다. 만약 Enum을 이용한 자료구조를 사용한다면 사전에 에러를 방지할 수 있다
2. 운영 디비에는 접근 못하도록 막던가 계정 권한을 달리주는 등 반드시 필요한 조건이다

 

 

📝나의 프로젝트를 공유할 때 WAS와 IDE도 같이 배포한다.

• 위와 같이 제품 호환성 때문에 다른 환경에서도 돌아가기 위해서 IDE(이클립스)와 1개의 프로젝트(workspace)와 1개의 WAS(Tomcat)를 세트로 묶어서 제공해준다.

 

📝여러번 확인하기

• 문서를 배포하든 프로그램 테스트를 하든 문자를 보내든 여러번 검토한다.
• 문자나 이메일의 경우 2 ~ 3번 정독을 하고 문서를 배포할 때도 2 ~ 3번 정독을 한다.
• 프로그램 테스트를 하고 문제가 생겨서 고친 후에는 다시 처음부터 테스트를 다시 시작한다. (관계 있는 부분 즉, 영향을 받는 부분은 모두 다시 테스틀 처음부터 다시해야한다)

 

📝문서화를 잘 해라

• API 명세 등 아무것도 모르는 상대방이 읽었을 때 읽기 쉽고 이해하기 쉽게 만들어야한다.

 

📝버그가 일어날 시

• 해당 버그 원인 파악 후 직접 재연 후 해당 버그 고치고 다시 해당 버그 재연해 테스트해 문제 없음 증명 후 배포한다.

 

📝피드백을 잘해라

•  내가 하는 일이 맞는지 능동적으로 움직이며 체크한다 (내가 하는 일이 이게 맞는지 상사에게 체크를 한다)

 

📝외부 일정은 최대한 길게 잡아라

• 아직 고민중... 하지만 너무 짧게 잡지는 마라... 전 회사가 너무 병신같아서 5일 걸릴 일 하루만에 끝내라고 한 경우가 부지기수라 밤새서한 적도 부지기수였음

 

📝데이터 관리를 잘해라

• 값을 넘겨받을 때 "빈값"인지 체크하고 Default 값을 넣던가 반드시 필요한 값이면 required로 에러를 방지해야한다

 

📝개인면담을 가져라

• 팀장인 경우 개인 면담을 가져서 일에 대한 불만 및 이슈사항이 있는지 체크를 해야하고 개선해야 한다.

 

📝말 잘 하는 법

1. 예시를 들며 설명하고 맨 마지막에 결론을 한 번 더 이야기하기
2. 상대방의 이야기를 듣고 생각한 다음에(3초 이상+심호흡) 이야기하기 [재촉시에는 잠시만요 컨트롤하기]
3. 아이컨택과 제스처가 중요하다
4. 여러 사람과 이야기할 때는 한 문단씩 이야기하면서 시선을 옮겨가며 이야기하기

 

📝DB 설계

• 너무 큰 확장성을 고려한 설계는 독이 될 수 있으므로 조심해야한다.

 

📝프로젝트 산정일 설정

• 야근해서 개발을 마치거나 미리 리소스를 크게 잡아 일을 시작하게 되면 개발자나 회사 모두에게 부담이 될 수 있기 때문에 개발자는 자기자신의 개발 속도를 객관적으로 판단할 수 있는 능력이 필요하다 → 자신의 실력 및 맡은 일이 어느정도 공수가 드는지 알 수준이 되어야 판단할 수 있다 즉, 어떤 일이고 어떤 프로세스로 돌아갈 지 사이드이펙트 등 많은 경우의 수가 떠올라야한다

 

📝실력이 늘지 않는다

1. 적절하지 않은 난이도
   1. 너무 낮으면 지루함을 느끼고 너무 높으면 불안감을 느끼게 되니 알아서 조절을 잘 해야한다
   2. 높은 경우는 버텼을 때 차라리 도움이라도 되는데 너무 낮으면 진짜 정체다
2. 회사 문화
   1. 새로운 기술을 두려워하지말며 적용시키며 피드백을 받고 실수를 고쳐나갈 수 있는 환경이 필요하다 즉, 실수를 잘 들어줄 수 있는 회사 환경이 중요하다
3.  본질을 이해해라
   1. 그냥 무작정 가져다 쓰는게 아니고 심도 있게 이해를 한다면 [데이터의 흐름 등...] 다른 프레임워크나 기술을 쓰더라도 많은 도움이 된다