좋은 코드란?

모든 팀원이 이해(understandability)하기 쉽도록 작성된 코드인 것 같다.

좋은 코드, 클린 코드에 대한 정의는 많지만, 내가 실무에서 봤을때 좋은 코드라고 느꼈던 부분은,

1. 알기 쉬운 변수명, 함수명
2. 읽기 쉬운 코드
3. 중복을 줄인 코드

사실 일하다보면, 정말 많은 클린코드의 원칙, 좋은 코드의 원칙을 지키기란 정말 어려운 것 같다.
이후에 리팩토링을 하더라도, 우선적으로 내가 실무를 하면서 지키고 있었던 나만의 코드 룰을 몇가지 소개해보려고 한다.

변수,함수명 잘 짓기

나는 영어를 아주 잘하지 못한다.
그래서 그런지, 뭔가 내가 한눈에 봐도 딱 알아차릴 수 있는 변수명과 함수명을 좋아한다.
내가 알아볼 수 있다면, 남들도 당연하게 알아볼 것이라고 생각한다ㅎ

나는 변수명 지을때,

1. 명사에 가깝게 짓기 (단수형으로)

 const editMode  //수정모드;
 const folder  //폴더 

2. 배열일때는 여러개인걸 명시 (복수형으로)

 const selectedItems = // 선택된 아이템들

3. 함수의 역할 (어떨때 실행되는 함수인지)

개인적으로 함수명 짓기가 제일 어려웠다.
뭔가 어느정도까지 함수의 역할을 함수명에 적어줘야하는지 감이 잘안왔는데

예를들어 초기화 버튼을 클릭 후, 진짜 초기화 하냐는 alert가 있을때
clickOpenResetAlert를 처럼 함수 동작에 관해서 써줘야할지
View 그대로 초기화 버튼을 클릭하다. 라는 것에 관해서 써줘야할지 너무 애매했다.
하지만 나의 선택은 View와 가깝게 작성을 했고 무조건 동사로 작업했다.

view에 가깝게 이름을 지은 이유는,
누군가 내 코드를 고쳐야하는 일이 생길 경우에 화면을 동작하면서 볼 가능성이 더 높을 것 같다고 생각했다.
그래서 좀 더 화면을 동작하자마자 알 수 있는 직관적인 이름을 지으려고 했다.

const clickViewTotalPrice = // 총금액보기를 클릭하세요
const clickReset = // 초기화 버튼 클릭 후 alert
const clickConfirmReset = // alert에 초기화 클릭

읽기 쉬운 코드

1. props로 내려주는 interface 정리

위는 변수, 아래는 함수로 정리해서 항상 작업해줬다.
확실히 어떤 정보들을 받고, 어떤 행동들을 하는지 한눈에 구분이 되서 보기 편리했다.

interface ViewProps {
	searchKeyword : string;
    items : Item[];
    onChangeSearchKeyword : () => void;
    onClickEditMode : () => void;
	onClickItem : () => void;
}

2. import 쪽도 정리 (개인적..ㅎ)

회사 코드 이외의 외부 사람들의 코드를 보는 버릇을 들이진 못했다.
남이 짠 코드도 많이 봐야한다고 하는데
이건 그냥 내 취향이다.. 나는 {} / * as /
이런 순서로 정리하거나, 기능 관련으로 import 를 정리되어있는 코드를 보기 편해한다.

import React, { useState } from "react";
import { Widgets } from "app/view";
import { Util } from "app/view-model";
import * as DataModel from "app/service/settlement-input/data-model";
import styled from "styled-components";
import useDebounce from "app/service/hooks/useDebounce";

3. 조건문 보다는 switch가 더 나을수도

사실 회바회 인 것 같다.
회사에서도 switch 문을 더 선호했고, 나도 줄줄이 늘어져있는 if else / ? : 보다는 가독성이 swich가 더 낫다고 생각한다.

	if(yellow){
    	로직
    } eles if(red){
    	로직
    }
    else{
    	로직
    }
    
	switch (color) {
    	case "yellow" :
        로직
        case "red" :
        로직
    }

중복을 줄인 코드

1. 컴포넌트 분리

자주 사용 되고, 반복적으로 발생되는 위젯,컴포넌트,코드들은 재활용 할 수 있게 컴포넌트로 분리해서 작업해준다.

2. util 사용, custom hooks 사용

함수가 너무 자주사용되고, 반복적으로 발생된다면,
util 폴더를 생성해서, 계산하는 함수, 날짜를 구하는 함수를 사용해서
import 해서 꺼내쓰는 식으로 구현하는 편이었다.

