첫 번째로는 글은 본인을 나타낼 수 있는 가장 쉬운 방법 중 하나인 점이다. 특히, 말로 표현하기를 어려워하는 사람들에게 글은 충분한 시간을 가지고 작성할 수 있으니 스스로를 표현할 수 있는 최선의 방식이라 느껴졌다.
두 번째로는 언제 어디로 갈지 모르는 개발자의 숙명(?)에 도움이 된다는 점이다. 진행했던 업무들의 히스토리를 기억하는 것은 필수이지 않나 싶다. 과거 면접에서 분명히 내가 했던 일이었지만 기억이 나지 않아 얼레벌레 이야기하면서 화끈거렸던 적이 있다. 기록이 있었다면 기억을 떠올리는데 훨씬 도움이 되었을 것이다.
그래서 휘발되는 기억에 의존하기보단 기록으로 남겨둬야겠다고 생각했다.
과거에도 다양한 방식으로 글쓰기를 시도했던 적이 있다. 하지만 꾸준함으로 이어지진 못했다. 이유가 뭘까 곰곰이 생각해 봤다.
기록을 어렵게 생각했던 점이 가장 큰 원인이 아니었을까 싶다.
잘못된 것을 쓰면 안 된다는 강박은 글을 쓰는데 허들이 되었고
잘 읽히는, 재밌는 글을 써야 한다는 생각은 고민만 키우고 기록으로 이어지지 않았다.
최근에 느낀 것은 이런저런 걱정들은 차치하고 ‘JUST DO IT’ 이 중요하다는 것이다.
고민만 하다가 시도 조차 하지 못한 것보다 가볍게 생각해서 일단 시도하는 것이 더 가치가 있다.
시도를 해야지 잘못된 것을 고칠 수도 있고, 피드백을 통해 나도 발전할 수 있다.
지금 이 글도 기록에 대해 어려워할 때마다 나의 마음을 다시 상기시킬 수 있도록 작성 중이다.
마음가짐을 바꾸고 나니 쓰고 싶은 글감이 많아졌다.
나를 브랜딩 할 수 있는 여러 가지 방법 중 올해 처음으로 시도하는 행동으로 기록을 선택했다.
당장의 넘치는 열정을 금방 소진시키지 않기 위해 일주일에 1회 작성을 목표로 가져가려고 한다.
@EnableJpaAuditing
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
2. 엔티티에 콜백 리스너를 추가한다.
@EntityListeners(AuditingEntityListener.class)
@Entity
public class Line {
3. 생성 날짜와 마지막 수정 날짜 프로퍼티에 @CreatedDate와@LastModifiedDate를추가한다.
@EntityListeners(AuditingEntityListener.class)
@Entity
public class Line {
@CreatedDate
private LocalDateTime createdDate;
@LastModifiedDate
private LocalDateTime modifiedDate;
4. @MappedSuperclass 를 사용해서 abstract class를생성해서사용한다면 중복코드를 분리할수있다.
비교 엔티티 비교시에는 식별자만 있어도 충분하다.
좀 더 디테일한 JPA 관련 내용은 추후 해당 블로그에 기재하도록 하겠다.
3주 차 미션에 대한 피드백
. 매직넘버는명명된상수로치환해서사용하기
// AS-IS
public class Calculator {
public int splitAndSum(String text) {
String[] numArr = Splitter.split(!isEmptyOrNull(text) ? text : "0");
//TO-BE
public class Calculator {
private final static String ZERO = "0";
public int splitAndSum(String text) {
String[] numArr = Splitter.split(!isEmptyOrNull(text) ? text : ZERO);
//AS-IS
private static List<Car> mapCars(int carNums) {
List<Car> cars = new ArrayList<>();
for (int i = 0; i < carNums; i++) {
cars.add(new Car());
}
return cars;
}
//TO-BE
this.cars = Arrays.stream(splitCarNames(carNames)).map(name -> new Car(name)).collect(Collectors.toList());
전략패턴 사용 => 자동차가 움직이는 규칙을 독립시킬 수 있다. 규칙이 독립되면 테스트도 용의해진다.
public interface MoveStrategy {
boolean isMove(int value);
}
=> 이동 규칙 관련 인터페이스를 생성
public class RandomMoveStrategy implements MoveStrategy {
private static final int START_CONDITION = 4;
private static final int END_CONDITION = 9;
@Override
public boolean isMove(int value) {
if(value >= START_CONDITION && value <= END_CONDITION) {
return true;
}
return false;
}
}
=> 인터페이스를 구현한 실제 적용할 규칙 클래스를 생성
public class Racing {
private List<Car> cars;
private MoveStrategy moveStrategy;
public Racing(String carNames) {
this.cars = Arrays.stream(splitCarNames(carNames)).map(name -> new Car(name)).collect(Collectors.toList());
this.moveStrategy = new RandomMoveStrategy();
}
public void race() {
for (Car car : cars) {
car.racing(RacingCarUtils.randomValueGenerator(), moveStrategy);
}
}
}
시작 전 설계에 대한 깊은 고민 없이 개발하다 보니 자주 수정이 발생. => (테스트 코드도 수정이 자주 발생, 커밋할 시점 잡기 어려움, 복잡해짐)
개발 전 꼼꼼한 설계에 대한 중요성 다시 느낌.
기능의 역할 정의에 어려움 => 입력한 야구 번호 검증하는 로직을 어디서(baseball.class or resultChecker.class) 처리하는 게 맞는지 고민이 많았음
도메인별 명확한 역할 할당, 다른 도메인에서 사용할 땐 메시지를 전달하여 결과만 받아오도록 처리(캡슐화) => 참조 depths(dot)를 한 단계로만 처리하도록 함. ex) result.getBall().getBallCount (X) -> result.getBall()
회고
: 첫 시간이었고 현재 서비스에서 Node.js를 이용해서 개발하다가 오랜만에 java를 이용해서 개발하니 친정에 돌아온 듯 재미있었다. 잊고 있었던 원칙들이 새록새록 생각나서 즐겁게 고민하면서 코딩했다.
