• Real mysql을 읽다 평소에 궁금하던 mysql에서 varchar를 어떻게 다루는지에 대한 설명이 간략히 있었다.

• 기본적으로 아래 설명과 같이 255byte 까지는 prefix data로 1byte, 이후는 2byte를 사용하는 것은 알고있었다. 잘못 이해하는 경우 문자열의 길이로 오해할 수 있는데, encoding에 의한 byte에 대한 내용이므로 1글자당 4byte를 사용하는 encoding인 경우 약 63글자 정도만 prefix로 1byte만 사용하는 것이다.

  In contrast to CHAR, VARCHAR values are stored as a 1-byte or 2-byte length prefix plus data. The length prefix indicates the number of bytes in the value. A column uses one length byte if values require no more than 255 bytes, two length bytes if values may require more than 255 bytes.

• 책에서는 한줄요약 급으로 설명하고 있어서, 실제 Engine layer에서는 어떻게 구현되어 있는지 궁금했다.

한 줄 요약

• Temp table을 활용하는 경우 Mysql 5.7까지는 char와 동일하게 fixed-length를 사용한다.

설명

• Mysql 5.7에서는 일부 작은 데이터를 위해 Temp table을 활용할 때, Memory DB를 활용한다.
• Memory DB는 varchar를 fixed-length로 활용한다.

구현 확인

• sql_tmp_table.cc 에서 create_virtual_tmp_table 메서드같은 것을 통해 temp table을 만든다. record length는 아래와 같은 로직으로 설정된다.

  record_length+= (*field)->pack_length();

• pack_length 를 호출하는 것을 통해 record length를 구한다.

  /*
    pack_length() returns size (in bytes) used to store field data in memory
    (i.e. it returns the maximum size of the field in a row of the table,
    which is located in RAM).
  */
  virtual uint32 pack_length() const { return (uint32) field_length; }

• hp_write.c에서 아래 코드로 메모리 할당한 후 write한다.

  memcpy(pos,record,(size_t) share->reclength);

추가로 알게된 것

• HA_KEYTYPE_VARTEXT1, HA_KEYTYPE_VARTEXT2는 Mysql source code내에서 prefix 길이를 구분하기 위한 enum이다.
• Memory DB에서는 HA_KEYTYPE_VARTEXT1 로 통일해서 활용한다.
• share->db_low_byte_first=1; // True for HEAP and MyISAM 에 의해 temp table의 storage engine이 설정된다.
• key length도 더 많이 사용할 수 있다.

          /*
            For BTREE algorithm, key length, greater than or equal
            to 255, is packed on 3 bytes.
          */

결론

• Mysql8에서는 기본적으로 MemoryDB(heap)을 사용하지 않아서, 구현체가 다를 것이다.
• 어찌되었건 길이를 너무 늘려서 활용하는 것은 좋지 않다.

Reference

• https://dev.mysql.com/doc/refman/5.7/en/char.html
• https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html
• https://dev.mysql.com/doc/refman/8.0/en/memory-storage-engine.html

knwon-issue로는 @TransactionalEventListener를 활용하는 메서드에서는 @Async를 붙이지 않으면 오류가 발생하더라도 Debug로 로깅이 된다.

단순히 키워드 조합을 통해 검색하더라도 다른 개발자들도 Debug로 로깅이 되는 문제를 마주친 것을 알 수 있다. 해당 글들에서 설명하는 내용은

1. call stack을 분석했을 때, 스프링에서 debug로 로깅하고 있다.
2. Async 어노테이션을 통해 수정이 가능하다.
3. 혹은 여러 커스텀 로직을 추가해서 다른 처리가 가능하다.

인데, 이 수정이 왜 발생했는지 근본적으로 파악해볼 필요가 있다.

github의 blame을 통해 따라가다 보면

1. https://github.com/spring-projects/spring-framework/commit/95110d825715a70dbc7fadc0e3ebd42f44e6bdfb 를 통해 커스텀 콜백을 등록할 수 있게 되는 것
2. 수정 내용, 설명과는 무관하게 error level이 debug level로 바뀐 것