//util 폴더안에 있는 함수
  getSliceTime = (saveTime: string) => {
        const now = new Date(saveTime);
        const hours = now.getHours();
        const minutes = now.getMinutes();
        const seconds = now.getSeconds();
        return `${hours}:${minutes}:${seconds}`;
    };

   validatePhoneNumber = (phonenumber: string) => {
        const regex = new RegExp(/^(010|011)[0-9]{3,4}[0-9]{4}$/g);
        return regex.test(phonenumber);
    };

//custom hooks
import React from "react";

export default function useInnerWidth(): number {
    const [innerWidth, setInnerWidth] = React.useState<number>(window.innerWidth);

    React.useEffect(() => {
        window.addEventListener("resize", setWidth);

        return () => {
            window.removeEventListener("resize", setWidth);
        };
    }, []);

    const setWidth = () => {
        setInnerWidth(window.innerWidth);
    };

    return innerWidth;
}

함수 쪼개기

서로 다른 두 대상을 한꺼번에 다루는 코드를 발견하면 각각을 별개모듈로 나누는 방법이다.

예를 들어 입력값이 처리 로직에 적합하지 않은 형태로 들어오는 경우,
본 작업에 들어가기 전에 입력값을 다루기 편한 형태로 가공한다.
혹은 로직을 순차적인 단계들로 분리하거나 해도 된다.

하나의 함수를 잘게잘게 쪼개서 적절한 이름을 짓고 나눠서 작성하는게 중요하다.
함수를 잘게 쪼개서 관리하면 디버깅 하기도 편리하다.

1. get 함수는 따로 빼준다.

나는 회사에서 작업했을때 get 관련 함수는 꼭 따로 빼줬다.
언제 어느때에 정보를 불러올지 모르고, get 함수는 게다가 복잡성이 커질 우려가 높았다.

그래서 init함수에다가 get 함수를 분리하지 않고 그냥 넣었을경우, 디버깅이 너무 어려웠고
코드 자체가 읽기 싫어지고 어려웠다.

약간 모듈화에 가깝게 생각해서 get 함수들을 다 모듈화 시켜놓고
필요한 함수들에서 불러오는 식으로 진행했더니 함수가 너무 깔끔해졌었다.

(React.query를 쓰고나서는 진짜..극락..)

2. Private Method, 큰 함수를 작은 함수로 분리

회사 실무코드에서는 DataModel이란 클래스를 생성해서 프론트에서 가져다쓰기 좋게 가공해주는 영역이 있었다.

Private Method: 클래스 내에서 특정 함수가 다른 함수에 의해만 호출될 경우,
그 함수를 클래스의 내부(private) 메서드로 만들어 정보 은닉을 유지하고 클래스 인터페이스를 단순화시켰다.

큰 함수를 작은 함수로 분리 :
위와 비슷한 사례인데, 너무 함수의 역할이 커지면, 함수의 역할을 분리해서 작업 한 후
필요한 곳에서 실행시키는 방식이다.

결론

바쁜 스타트업이나 프로젝트 개발 시간이 제한된 상황에서 코드 품질을 100%까지 유지하려는 것은 현실적으로 어렵다고 생각한다.
마감 기한을 지키면서 완벽한 코드를 작성하는 것은 너무 이상적이다.
따라서 프로젝트 개발과 코드 품질 사이에는 trade-off가 필요하다고 생각했다.

그래서 나만의 최소한의 규칙을 정해서 이정도는 무조건 코드를 짤때
최소한의 조건을 지켜야지!하며 나와의 약속을 하고 코드를 짠다.

개발 프로세스 중에 코드 품질을 유지하기 위해 나만의 최소한의 규칙을 정하는 것은 중요한 단계다.
이러한 규칙은 개발하는 동안 코드를 작성할 때 필수적으로 지켜야 하는 기준으로써,
코드의 가독성과 안정성을 보장할 수 있다.

부족한 부분은 시간적 여유가 생겼을때 '클린 코드'나 '리팩토링'과 책을 통해 학습하고 코드를 평가하며 점차 품질을 향상시키는 데 노력해야한다고 생각한다.

여유가 생길때마다 리팩토링이란 책이나, 클린코드 책을 통해서
좋은 코드의 조건을 계속 숙지해 나아가면서 점차 시간이 여유로워질때는 리팩토링을 하고
실무에서 나와의 최소 조건을 늘려나가는 것도 하나의 방법이라고 생각한다.