안 좋은 코드 시리즈 1탄

 

 

 

안 좋은 코드란?

 

1. 모호한 이름 (Mysterious Name)

함수, 변수, 클래스 ,모듈 등 이름을 모호하게 작성하는 것.

만약 명확한 이름이 떠오르지 않는다면 프로젝트의 설계에 문제가 있을 수도 있다!

 

2. 중복 코드 ( Duplicated Code)

똑같은 구조를 반복하는 것은 최악이다.

하나의 클래스 안에 비슷한 함수가 있다면 중복되는 부분을 함수로 추출하자.

 

3. 긴 함수 (Long function)

짧은 함수는 재사용성이 좋고 코드를 공유하기 쉽다.

하나의 함수를 길게 만들기 보다는 짧은 함수를 여러 개 호출하는 구조가 훨씬 좋다.

(코드 줄 수가 중요하다기보다는, 가독성이 좋아야 한다.)

 

알고리즘 문제풀이의 경우는 성능이 1순위, 가독성이 2순위.

 

4. 전역 변수의 남용

전역 변수는 어디서나 변경이 가능해서

1) 변경 시점을 추적하기 힘들고

2) 디버깅도 어려워지고

3) 버그의 원인이 되기 쉽다.

 

전역 데이터를 써야 한다면 변경되지 않도록 캡슐화 하는 습관을 가져야 함 (get set 방식)

 

5. 주석의 남용

코드는 주석이 없어도 이해할 수 있는 것이 제일 좋다.

코드만으로도 타인이 명확히 이해할 수 있는 코드가 좋다. 

주석이 필요한 상황이라면 주석이 필요없는 코드로 바꾸는 게 우선.

 

주석은 복잡한 함수의 제작 의도, 예외처리 등을 담는 용도로 사용하면 좋다.

 

 

Unity 에서 script 작성 시 주의사항

 

Random.Range 사용 시 주의사항

상위에 using System; 과 using UnityEngine; 이 같이 있으면 충돌할 수 있다.

둘 다 랜덤값을 사용하기 때문.

따라서 해당 스크립트에서 Random.Range 를 쓰기 위해서는 사용할 네임스페이스만 남기고 삭제해야한다.

 

Workflow 가시화 - 효율적인 팀 프로젝트를 위해

 

팀장님께서 팀 프로젝트의 제한된 시간을 효율적으로 사용하기 위한 방법을 소개해주셨다.

바로 JIRA 라는 workflow tool 이다.

 

팀원 모두가 팀 프로젝트 방향성과 진행 흐름을 파악하고 있는 것이 시간 관리에 매우 중요하다.

이런 추상적인 부분을 가시화할 수 있는 방법은 시간관리 도구를 사용하는 것이다.

JIRA를 사용하면 직관적인 인터페이스로 팀원이 어떤 위치에서 어떤 일을 하고 있는지 확인할 수 있다.

따라서 작업공백을 최소화할 수 있고, 중복 작업을 없앨 수 있다.

 

* 알짜 협업 상식

스프린트 : 게임사가 많이 사용하는 방식으로, 테스트를 빠르게 진행하는 workflow 절차

빌드를 짧은 주기로 완성해 테스트하고 다음 빌드로 넘어간다.

깃허브에 1.0  => 1.1 => 1.2 이런 식으로 빌드업이 되는 것도 스프린트 방식의 예시이다.

 

 

오늘의 회고

 

주말 안에 Unity_숙련 강의를 모두 듣는 것을 목표로!!

주 80시간 몰입을 향하여 아자아자!