을 알 수 있다.

따라서 https://github.com/spring-projects/spring-framework/pull/30776 로 수정하니 바로 반영되었다.

시간 제한이 애매해서 어떻게 풀지 고민하다가

N개의 element를 first, second로 각각 구해서 연산해주는 방법을 활용했다.

N+1개의 element에서 first가 생긴다면, 1개의 elemen가 제외되고 큰 element들만 활용된다. ...

second도 같은 원리로 구해준 후 계산해주면 된다.

using ll = long long;
using pii = pair<int,int>;
class Solution {
public:
    long long minimumDifference(vector<int>& nums) {
        int N = nums.size() / 3;
        ll max_data[N*3];

        ll max_num = 0;
        priority_queue<int, vector<int>, greater<int>> lowest;
        for (int i = 2 * N; i < 3 * N; i++) {
            max_num += nums[i];
            lowest.push(nums[i]);
        }
        max_data[2 * N] = max_num;

        for (int i = 2 * N - 1; i >= N; i--) {
            lowest.push(nums[i]);
            max_data[i] = max_data[i + 1] + nums[i];
            max_data[i] -= lowest.top(); lowest.pop();
        }

        ll min_data[N*3];
        ll min_num = 0;
        priority_queue<int> highest;
        for (int i = 0; i < N; i++) {
            highest.push(nums[i]);
            min_num += nums[i];
        }
        min_data[N-1] = min_num;
        for (int i = N; i < 2 * N; i++) {
            highest.push(nums[i]);
            min_data[i] = min_data[i - 1] + nums[i];
            min_data[i] -= highest.top(); highest.pop();
        }
        ll result = 1e18;
        for (int i = N - 1; i < 2 * N; i++) {
            result = min(result, min_data[i] - max_data[i + 1]);
        }
        return result;
    }
};

접근 방법

1. arr[i] <= i 일 때, l~r 구간에서 조건이 성립하는지?(0 <= l, r < K)
2. l~r 뿐만 아니라 다른 구간까지 나머지 구간까지 구하면 된다.

prefix sum으로 풀 수 있다.

class Solution {
public:
    int bestRotation(vector<int>& nums) {

        ios_base::sync_with_stdio(false);
        cin.tie(0);
        cout.tie(0);
        int N = nums.size();
        int counts[N]; memset(counts, 0, sizeof counts);
        for (int i = 0; i < N; i++) {
            auto n = nums[i];
            int moves = 0;
            if (n > i) moves = i+1;
            counts[moves]++;
            if (n == 0) continue;

            int next = i;
            if (moves > i) next = N-1;
            moves += next-(n-1);
            if (moves < N) {
                counts[moves]--;
                if (i - moves >= 0) {
                    moves += i - moves + 1;
                    if (moves < N) counts[moves]++;
                }
            }
        }

        int result = 0;
        int tr = 0;
        int index = 0;
        for (int i = 0; i < N; i++) {
            tr += counts[i];
            if (result < tr) {
                index = i;
                result = tr;
            }
        }
        return index;
    }
};

요즘 TDD, BDD와 같은 방법론에 대해 여러 의견들이 있는 것을 보았다. 그 내용들과 무관하게 TDD를 공부하며 적용하고, 적절한 부분에서 사용하게 된 배경을 공유하고, 피드백을 받음으로, 다른 의견들을 보고 배우고싶어서 부족한 지식이지만 짧은 생각을 글로 남겨본다.

TDD

TDD라는 용어를 약 5년전에 용어를 처음 접했다. 그때 보이던 글들에 의해서는 red-green-blue와 같은 사이클을 가지는 개발 프로세스이고, 되게 좋아보였다. 정리해보면 결국은 테스트코드를 먼저 작성하고, 테스트코드를 성공하기 위한 로직을 작성한 후 리팩토링하는 프로세스이다.

TDD적용 사례 1

