애플 카드… 애플이 이걸 만들고 싶어했던 이유를 진짜 알 거 같다. ㅠㅠ

뭐… 트위터에서도 여러모로 떠들었지만, 규링은 애플카드를 만들었다. ㅇㅅㅇ;

마침 신용카드 제대로 된 거 슬슬 신청하고 해야 할 시점이기도 했고 해서….

별 생각없이 만들었는데 한도 참 좋게 나왔다. ㅇㅅㅇ;;

(만세!)

뭐 이런 건 넘어가고….

미국에서는 애플 페이가 의외로 안통하는 동네 엄청 많다. ㅇㅅㅇ

특히 유통에 관여한 엄청난 대기업들은 자기네 솔루션에다가 카드 등록해서 쓰는 걸 좋아하지 애플 페이나 뭐 삼성 페이나 그런 거 지원 잘 안해주려고 한다.

지원해주는 몇몇 대형 유통 관련 업체들은 다 비싼 곳들이다. (그만큼 물건값에 수수료가 녹아있단 뜻이겠지… 특히 그넘의 타겟….)

같은 걸 사도 뭔가 이상하게 비싼 곳들은 다 이유가 있긴 하다만… 그래도 비쌈. ㅠㅠ

그러다 보니 걍 많은 인간들한테 쓰게 하고 싶고, 그걸 잘 표현할 수 있으면서 돈이 될만한 아이디어 중에 카드 사업이 있기도 하고…

여러 이유가 섞여서 만들어진 녀석이다. 여러 이유에 대한 분석들은 나보다 더 많이 떠드는 분들이 잘 설명해 준 것들이 많으니…;;;

나같은 잉여는 이렇게 잘 쓰면 된다. (?!)

[Oh! 반면교사] 10. 부모 변수랑 함수 끌어다 쓰지도 못하면서 상속은 왜 해?!

프로그래머가 돈 많이 버는 방법은 상속이라고 하죠….

흠흠….

…..(도주)

기존 클래스로부터 속성이랑 동작 이어받아서 다양하게 이용하고자 하는 것은 좋아. 그래 그러려고 클래스 쓰고 하는 거니깐…

근데 지금 부모 클래스에 자식 클래스 재정의하면 그게 부모 하는 일 그대로 한다고 착각하냐?! 지 스스로 전혀 다른 코드 짜놓으려고 여러 시도 다 해놨으면서 정작 중요한 녀석은 그냥 그대로 갖다쓰고 있고….

아우 썅….

아무리 대학교 중간고사 시험때 리스코프 원칙 같은 거 출제하고 해봐야 뭔 소용있어! 지들이 실제로 그렇게 안쓰는데!!!

죽음의 다이아몬드? 썅 그런 거 이전에 상속 숫자나 적당히 줄이라고! 상속 미친듯이 누가 4~5번씩 당연하게 때려박으래!!! 게다가 위에 클래스들 보면 어디서 쓰는 곳도 없어! (7번 넘게 한 S모군보단 니가 낫..긴 개뿔… 그래도 S모군은 유명해져서 강의뛰고 신자도 생겼더라. ㅡㅅㅡ)

게다가 중요하게 자식이 똑같이 써야 하는 함수들은 죄다 private 남용….

그러면서 안에서 새로 수식 계산을 또 하고 있어…

그러면서 부모 상속하면서 똑같이 쓰는 거라고는 디비에서 불러오는 키값 딱 하나….

……아 발암걸린다 진짜….ㅠㅠ

글쓰면서도 우황청심환 찾는다….. 누가 나 좀 사다주면 안되나….ㅠㅠ

그래서 자식은 아예 그냥 이거 기반으로 새로 구현하는 게 낫겠다 싶어서 새로 구현함… 그게 더 빠르고 쉽게 해결됨.

의외로 버그를 불러 일으킨 녀석은 진짜 단순한 걸 요구하는 곳이었다.

코드 꼬아쓰다가 별 쑈를 다하는듯 하다 진짜…

여기에 하나 더.

이렇게 부모 코드 죄다 끌어쓰지도 못하는 거면 불러와서도 문제인 거 당연한 거 아닌가요라고 묻겠죠….

그렇게 해서 만들어지지 못한 값들….

죄다 null 체크로 해결하고 있었습니다. 그리고 이전 글에서 적었듯… null도 제대로 처리 못하는 친구입니다.

이러면서 지딴에는 이런 소리 지껄였겠죠…?

가만 보면 뭐 알고쓰는 것도 아님….

오씨…. 대단한 녀석입니다….

나보다 나이도 많다는데… 이런 실력으로 뭐하고 살려고요?

