성장하는 개발자

서론

SI 기업을 다니면 정해진 일정에 쫓겨서 개발을 한다. 마감 기한까지 맞추기 위해 기능은 돌아간다. 이 프로그램이나 웹 사이트가 지속적으로 운영이 된다. 지속적으로 운영이 되면 유지 보수를 필수적으로 해야 한다. 프로그램이나 웹 사이트는 만들고 나서 끝이 아니라 사용자가 필요로 하는 기능이나 운영되면서 에러가 나는 부분을 추가 및 수정해야 하는 경우가 온다.

그때 기능만 돌아가던 부분을 수정한다. 운영되고 있는 시스템의 소스 코드가 기능만 돌아가고, 복잡한 코드라고 가정을 해보자. 복잡한 소스 코드가 눈 앞에 있다. 그러면 이 소스 코드를 해석을 하고, 어떤 기능이 관련되어 있는지 파악해야 한다. 파악하는데 시간이 오래 걸리면 필요한 기능 개발하는데 있어서 시간이 많이 소비된다. 그러면 이 소스 코드는 좋은 코드가 아니다.

좋은 소스 코드로 개발하기 위해 개발자는 어떻게 개발을 해야 좋은 소스 코드를 짤 수 있는지 고민해야 한다.

 

좋은 소스 코드란?

첫 번째로 가독성이 좋아야 한다. 저장하는 기능을 가진 소스 코드가 있다고 가정을 하자. 그러면 그 코드엔 저장하는 기능만 있다고 생각한다. 하지만 저장하는 소스 코드에 신규로 저장하는 기능과 수정하는 기능을 조건문으로 분기를 한다. 저장 기능을 가진 소스 코드는 신규로 저장되는 기능과 수정되는 기능이 같이 있다.

같이 있기 때문에 소스 코드를 처음부터 끝까지 해석하는 데 시간이 걸린다. 이 소스 코드는 좋은 코드가 아니다. 저장하는 기능의 함수면 저장만 처리해야 한다. 저장하는 기능이면 저장하는 기능이 있어야 한다. 그리고 수정하는 기능은 별도로 있어야 한다. 해당 기능만 있어야 소스가 쉽게 읽힌다.

왜냐면 기능 개발만 해서 끝나지 않는다. 유지 보수도 할 수 있다는 걸 생각해야 한다. 아니면 해당 기능과 관련해서 기능이 추가되는 요청 사항이 있다. 아니면 사용자는 개발한 기능에서 조금 더 수정을 원한다. 편의성을 원하는 게 사용자기 때문에 사용자에게 맞춰주는 게 좋다. 젠장...

두 번째로는 유지 보수성이 좋아야 한다. 유지 보수성이 좋은 건 새로운 기능이 추가되면 곧바로 기능이 추가 개발할 수 있다. 기능 별로 코드를 작은 단위로 나누면 새로운 기능이 추가되어도 개발이 쉽게 된다.

소스 코드는 기능 별로 나뉘어진 게 좋다. 추가 요청 사항이 들어와도 해당 기능에서 나누어주면 된다. 소스 코드는 기능 별로 나누어 주는 게 좋다.

 

개발자 실력에게 필요한 것

개발자의 실력을 판가름 하는 건 좋은 소스 코드를 작성하는 것과 운영 중인 시스템을 효율적으로 작동하게 하는거다. 효율적으로 작동하게 만드는 건 주니어 개발자들에게는 쉽지 않다. 연차가 쌓이면 경험하는 게 많아진다. 많아진 경험을 토대로 시스템을 효율적으로 만든다.

 

예를 들어서 스프링으로 운영중인 웹 사이트가 있다. 동일한 데이터를 DB에 넣을 때 데이터를 가공했다. 여러 건의 데이터를 한 건 넣을 때마다 Mybatis로 작성된 Insert 문을 데이터를 다 넣을 때까지 쿼리문을 계속 호출하는 건 자원 낭비가 심하다. 동일한 Insert문을 매번 호출하는 것보다 Insert문에 넣을 데이터를 Mybatis에 List 형식으로 담아서 넘겨서 DB가 처리하게 만든다.

 

그러면 스프링에서는 Insert문을 한번만 호출하면 되고, 나머지는 DB에 맡기기 때문에 DB에 값이 제대로 들어가게 처리하면 된다. 그리고 서비스 속도도 더 빨라진다.

 

서비스 속도가 향상되고, 효율적으로 돌리기 위해선 선임이 있으면 물어보거나 혼자 생각을 해보고 자료를 찾아본다. 그리고 사이드 프로젝트를 진행해서 직접 처리해보는 것도 좋은 방법이다.

스스로 생각하고 연구를 해본 후 자신만의 개발자 노트를 만들고, 커뮤니티나 자신의 블로그에 올려놓으면 좋다. 자신과 똑같은 문제로 고민했을 개발자들이 있기 때문이다.