TDD를 한 번에 모든 업무에 도입하지는 않고, 일부 작업들에 활용했다. 첫 사례로는, 이미 만들어진 시스템에 버그가 발생했고, 이를 해결하는 과정에 적용해본 것이다.

그러면,

1. 문제가 되었던 파라매터들을 준비해서 regression test를 작성한다.
2. 의도된대로 실패하는지 확인한다.
3. 해결 후 동작이 잘 되는지 확인한다.
4. 1~3을 반복 이후 로컬 혹은 개발서버에서 실제 유저의 시나리오를 재현하며 동작이 잘 되는지 확인한다.

순서로 개발이 끝나게 된다. 이 과정에서는 4번을 가장 마지막에 할 수 있게되어 데이터 세팅, 브라우저 새로고침 등 번거로운 작업을 뒤로 미루게되어 효율적이었다.

즉, 테스트 실행을 IDE에서 간편히 할 수 있는 세팅과의 시너지가 있었다.

TDD적용 사례 2

하지만, 신규 기능을 새로운 구조로 구현할 때는 비효율의 어려움이 있었다.

테스트를 작성하며 새로운 모델, 코드 구조를 작성한다. => 작성 중인 코드 혹은 구상중인 코드가 비효율적이라고 판단되는 피드백이 느리다.

머릿속으로 코드 구조를 상상하고, 비효율적이라고 판단되면 다른 구조를 생각하는게 훨씬 빠르고 효율적이다. => TDD를 활용하면 무의식적으로 코드 작성에 집중하게 되어, 구조 개선에 집중이 안된다.

라는 결론이 나왔다.

TDD적용 사례 3

리팩토링에서도 TDD의 방법을 따와서 작업하면 효과적이다. 이미 기존 로직들에 테스트 코드가 있다면, 동작이 깨지지 않는 선에서 수정하기가 수월하다.

하지만, 테스트 케이스 및 테스트 코드가 없는 경우는 기존 동작이 유지된다는 100%확신을 할 수 없다. 따라서 테스트 코드를 만들어서 기존 동작을 보장시키고, 내부 구현 최적화를 하는데에는 자신감있게 작업할 수 있어서 좋았다.

결론

TDD방법론은 이상적인 시나리오를 위해 나왔다고 생각한다. 하지만 현실의 문제는 '시간 = 비용'이다.

따라서 적절히 TDD의 방법론의 방법을 엔지니어링에 적용하니,

1. 작업의 자신감
2. 작업의 속도

가 장점으로 작용되는 부분이

1. regression test
2. refactoring

에 있었다.

다른 부분들은 딱히 드라마틱한 이점이 없었다.

추후 읽어보면 좋을 글들