[Oh! 반면교사] 09. CRUD부터 잘해라 ㅄ아….

CRUD도 제대로 못하면서 이런 거 따지는 것들이 프로그래머라고 지껄이면….

Create(생성), Read(읽기), Update(갱신), Delete(삭제)

….제일 간단한 일이다.

사실 데이터를 요구대로 만들어내서, 그걸 그대로 저장하고, 그걸 그대로 읽고, 그리고 저장한 내용 업글하고….

가장 간단한 프로그램의 가장 단순한 원칙이다만….

그리고 그걸 위해서 파일 시스템을 쓰던, 데이터베이스를 쓰던, 블록체인을 쓰던 하는 건데….

데이터 하나 그냥 그대로 저장하고 불러오고 하는 짓을 못하는데….!!!!!!!!

변수값을 저장했다가 필요할 때 그 변수값 불러서 일일이 계산해서 화면에 뿌리는 걸 CRUD 해놨다고 지랄해놨어…

게다가 화면마다 계산하는 방식이 달라서 똑같은 값 불러다가 똑같은 거 보여주는 곳들인데도 화면마다 작성한 코드 공식이 죄다 달라….

그것도 돈 계산하는 프로그램이…!!!!

하 미친…..

내가 진짜로 오씨 프로그래머로 인정 안하는 부분이다.

소스코드 짜는 데 기교부리는 것만 배웠다고 욕쳐먹는 큰 이유 중 하나… (앞으로도 쓸 글 많다…)

이런 놈이 미국에서 프로그래머로 일하려고 할 때에도 한국에서 경력있다고 하는 짓거리도 하고… 이런 놈이 한국으로 쫓겨날(…) 때에도 미국에서 경력 있었다고 지껄이겠지….

하 나 진짜…..

어려운 거 이야기 하는 것, 어려운 거 요구하는 코드도 아니었을텐데….

내 노가다의 이유 중 하나가 이딴 코드라는 것이 싫다 진짜….

p.s. 정말 어려운 버그도 있었지만… 솔직히 이런 것들이 더 열받는다…

[Oh! 반면교사] 08. null…. null… null….

오씨의 코드에서 매번 빠지지 않고 갑톡튀 하는 전문적인 녀석… null….

null값 자체에 대해서는 뭐… 생길 수 있는 값이다. 당연한 거다. 특히 C 프로그래밍을 주로 하는 내가 포인터 초기화 할 때부터 null 쓰는 건 당연한 건데….

근데 문제는….

  1. 숨었다가 튀어나오는 null
    코드 디자인 할 때에 생성자쪽에다가 필요한 변수는 마구잡이로 때려놓으면서 정작 쓰진 않아서 죄다 null 쓰면서 선언하게 만드는 이상한 클래스들이 너무 많다… 이건 전적으로 오씨의 설계 실력.
  2. 대량의 null
    필요한 클래스, 인터페이스, 추상 클래스들을 막 만들어서 내 딴에는 구조 잘 잡았어! 하고 시작했겠지 하면서 상속의 상속의 상속의 상속의 상속을 반복하니 그냥 필요하다 싶어서 하나 둘 내부 값들이 막 많이 만들고 신나게 써먹으려고 해놨는데….

    정작 재사용은 할 필요도 없이 걍 하나하나 따로 구현해야 하는 형식인데 아냐! 코드 재사용 할꺼야! 뿌뿌! 하면서 억지로 끼워 넣으려니 자연스럽게 대량의 null을 만들고 있음. 그리고 잊지 말자. 앞 문단에 적은 상속의 숫자를… 도중에 꼬이면 이상한 값 튀어나오기 일쑤다.
  3. null체크 없는 코드
    지딴에 필요한 값 제외하고는 null 체크를 안해놨다가 나중에 기능 늘리려 하면 null 에러가 뜨는데 1,2번 문제로 인해서 어디서 튀어나오는지는 모르고 하니 그냥 “못해요!” 하고 던진 케이스…

    이거 때문에 새로운 기능 넣는 데 개고생한다. 근데 문제는 기존에 설꼐에는 있던 기능을 만들려고 하는데 그때를 위해 만든 디비 테이블하고는 또 호환이 안맞아서 그냥 null값으로 때려박혀진 필드들도 있…. 이게 다시 1,2번의 null로 만들어진다.
  4. null과 0을 똑같은 걸로 생각하고 짠 코드가 있다.
    ………….구라같죠? 이게 경력 있다던 개발자가 짰다고 생각이 될 거 같으냐…?! 앙! (버럭!)

……..후…..

진짜 내 맘 속을 대변한다….

…..적고 나니 혈압 올라서 일단 스톱. ㅡㅅㅡ