[TIL-182] 시뮬레이션 복습, 자바의 예외와 인터페이스, 플루터 실습

[그림1]. 오늘도 감사한 공부 시작 ~

 

목차

0. 오늘의 학습 시간
1. 오늘 배운 것
2. 오늘의 알고리즘
3. 오늘의 CS
4. 영어 받아쓰기
5. 내일 할 일 (청사진)
6. 감사한 일

 

0. 오늘의 학습 시간

07:00 ~ 08:00: 본가에서 회사 출근하는 기차 안에서 공부 
08:30 ~ 09:00: 회사까지 뛰어가서 30분 짜투리 공부
11:30 ~ 12:00: 점심시간에 토스트 먹으면서 공부
20:00 ~ 24:00: 개인 플젝 개발 및 공

 

1. 오늘 배운 것

- 오늘은 map을 쓰면 안되는 이유에 대해서 고민해봤다. 주변에 서비스 기업 사람들은 "지뢰를 깔아놓는 것", "그냥 멍청한 것"이라는 원색적인 비난을 해댔는데, 사실 우리 회사에선 map을 상속받아 재정의한 클래스를 통해 모든 요청과 응답값을 처리한다. 우리는 SSR 서비스라 API 명세가 엉망이더라도 아예 개발이 안될 정도는 아니긴 해서 기존에  이미 MAP으로 가득찬 방대한 레거시에 DTO를 도입하는게 과연 정말 효율적인 일일까를 고민해봤다. 

결론은 DTO를 도입하는 게 정답은 아닌 거 같다.  이유는 여러가지가 있는데, 애초에 현재 깔린 모든 커스텀한 MAP을  DTO로 교체하는  건 위험할 뿐더러 작업 비용이 매우 크다. 또 팀원들이 현재 요청, 응답값 관리에 대해 크게 불편함을 느끼지 못하고 DTO 도입에 대한 긍적적인 반응도 절반 정도이다. 어쨌든 객체지향이든, 남들이 말하는 화려한 기술이던, 그 목적은 "유지보수성, 협업의 용이성"이 목적이라고 생각한다. 정말 예외적인 상황을 생각해도 우리 서비스가 그 정도로 훌륭한 객체지향 서비스일 필요가 있는지에 대해선 아직 내가 부족해 납득하지 못한 이유도 있다.

[회고]
어쨌든 결론은 금융사 레거시 코드속에 쌓여 "정말 의미있는 서비스 기업에 가고 싶다는 꿈"이랑 점점 멀어지는 느낌이 자꾸 나를 불안하게 만들었던 거 같다. 그 와중에도 화려한 남들의 말들에 현혹되지 않고, 우리 서비스에 진실로 필요한게 뭔지 고민해볼 수 있어서 감사한 하루였다.

// 플루터 위젯 만들기 실습

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

// stless 단축키로 등록
class MyApp extends StatelessWidget {
  const MyApp({super.key});
  @override
  Widget build(BuildContext context) { // class 선언부터 여기까지는 그냥 세팅 문법, 무시해도 됌

    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(
          backgroundColor: Colors.blue,
          title: Text("test"),
        ),
        body: Container(
          child: Text("Hi")
        ),
        bottomNavigationBar: BottomAppBar(
          child: Container(
            color: Colors.white,
            child: SizedBox(
              height: 70,
              child: Row(
                mainAxisAlignment: MainAxisAlignment.spaceEvenly,
                children: [
                  Icon(Icons.phone),
                  Icon(Icons.message),
                  Icon(Icons.account_box_rounded)
                ],
              ),
            ),
          ),
        )
      )
    );
  }
}

 

2. 오늘의 알고리즘

시뮬레이션 파트 문제를 간단하게 풀어봤다. 내일부턴 완전탐색 한번 쓰윽 다시 훑고 코테용 알고리즘으로 넘어가려 한다.

 

3. 이주의 CS

[2023-12-18]
- 자바에서 .class 파일을 만들 수 있는 건 class 만 있는 게 아니라 interface, abstract 클래스도 존재한다.
- 인터페이스의 역할은 구현된 클래스는 관심 둘필요 없이 인터페이스를 이용해 작업할 수 있도록 하는 것이다.
-  이에 대한 일반적인 예시는 DAO(Data Access Obejct)이다.
-  인터페이스와 abstrtact를 사용하면 "개발할 떄 기능 구현에만 집중 가능", "개발자 역량에 따른 메소드 이름, 매개 변수 선언의 편차 줄일 수 있음", "공통적인 인터페이스와 abstract 클래스 선언을 통해 선언과 구현 구분"등의 이점을 얻을 수 있다.
- Enum이라는 상수의 집합도 있는데, 열거형 클래스로서 어떤 클래스가 상수만으로 만들어져 있을 경우에는 반드시 class로 선언할 필요 없이 ENUM을 써주면 된다.
- 사실 예외의 종류는 checkedException, uncheckedException(Runtime Exception), error로 세 종류이다. 
- 모든 Exception과 에러의 부모 클래스는 당연히 Object 클래스이지만 또 다른 공통 부모 클래스가 있는데 바로 Throwable 이다.
- getMessage, toString, printStackTrace등의 메서드 들도 Throwable의 추상 메서드들이다.
- throws로 예외를 직접 만들어 던질수도 있는데, 이 경우 받는 클래스에서 try-catch로 잡아줘야한다.
- 근데 컨트롤러 어드바이스 같은걸 이용해 알아서 받아주도록 할 수도 있다.

 

4. 오늘의 무자막 시청

오늘의 영상: 라따뚜이 (중반)
- 주인공(쥐) 엉겹결에 주방에 들어갔다 도망 나오는 길에 못참고 수프 요리를 해버렸다.
- 근데 그게 신참이 얼탈 동안 고객한테 나갔는데 고객이 유명한 미식가여서 너무 맛있다고 다음에 한번 더 요리해달라고 부탁한다.
- 원래 쓰레기 치우는 역할을 하던 신참이 다시 요리를 해야 하는 상황이 됐다.
- 그 와중에 도망치던 주인공(쥐)가 셰프한테 걸려서 흠씬 뚜드려 맞고 신참 요리사한테 잡혔는데, 주방장이 그 쥐를 버리고 오라고 해서 강가에 던지러 갔다.
- 마음이 약해진 신참 요리사는 쥐한테 말을 걸었는데 쥐가 말을 알아듣자 자기가 미친 게 아니였다고 너가 요리한 거 맞으니까 한번 더 해달라고 부탁한다. (근데 미친 거 맞는 거 같은데 ..)
- 그렇게 신참 요리사의 집에서 한 숨 자고 아침도 같이 먹고 다시 주방으로 향한다

 

5. 내일 할 일 (청사진)

1. 자바의 신 마저 공부하기
2. 점심시간에 코드 트리, 프로그래머스(sql) 풀기
3. flutter 앱 개발 공부
4. 점심시간 끝나기 30분 전에 네트워크 공부하기

 

6. 감사한 일

오늘 늦잠잤는데 기차 연착되서 시간 딱 맞게 잘 탔다. (ㅋㅋ) 그래서 감사하다.

 

 

오늘 하루도 공부할 수 있어 크게 감사합니다

2023-12-18 개발자 최찬혁