• Mockist testing, Classical testing
• Unit test
• How Much Testing is Enough
• Mutation Testing
• SHOULD PRIVATE METHODS BE TESTED
• Test Flakiness - One of the main challenges of automated testing
• Test Flakiness - One of the main challenges of automated testing (Part II

• 내 소개

회전 목마 문제 빼고 다 풀었다. 최근 골랜디를 하고 있는데, 효과가 있는 거 같다.

나중에 editorial이 나오면 남은 1문제도 풀어봐야지..

을 더한 게 7로 나눠지면 7의 배수이다.

1001을 통해 증명가능하다.

우선 6k+2까지만 보면 100a + 10b + c = 0 mod 7 2a + 3b + c = 0 mod 7

6k+345는 1001이 7의 배수인 것을 이용해서 증명

1001(100a + 10b + c) - 100a - 10b - c = 0 mod 7

-3a-2b-c = 0 mod 7 반복...

def check?(i)
  data = [1,3,2]
  @test = -1
  i.to_s.chars.reverse.map.with_index do |c, index|
    c.to_i * data[index % 3]
  end.inject(:+) % 7 == 0
end
a=0
1.upto(3000000) do |i|
  a=i
  if i % 7 == 0
    p "yes no #{i}" unless check?(i)
  elsif check?(i)
    p "no yes #{i}"
  end
end

로 답을 확인 가능하다.

• 집중력의 농도를 짙게 하기위해 해본다.
• 우선은 여러 가이드에 따라 5분 집중, 1분 휴식 주기를 반복하며 진행한다.
• 지치지 않기 위해 적절한 휴식을 도입하기 위함도 있다.

리뷰

아직 많이 해보지는 않았지만 5분 집중 구간에 집중력이 높아지며 뭔가 호르몬이 분비되는 느낌을 받는데, 1분 휴식의 alert이 울리면 바로 작업을 멈추고 딴짓을한다. 그러면서 다시 1분 휴식이 지난 후에는 다시 작업을 착수하며 다른 몰입했던 방법(구현)이 아닌 다른 방법을 확인하기도 한다.

평균적인 집중 수치가 유지되며 흥미도 높아졌다.

이후 적응되면 10분정도로 늘려보거나 나에게 맞는 여러가지 시도를 해볼 것이다.

현재는 시간만 조절하고 있다. 이후에 해볼 것들은

1. 태스크에 걸리는 시간을 명확히 파악
2. 여러 가지 일들을 switching하며 처리가 어느정도 퍼포먼스가 나오는지 파악
3. 집중을 멈추고 다른 방향으로 구현 방식 및 솔루션을 변경했을 때, 효과가 있는지 파악

• 커뮤니티 참여
• 최신 작성된 글 읽기
• 괜찮아보이는 책 읽기

커뮤니티 참여

• 다양한 사람들이 글을 많이 작성하는 커뮤니티에서 내가 원하는 토픽을 읽고, 궁금한 것은 질문하거나 틀린 것은 의견을 제안한다.

주로 reddit, velog를 이용하는데, reddit은 offical news를 가장빨리 접할 수 있는 공간이기도 하다. 그리고 오픈소스 maintainer들이 직접 활동을 하기도 해서 다양한 의견을 주고받기에도 좋다.

• ruby
• rails
• softwarearchitecture

이 것들 중에서는 웬만하면 매일 top rated된 글을 읽으려고 노력한다. 홛동하다보면 얻는 Karama를 쌓아나가는 재미가 쏠쏠하기도 하다. 반대로 잘못된 정보를 말하면 downvote가 막 찍혀서 잘못된 정보구나 알기도 쉽다.

velog는 국내 커뮤니티인데, 빠르게 읽고 국내의 트렌드를 쉽게 접할 수 있어서 좋다.

최신 작성된 글 읽기

medium에 원하는 토픽을 구독해서 매일 읽어보려고 노력한다. 가끔 reference를 타고타고 가다보면 좋은 paper나 기업의 기술블로그를 볼 수 있는데, 웹서핑하듯이 다 읽어보는 편이다. 많이 하다보니 이제는 제목만 보고, 읽고싶은 글인지 아닌지 알 수 있게되었다. 괜찮다 생각하는 글은 Github에 정리도 한다.

괜찮아보이는 책 읽기

GoF, DDIA, Clean Architecture, Database Internals 등 좋은 책들은 항상 어디선가에서 레퍼런스로 사용된다. 익숙한 이름이면, 후기도 읽어보고 괜찮은 책이면 일단 사놓는다. 그러면 나중에 아까워서라도 읽게되더라..

[f1, f2] = [0, 1]이다.

[f2, f3] = A[0, 1]이다.

A를 구하는 것은 원래의 점화식을 생각하면 쉽다. [ 1 0 1 1 ] 이다.

그렇다면, [f3, f4] = A[f2, f3]인데, [f2, f3]은 풀어서 보면 A*[0,1]이다.

따라서, 결합 법칙과 일반화를 통해 A^n[0,1]을 [fn, fn+1]으로 볼 수 있다.

문제풀기 위해 시간복잡도를 줄이면, A^n은 A^(n/2)의 제곱으로 처리가 가능하다.

그래서 O(logN)이 된다.

흔히 JS를 이용해서 코드르 작성할 때, 함수를 통해 반환하는 값을 다른 함수에 이용하고, 그리고 이 과정을 반복하는 경우가 많다.

const a = pow(30, 2);
const b = pow(a, 30);
const c = pow(a, 30);

or
pow(pow(pow(30, 2), 30), 30));

or
30.pow(2).pow(30).pow(30);

위와 같이 작성하는 경우

1. 깊이가 점점 깊어지는 문제
2. 불필요한 변수가 할당되는 문제

가 필연적으로 발생한다. (1) 은 가독성을 해치므로 문제가 되는데, (2) 는 공감이 잘 가지 않을 수 있다. 하지만 Martin Fowler의 글에서도 설명하지만[1], 변수명 정하는 것은 아주 어려운 일이다. 즉, 시간이 불필요하게 소요될 수 있는 것을 의미한다.

하지만 우리는 fluent interface[2]를 이용해서, 이 문제들을 해결하고 있다. 그런데 fluent interface는 언어레벨에서 제공하는 기능이 아니므로, JS의 native keyword와 조합해서 사용할 수 없는 문제가 있다.

따라서, 특정 값을 연속해서 활용하는 것은 항상 기능 구현하는데에 overhead가 따르게된다.

해결

아직 정확히 어떤 문법을 사용할지는 정해지지 않아서, 어떤 방식으로 해결할 예정인지만 간략히 설명하겠다.

const result = 30 |> pow(^, 2) |> pow(^, 30) |> pow(^, 30);

와 같은 코드가 될 예정이다.

풀어서 설명하자면, |>를 통해 value를 pipe처럼 연속적으로 사용하는 것이다.

1. 30이 ^를 통해 불러와져서, 계산됨
2. (1)에서 계산된 값이 ^로 불러와져서 pow(^, 30)이 계산됨
3. (2)에서 계산된 값이 ^로 불러와져서 pow(^, 30)이 계산됨
4. 마지막으로 result에 할당됨

마무리

위 기능을 Babel을 통해 미리 사용하는 것은 가능하다.

하지만, 현재 Stage2상태여서 빨라도 ECMAScript에 1년안에 적용될 내용은 아닌거 같다.

매우 유익한 토론이 진행 중이니, 오픈소스 커뮤니티에서는 어떤 식으로 논의가 진행되는지 확인하면 좋을 것이다.

Ref

1. https://martinfowler.com/bliki/TwoHardThings.html
2. https://en.wikipedia.org/wiki/Fluent_interface
3. https://github.com/tc39/proposal-pipeline-operator

우선, 이 책은 입문자 용이 아니다. Design pattern, Object 설계 등 Robert C. Martin의 다른 책들을 읽은 것을 가정하고 설명하기 때문에 모른다면 참고문헌을 알아서 보라고 책에서도 설명한다.

그렇기 때문에 입문자가 읽는다면 용어들의 뜻을 잘 파악하지 못해 잘못된 내용을 이해하거나 이해하는데 시간이 많이 걸릴 수 있다.

이 책에서 강조하는 내용은 세 가지정도로 요약이 가능할 것 같다.

1. 고수준의 컴포넌트는 저수준에 종속되면 안된다. 저수준은 고수준의 interface를 이용하되, 특정한 내용에 종속되면 안된다. 이를 지키기 위해서는 SOLID principle 중 D를 활용할 수 있다.

2. 세부사항은 언제든지 변경할 수 있는 대비가 돼야하나, over engineering은 하지말자. 만약 데이터베이스를 Mysql을 이용하다가 MongoDB를 이용해야될 때, 모든 코드가 변경돼야하면 어떻게 되는 걸까? 서비스가 웹 기반으로 되어있다가 native application을 지원하도록 변경해야 된다면 어떻게 해야될까? 즉, business rule에 관련된 고수준 컴포넌트는 저수준에 영향을 받으면 안된다. 항상 세부사항이 변경될 수 있는 것을 열어두되 가능성이 없는 것을 고려하기 위해 over engineering은 하지말자

3. rule을 통해 강제하지 말고 compiler나 linter와 같은 자동도구를 통해 구축한 Architecture를 위반하는 것을 막자. 누군가는 규칙을 몰라서 의도한 architecture를 위반하기 쉽다. 따라서 긴밀하게 코드리뷰를 해야하고 이는 자동화 된 도구를 통해 강제하면 좋다.

어쩌다보니 요약하면서 더 쓰고싶은 말이 많지만 1번만 읽은 내용이라서 정리가 잘 되지 않았다. 다른 책들을 읽어보고 다시 읽어봐야겠다.

SRP가 정리된 글들을 종종 읽어보면, 너무 생략해서

한 기능은 한 역할만 해야한다.

라고 설명한다.

그렇다면 질문이 추가로 생기게된다.

하나의 기능은 무엇이고 하나의 역할은 무엇일까? 이 질문에 대한 해답을 찾기 전에 SOLID가 무엇을 위함인지를 아는 것이 먼저이다.

SOLID는 완벽하지도 않고 휴리스틱을 이용하여 해결을 위한 가이드이다. [1]

SOLID는 5개의 design principles들을 이용해서 유지보수를 쉽게 도와주고, 기능을 쉽게 이해하도록 도와주고, 개발확장성 쉽게하도록 도와준다. [2]

간략하게 이 정도면 SOLID가 무엇을 추구하는지는 알게되었다.

다시 원래의 질문으로 돌아와 답변해보자

하나의 기능은 무엇일까?

모듈이다. [3] 하지만 모듈이라는 것은 너무 모호해서 단순히 함수와 데이터 정보를 묶은 Class정도로 이해해도 괜찮다.

그렇다면 첫 질문인 기능의 단위는 해결되고 마지막 질문이 남는데, 이 부분이 가장 실수가 많이 발생하고 연습이 많이 필요한 부분이라고 생각한다.

SRP를 만든 Robert C. Martin(a.k.a uncle bob)의 설명에 의하면

하나의 기능은 한 가지의 변화에 대해서만 변경돼야한다.

이다. 하지만 변화에 대한 이유가 아직까지 모호하다.

코드와 함께 살펴보자

public class Employee {
  public Money calculatePay();
  public void save();
  public String reportHours();
}

코드는 회사의 관점에서 작성되어 있고,

• caclulatePay: 지급해야 할 급여 계산
• save: 직원의 정보를 저장
• reportHours: 근무시간

정도로 구성된 클래스가있다. 언뜻보면 Employee클래스는 회사의 구성원에 대한 한 역할만 하는 것으로 이해될 수 있다. 하지만 Bob이 원하는 관점은 다르다.

caculatePay의 기능이 어느날 문제가 생겨서 직원들에게 급여가 잘못 지급되는 문제가 발생했다. 극단적으로 이 책임을 지고 누군가 퇴사를 해야하는 경우가 생기면 누가 퇴사를 해야할까?

애매하다. 그래서 원인을 찾아보니 calculatePay메서드는 기존과 동일하지만 save의 동작이 calculatePay에서 참조하는 변수와 동일해서 예상하지 못한 side-effect이 발생한 것이다.

이를 방지하기 위해 각각의 기능을 클래스로 분리해서 서로 영향이 없게 처리해야한다.

그런데 다시 모호한 부분이 발생한다. 어떠한 기준을 통해 각 기능들을 모듈화할 것인가? 이는 Bob이 방법을 제안한다.

한 사람 혹은 한 그룹에 의해 변경되는 기능끼리 모아야한다. [3]

원문에서는 C-level의 결정권자를 통해 설명한다.

• CFO: calculatePay
• COO: reportHours
• CTO: save

각 메서드별로 변경을 필요로하는 사람이 다르다. 따라서 세 개의 모듈(클래스)로 분리돼야한다.

참고문헌

1. https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start
2. https://en.wikipedia.org/wiki/SOLID
3. https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html