1. Debug Mode 활용

디버그 모드로 애플리케이션을 구동시키면 아래 스크린샷과 같이 변수, 객체 등의 값을 알 수 있다. log를 찍거나 system print 등을 사용하지 앖아도 실시간으로 값을 알 수 있고 브레이크 포인트를 사용해서 트래킹 하는데 수월하니 앞으로는 IDE의 디버그 모드를 적극 활용하자. intellijeclipse 모두 지원한다.

IntelliJ의 디버그 모드


2. Comment 제거

아래 기준을 참고해서 과감하게 기존 코멘트를 제거한다.

  • 위 디버그 모드 활용과 더불어 단순 값 확인용 코멘트는 제거한다.
  • 의미없는 ‘//////////////’ 와 같은 구분선 종류의 코멘트는 제거한다.
  • Github을 통해 트래킹, 복원이 쉽기 때문에 불필요한 주석은 과감하게 제거한다.

3. 선언, 초기화, 디폴트에 신경쓰자

코드 품질은 디테일에서 나온다. 그리고 디테일은 기본기 없이 챙기기 힘들다. 아래 스크린샷을 보자.

  • 선언부 이후에 로직 중에 항상 해당 변수에 값을 할당한다면 굳이 선언하면서 초기화 할 필요가 없다.
  • 의미없는 값으로 대충 초기화 하는 습관은 멀리하자. 초기화 하는 값은 일반적으로 디폴트 값이어야 하고 이 디폴트 값이 뭔지 정확히 알고서 초기화 해야한다.

4. 가독성을 높이자

// Before
// 결제상점아이디에 따른 분기
if (TRD_NO.indexOf(oldIdPart) >= 0) {
    sMallID = oldMid;
}

// After
if (TRD_NO.contains(oldIdPart)) {
    sMallID = oldMid;
}

위 코드는 파라미터로 넘긴 string의 존재 여부를 검사한 뒤 그에 따른 처리를 하기위한 것으로 보인다. 그래서 자바의 String에 있는indexOf() 메소드를 사용해 >= 0 조건으로 판별한다. 이 코드는 기능상 아무 이상 없이 작성자의 의도대로 잘 작동한다.

앞서 이야기한 것처럼 이런 코드에서 보이는 디테일을 잡으면 가독성과 품질이 상승한다.

indexOf 와 contains

자바에는 각 객체를 위한 유틸 메소드들이 많다. 그 중 contains라는 메소드로 indexOf를 대체할 수 있다. contains의 내용은 아래 스크린샷처럼 indexOf를 래핑한 메소드다. 따라서 성능이나 기능에선 차이가 없다고 봐도 된다.

JDK 1.5에 생긴 contains
indexOf

그럼 왜 indexOf를 contains로 대체하려고 하는거고 언제 써야 할까?

indexOf와 contains는 용도가 다르다.

indexOf는 스트링이 시작되는 index를 int값으로 반환하고 contains는 스트링의 포함 여부를 판단해 boolean으로 반환한다. 따라서 특정 비즈니스 로직 혹은 알고리즘을 구현하기 위한 경우가 아니면 일반적인 경우에 contains의 목적으로 더 많이 쓰게 된다.

Readability

물론 indexOf를 보고 >= 0 조건을 보면 뭘 하려는지 알 수 있다. 하지만 contains라는 단어가 그 모든걸 포함하기 때문에 훨씬 더 직관적이다. contains쓰면 indexOf라는 메소드는 잘 썼는지, 뒤에 >=0 인지 > 0 인지 > -1 인지 잘못쓰진 않았는지 이런 생각 할 필요도 없다. 가독성을 정의할 때 그저 문자가 잘 읽히는 정도를 넘어서 (특히 메소드는) 이름에 맞는 목적과 기능을 신뢰할 수 있어서 불필요한 생각도 줄여주는 수준까지 갈 수 있도록 신경써야 한다.


5. Naming - 변수명은 중요하다

현재 레거시 코드의 문제점

  • 
프론트 HTML tag'name을 그대로 백엔드 로직에 사용함
  • 마크업과 프론트 사정에 따른 hChk, pChk 와 같은 변수명 백엔드에서 실제 용도를 구분하기 어려움
  • 변수명과 주석이 일치하지 않거나 주석의 뜻을 담아내기에 부족한 변수명이 많음

실제 주문취소에서 볼 수 있는 케이스는 아래와 같다.

    // bad case
    String[] hChk = request.getParameterValues("hChk");//선택여부

    // good case
    String[] cancelSelectYn = request.getParameterValues("hChk"); // 취소선택여부

위 변수가 가리키고 있는 건 주문 취소 시 상품 별 체크박스 값이다.(아래 스크린샷) 따라서 hChk 라는 이름을 그대로 백엔드 로직에도 차용한다면 코드 전체를 트래킹 해야 하는 수고가 더해진다. 그래서 이름을 취소선택여부, 취소신청여부 등으로 하고 변수명도 이에 맞춰 수정하는 것이 좋다.

주문 취소 상품 선택화면

하지만 실제로 레거시 시스템은 볼륨도 크고 복잡한 상호관계를 이미 가지고 있는 상태기 때문에 변수명만 바꾸기에 위험하다. 래거시 프로젝트 소스코드도 마찬가지이며 따라서 변수명을 바꾸려 할 땐 아래 항목을 점검해서 진행한다.

  • JSP와 JAVA에서 동일하게 사용하고 있는 변수가 response나 query에서 반드시 동일하도록 짜여 있는지
  • 주석과 변수명이 다르다면 둘 중 어느 것이 맞는지, 둘 다 틀린지
  • 변수명을 바꿨을 때 영향 범위가 백엔드 비즈니스 로직에만 해당되는지

6. 조회와 요청, 트랜젝션

  1. 사용자의 화면에 보이는 내용은 화면을 그리는 시점에 유효한 정보이다(화면을 실시간으로 갱신하지 않는한)
  2. 현재 프로세스는 <step 2> 와 같고 주문 취소 요청 시 JSP에 뿌려진 주문/결제 값으로 환불요청을 시작한다
  3. 때문에 주문 조회 시점과 환불 요청 시점 차이가 있을 때 주문 상태 차이가 발생할 수 있고 중복 발생 가능성 또한 있는 구조다.
  4. 개선 프로세스는 <step 3> 와 같이 사용자 요청을 받고 현재 주문과 환불 진행상태 등을 DB에서 조회하는 ② 부터 완료된 주문/결제/환불 정보를 DB에 업데이트하는 ⑥ 까지를 하나의 트랜잭션으로 묶는다.

대부분의 레거시 프로젝트 코드에는 화면에서 가져온 값들로 무언가 처리하는 로직이 많은데 전반적인 수정이 필요하다.


7. 3-tier Architecture

아래 쿼리를 먼저 보자.

// 이런 패턴
, X.BANK_CD                <!--은행코드-->                        
, CASE WHEN X.BANK_CD IS NOT NULL
  THEN DECODE(X.BANK_CD, '02', '산업', '03', '기업', '05', '외환', '06', '국민', '07', '수협', '11', '농협', '20', '우리', '23', 'SC제일', '27', '한국씨티', '31', '대구'
                  , '32', '부산', '34', '광주', '35', '제주', '37', '전북', '39', '경남', '45', '새마을금고', '48', '신협', '71', '우체국', '81', '하나', '88'
                  , '신한(계좌이체)', '26', '신한(가상계좌)','S0', '동양증권', 'S1', '미래에셋', 'S2', '신한금융투자', 'S3', '삼성증권', 'S6', '한국투자증권' , 'SG', '한화증권')
  ELSE '-'
  END    BANK_NM            <!--은행명-->

// 비슷한 패턴
, X.MEMO                <!--메모(가상)-->
, NVL(X.MEMO, 'X') SHW_MEMO                <!--화면용메모(가상)-->

// 비슷한 패턴
, X.RECP_PSN_TELNO            <!--수령인전화번호-->
, CASE WHEN  LENGTH(REPLACE(NVL(X.RECP_PSN_TELNO, 'X'), '-', '')) <![CDATA[ < ]]> 9
  THEN 'X'
  ELSE X.RECP_PSN_TELNO
  END   SHW_RECP_PSN_TELNO            <!--수령인전화번호-->

안좋은 케이스로 보이는 건..

  • 쿼리 안에서 데이터 가공을 한다는 것이다. 게다가 화면에 보여줄 목적인 것들이 꽤 있다.
  • 코드 관리나 관련 메소드가 애플리케이션에 있는게 아니라 쿼리에 들어가 있다.

대부분의 레거시 프로젝트들은 JSP, Spring, Oracle 기반이지만 잘 구분된 계층 구조를 이루고 있지 않다. 해당 계층에서 해야 할 일들이 다른 계층으로 번져간다면 결국 문제가 생길때마다 화면~데이터 모든 영역의 코드를 살펴봐야만 어느 부분이 문제인지 찾아낼 수 있다. 그래서 앞으로 신규 개발하는 화면, 기능은 이러한 강한 결합을 피하고 우리 시스템과 기술이 지향하는 3티어 계층에 맞춰 프로그래밍을 하도록 한다. 추후 가이던스를 마련하고 공유하겠지만 먼저 간단하게 요약하면 아래와 같다.

  • 화면 코드에(JSP)에 비즈니스 로직 넣지 말자
  • 쿼리에 비즈니스 로직, 하드코딩, 화면 표시용 글자 넣지 말자(특수한 경우 제외)
  • 컨트롤러에 비즈니스 로직 넣지 말자
  • 실제 필요한 것들만 파라미터로 전달하고 용도에 맞는 모델을 만들자

 


출처 : 같이 일 했던 선배가 컨플루언스에 올린 글

 
728x90
반응형

확실히 비즈니스 모델이 SW인 회사와 그렇지 않은 회사는 같은 질문도 의도나 원하는 대답이 다르 다는 것을 느꼈다. 가고 싶은 회사로 이직하기 위해 기본기 공부와 코테 준비를 하는 것도 중요하지만, 면접 경험 역시 계속 쌓는게 좋다는 것을 느꼈다.


질문 내용

  • 당사에 와서 어떤 일을 하고 싶은지
  • 이직할 때 회사를 고르는 기준이 무엇인지
  • 왜 이직 하는지
  • 그 동안 뭘 했는지
  • 졸업하고 분야를 전향하기 전에는 뭐를 했는지
  • 초등학교때부터 개발하는 애도 있는데 무슨 경쟁력이 있다고 하는지
728x90
반응형

'커리어 디버깅' 카테고리의 다른 글

[면접 회고] 20230530 COY 면접 회고  (0) 2023.05.30
[면접 회고] 20230420 EI사 1차  (0) 2023.04.20
[면접 회고] C사  (0) 2023.02.27
2022년 회고 및 2023년 목표 설정  (0) 2023.01.03
[코테 회고] 2022 10 01  (0) 2022.10.01

역대급으로 면접을 잘 보았고, 면접이나 처우 협의 경험을 기록 해둬야 할 것 같아서 남겨둔다. 계약 연봉만 따지면 조금이나마 인상이지만, 인센이나 성과금, 현금성 복지 그리고 업무 환경으로 따지면 낮아지는 이직이 되었다.

면접관님과의 대화에서 OOP 잘 쓰는 사람들과 일 하는게 쉽지 않을 것이라는 생각이 들었고, 아키텍쳐 공부 역시 꼭 해야겠다는 생각이 들었다. 그리고 잘하는 동료와 좋은 경험을 할 수 있는 환경에서 근무를 하려면 아무래도 다음 이직은 중견 이상으로 가야겠다는 결론이 났다. 면접관님이나 그분이 말씀 하시는 환경 또한 좋지만  IntelliJ 개발 환경 그리고 실 사용자의 규모에서 나오는 경험은 못 잃겠다는게 결론이였다.


면접 내용

  • 간단한 자기소개
    • 4년 차 개발 SI, SM로 2년 재직, 이후 쇼핑몰에서 이벤트/프로모션, 결제, 물류/배송 담당으로 기능개선 작업을 주로 했다.
  • 재직중인 팀 구성은 어떻게 되는지?
  • 현재 재직 중인지
  • 이직 사유
    • 이커머스 플랫폼 프로젝트 예정이었으나 엎어지고, 외주 개발로 돌리게 됨.
    • 주요 3인이 퇴사함.
    • 할 수 있는 것이 크지 않을 것으로 보여서 이직을 고려함.
    • 본가가 이사할 예정이 되어서 자취할 겸 이직할 곳을 구하게 되었다.
  • 결혼했는가?
    • ㄴㄴ
    • 근방에 여자친구가 살고, 해당 동네 근처에 친구들이 많다
  • 자취는 부모님과 합의 됐는가?
    • 그렇다
  • 그럼 결혼은 언제?
    • 3년 내?
  • 회사 내에서 다른 문제는 없었는가?
    • 지금 사용하는 기술 스택이 자바 1.7, 스프링 3.1.1, 마이바티스 초반 버젼을 사용하는데 기술적으로 성장을 원해 이직을 고려했다.
  • 지금 해당 회사에서 사용하는 기술과 비슷하다. 어떤 회사인지 알아봤느냐?
    • OOOO, OOO을 만드는 회사로 알고 지원했다.
  • 핵심 기술은 OOOO로 A, B, C, D등이 핵심 기능이다.
  • 자바는 1.8 사용. 스프링 5점, 마이바티스 10점대로 대로 버전 업 진행 중.
  • 전의 회사에서는 어떤 것을 위주로 했는가?
    • 공공기관 SI/SM, 간단한 업무 프로세스로 게시판, 체육시설/교육프로그램/공간 대실/예약시스템, 공공 API 공고, SNS 게시물 스크래핑 등
  • 두 번째 회사를 짧게 다니고 이직한 사유
    • 7개 프로젝트를 유지보수했는데, 업무가 간단하고 단조로웠다.
  • 첫 회사, SI?
    • 솔루션 기반 지리정보 시스템이지만 프로젝트마다 커스터마이징이 심해 거의 항상 새로 개발했다.
  • 스프링 부트 써봤는가?
    • ㄴㄴ
  • 스프링 부트는 쉽다, 레거시가 어렵다. MVC 썼는가?
    • ㅇㅇ
  • DB는?
    • Oracle
  • sql은 어떻게 다뤘는가?
    • ANSI JOIN으로 사용했다.
  • PL/SQL은?
    • 손댈 일이 거의 없어서 사용해보지 않았다.
  • 우리도 PL/SQL은 별로 안 쓴다, 다른 DB는 뭐 써봤나?
    • MySQL, MariaDB, Tibero, PostgreQSL
  • PostgreSQL?
    • GIS 할 때 써드파티가 많아서 사용했다.
  • MySQL을 쓴다.
  • JPA는?
    • 인강으로 공부만 해봤다
  • Stored Procedure는?
    • 안 해봤다
  • OOP는 들어봤을 텐데 추상화의 개념이 뭐냐?
    • 예제로 자주 나오는 예시인데, 자동차에 엔진이 있고 이 엔진이 작동하는 메소드를 인터페이스로 만들고 실제로 구현은 상속받아서 구현한다. A 엔진을 사용하다 B 엔진을 사용하고 싶으면 엔진 인터페이스를 상속받는 엔진 B를 만들어서 A를 B로 교체한다.
  • 그런 식의 개발을 해봤는가?
    • S3 전환을 할 때, 파일 저장하는 Util 클래스를 로컬 파일 시스템에서 S2 환경으로 전환하면서 개발 해봤다.
  • 자바 개발자들중 절차적으로 개발 하는 경우가 많고, 설계에 대한 경험이 별로 없는 사람이 많더라. 리팩토링은 좀 해봤는가?
    • 기능개선 중에 절차지향적 소스가 많았고, API 송신 후 DB에 저장하는 프로세스를 OOP로 개선한 적 있다.
    • API 송/수신, 데이터 처리, 저장하는 로직을 역할별로 클래스를 분리한 적 있다.
  • MSA는 어느 정도 아는가?
    • 회원계 서버, 상품계 서버, 결제계 서버 따로 분리해서 클라이언트 - 서버간 API 통신, 서버간 API 통신하는 구조인 것만 알고 있다.
  • 정규화 등 잘 설계된 테이블이 있다 치고, SQL을 짤 때 어떻게 짜는가? Index나 WHERE 절을 어떻게 거는지
    • 마스터 테이블의 where 절을 먼저 만들고,
    • inner join이나 left outer join, on으로 테이블을 연결
    • where 절에 join 테이블 조건 거는 방식으로 만든다.
    • 기존에 자주 사용하는 쿼리 템플릿이 있는 경우에는 그 쿼리 위에 with as 절로 대상을 먼저 만든 뒤 조회 함.
  • 트랜잭션 관리는 해본 적 있는가? commit이나 rollback 등
    • java src 상으로는 최근에 배송 송장 상태 업데이트 배치 프로그램에서 MyBatis에서 Execute Type BATCH를 사용했고,
    • 해당 옵션은 SELECT 절이 반복되면 쿼리 결과를 재사용하는 문제가 있음.
    • 그래서 메인 메소드에서 SELECT하는 메소드 따로, UPDATE하는 메소드를 따로 호출, UPDATE 메소드에서 Transactional required_new 옵션을 걸어줬다.
    • 원하는 답이 맞는지는 모르겠다.
  • 나쁘지 않은 대답이다. 형상 관리나 배포 CI/CD 는? 젠킨스 써봤는가?
    • SVN이나 GIT 사용했고, 젠킨스는 잘 아는 것은 아니고 stage, dev 환경 분리할 때 기존에 있던 설정을 복사해서 옵션 바꿔 만들어 본 경험이 있다.
  • Redis는 어떻게 사용해보았는가?
    • 이전 시스템에서는 수기 배포를 했고 한쪽 서버를 재시작하면 세션이 끊기는 문제가 있었다.
    • 세션 클러스터링용으로 레디스를 사용, 조악한 UX 문제를 해결하는 데 사용했다.
  • Jira 사용?
    • ㅇㅇ
  • AWS EC-2만 써봤냐?
    • EC-2, S3, Code Deploy, Cloud Front 써봤다.
  • FE 개발할 때 스크립트는 어떤걸 쓰는가?
    • 타입 스크립트는 사용 안 해봤고, 되도록 ES 6 이상 사용하려고 하는데, 아무래도 JAVA만 만지다 보니 부족하다.
    • async, await만 사용하는 정도
  • 가족 관계? 사랑을 많이 받았을 것 같은 느낌이다
  • 음악과 졸업?
    • 실용음악 기타로 입학, 졸업할 때는 미디/전자음악로 졸업했다.
  • 방향을 바꾼 이유는?
    • 친구랑 같이 카페에서 공부하다 호기심이 생겨서 좀 배워봤고, 친구 권유로 국비 지원 학원을 다녔다.
  • 국비를 다니고 개발자를 하기로 마음먹었느냐?
    • 40명 중에 20명은 수업을 못 따라오고, 5명 정도 반 안에서 잘하는 것으로 두곽을 냈는데 그 5명이랑 나랑 크게 차이가 없는 것으로 느껴졌다. 나쁘지 않게 하는 것 같은 생각이 들었다. 적성에도 잘 맞는 편이였다.
  • 적성이 맞는가?
    • 구체적 예시는 없지만 적성에 맞다.
  • 음악 한 것은 아깝지 않은가?
    • 딱히 그렇게 생각하지 않는다.
  • 방통대 편입해서 졸업한 것 같은데 할만했는가?
    • ㅇㅇ, 퇴근하고 공부하는 게 할만 했다.
  • 요새도 공부 하는가?
    • 주말에 모여서 각자 공부하는 스터디를 하는데, 주제를 같이 하는 건 아니고 개발자들끼리 모여서 공부하고 있다.
    • 지금은 토비의 스프링 책을 읽고, Vue.js 인강 보고 있다. 이전에는 OOP 책 읽고, 알고리즘 강의 들었다.
  • FE에 관심 있는가?
    • 없진 않다. 예전엔 react 강의도 봤었고, 재직회사에서 추후 vue를 쓸 예정이라 결제를 했다.
  • 공부 계속 해라 ㅇㅇ. 본인도 50대인데 지금도 공부하고 있다.
    • ㅇㅇ 아버님이 퇴직하기 전까지 퇴근하면 항상 공부하셔서 보고 자란 게 그거다.
  • 좋다.
  • 연봉이 굉장히 세다, 소득 증빙 가능하냐?
    • ㅇㅇ
  • 연봉이 쎈데 왜 나오냐?
    • 새로운 환경에 들어가서 자극도 받고 싶다.
  • 전 직장 연봉도 다 증빙 가능한가?
    • ㅇㅇ
  • (10초간 정적)
  • DB 설계를 할 때 논리적 다이어그램을 그리고 물리적 설계를 할 것이고 그 후 테이블간의 종속관계나 트리거등을 만드는데
    게시판 설계를 한다면 어떻게 할 것이냐?
    • {메뉴 : PK, 메뉴 명(게시판 타이틀)}
    • {게시물 : 메뉴 FK, 게시물 PK, 게시물 타이틀, 게시물 내용, 게시자, IP, 작성시간}
    • {첨부파일 : 게시물 FK, 첨부파일 PK, 원 파일명, 저장명, 저장경로, 확장자, 용량}
    • {댓글 : 게시물 FK, 댓글 PK, 게시자 명, 댓글 내용, IP, 시간}
  • IDE 뭐 써봤?
    • 지금은 IntelliJ, 이전에는 이클립스 썼다.
  • 우리는 이클립스 쓴다. 500여 개 기업에 납품하는데 고객사에서 유료 툴을 쓸 수가 없다.
  • 프로세스 다이어그램이나 시퀀스 다이어그램은 그릴 줄 아느냐?
    • 컨플루언스에서 Draw.IO 플러그인으로 그렸음. 신규 기능 개발 시 작성하는데 많이 그려보진 않았다.
  • 문서 작성은 잘하는가?
    • 많이 안 해봐서 시간이 조금 걸리는 편이다.
  • 설계할 연차는 아닌데 히스토리가 나쁘지 않은 것 같다.
  • 질문?
    • VCS, 협업툴, IDE, 기술 스펙은 이미 들었고,
    • 야근 수당이나 식대?
      • 야근은 잘 안 하지만 야근 신청서를 작성해야 한다.
    • jira를 20년 사용했다고 했는데, 몇 번째 회사인가?
      • 본인도 온 지 4개월 됬으며, 10번째쯤 되는 것 같다.
    • 조직 변화가 많은 상황인가?
      • 어디나 마찬가지로 개발자 이직이 많다 보니 엄청 뽑고 엄청 나갔다. 연구소는 안정적인 편.
    • 일하게 될 팀 구성은?
      • 웹 기반 SaaS OOO 솔루션으로 {A, B, C} 파트가 있고 파트는 아직 정해지지 않았다. 총 11명 정도 있다.
      • 아마 B나 C를 할 것 같다.
      • 클라우드 기반 MSA로 고도화 예정이다.
    • 개인장비는?
      • I7 씽크패드 노트북 1대, 모니터 1대, 연구소는 전화기가 없음.
  • 더 대화하고 싶은데 다음 면접자가 있는지 확인해 보겠다
    • (다음 면접자 대기 중이라고 함)
  • 회사 구조 설명
    • 관리/영업은 50여 명, 연구소는 20명 정도 있고, SI은 140명, SM은 20여 명
    • 수행팀은 SI, 제품팀은 운영/개발, 연구소에서는 새로운 기능 개발 중심이지만 지금은 사람이 없어서 수행팀, 제품팀 지원을 자주 한다.
    • 협업 도구는 자체 개발 한 것과 레드마인을 쓴다.
  • 개인차가 조금 있지만 기본 연봉 테이블이 있다. 면접관 마음에 드는 데 붙여줄테니 처우 협의는 알아서 해라. 또 봤으면 좋겠다.

 

728x90
반응형

'커리어 디버깅' 카테고리의 다른 글

[면접 회고] 20230420 EI사 1차  (0) 2023.04.20
[면접 회고] W사  (0) 2023.02.27
2022년 회고 및 2023년 목표 설정  (0) 2023.01.03
[코테 회고] 2022 10 01  (0) 2022.10.01
[채용 과제 회고] 2022 09 22 P사  (0) 2022.09.22

 

 

사람이 많지 않아서 느긋하게 볼 수 있었다.

'그림 같은 컬러 사진'으로 유명한 것으로 알고 있는데
크롭한 필름 사진과 그 필름에서 느껴지는 질감이, 원근감이 사라진 평면적이고 기하학적인 이미지가 인상 깊었다.

"프레센쟈 아센쟈"

728x90
반응형

'ETC > Daily Life' 카테고리의 다른 글

내돈내산 선크림 후기 - 2023년엔 외모 관리도 하자  (0) 2022.12.19
[카시코이] 빛이 예쁜 화과자 카페  (0) 2022.12.19
RICOH GR3  (1) 2022.12.19
[한탄] tibero  (0) 2020.06.14

netstat 확인하기

    netstat -an

Local Addrress 는 현재 내 PC의 IP와 Port, Foreing Address는 외부 사이트의 IP와 Port 다

아이피 다음에 있는 : 으로 아이피주소와 포트번호가 구분이 된다


netstat 으로 특정 포트 확인하기

    netstat -an | findstr ":80"

Linux의 grep 명령어는 windows에서는 findstr로 볼 수 있다.

 

 


그렇지만

더 이상 윈도우를 서버로 쓰는 일은 없었으면 좋겠다

728x90
반응형

벌써 2023년이 되었다.
지난 2022년을 되돌아 작년의 목표가 얼마나 지켜졌는지 확인해보고 2023년에 대한 목표를 잡아보고자 한다.


2022년 회고

[방통대 졸업]

물론 2022년 이전 학기부터 학점이 쌓여 온 것이지만 어쨌든 3. 후반대 학점으로 졸업 했다.
졸업은 했지만, 시험을 위한 공부를 한 탓에 CS 지식이 많이 모자라다는 것을 느끼고 2023년에도 CS 공부를 부지런히 해야겠다.

[SQLD 취득]

생각보다 노력을 덜 하고 sqld를 땄다. 6주 정도 퇴근하고 3시간, 출퇴근 길에 요약 내용 복습 정도로 공부하고 붙었으니 운이 좋았던 것 같다.
사실 자격증이 있다고 실무를 잘 하는 건 아니지만, 자격증을 딴 덕분에 쿼리를 짜거나 DB 구조를 변경할 때 한 번 더 생각하게 되었다.
물론 아직은 경험치가 모자라니 더 정진해야겠다.

[JPA 학습]

인프런에서 인강을 듣긴 했지만, 완강하지 못했다. 아무래도 지금 일 하는 곳, 지금 까지 일 했던 곳은 MyBatis를 사용하다보니 JPA 공부에 절실하지 않았던 것 같다. 테크기업 이직을 생각하고 JPA를 꼭 미리 학습 하도록 해야겠다.

[알고리즘 문제풀이]

1학기 끝나고 7월부터 인강과 함께 코테공부를 했었다. 과거형이다.
10월부터 극심한 야근의 늪에 빠지면서 지금까지 게을리 해버렸다. 올해는 꼭 프로그래머스 3레벨까지는 풀어야 겠다.

[경력기술서 지속적인 업데이트]

블로그엔 올리지 않았지만 분기별로 업데이트를 잘 했다고 생각한다. 23년에도 잘 정리해서 이직 준비 해야겠다.

[다른 개발자들과의 교류]

따로 커뮤니티를 하는 것은 아니지만 동네 스터디 모임에 들어갔고, 이전 직장 동료들이나 친구들과 꾸준히 연락하면서 소식을 듣고 있다. 나랑 다른 분야의 선후배 개발자들이나 같은 분야의 다른 회사사람들을 통해 업계 소식을 조금씩 듣고 있다. 이렇게 조금이나마 간접 경험을 하고 있고, 다른 사람의 시각이나 생각을 들으면서 내 식견도 늘리려 하고 있다.


2023년 목표

목표를 너무 많이 세우지 않고 작은 목표를 집중적으로 수행하려 한다.

[Java, Spring 더 깊게 공부하기]

Spring 소스코드도 뜯어보고, 인강이나 토비의 스프링 책읽기등을 하면서 레벨업을 해야겠다고 느꼈다. 회사 과제를 수행하면서, 종종 기초지식이 부족하다는게 느껴질 때가 있었다. 회사에서 사용하는 스펙이 심각한 레거시라 생긴 문제인지, 아니면 정말 내가 뭔가를 모르고 있는 것인지는 공부 해봐야 아는 것이다.

[인강 및 프로그래밍 책 읽기]

게을리한 JPA, 알고리즘 코테 인강을 올해는 끝내고 그 이상으로 발전 해야겠다.

[이직]

회사 사정까진 모르겠고, 지금 회사에 머물 이유가 배울 수 있는 선임들 이였는데, 그 사람들이 지금 다 나갔다.
회사가 학교는 아니지만 개인의 성장에 많은 영향을 미친다고 생각하며, 그 성장에는 같이 일하는 동료들이 중요하다고 생각한다.
떠나신 그 세분을 내가 따라 갈 수 있을지는 모르겠고, 우선 적으로 회사 매출이 어떻든 개발팀의 조직이 8인 이상인 곳으로 이직하고싶다고 생각 했다.
이직의 결심은 22년에 "다른 선/후배/동료 개발자들과 생각을 교류하고/보고/배움으로써 개인이 성장할 수 있다"고 느낀게 가장 큰 것 같다.

[여행]

적어도 분기에 한번은 여행을 다녀와야겠다고 생각했다.
일 하면서 쌓인 생각이나 걱정들도 잠시 내려두고, 여행에서 마주하는 낯선 경험들이 나를 찾도록 해주는 것 같다.

[운동, 건강]

건강하지 않으면 공부도 할 수 없는 것 같다. 살로인해(?) 집중에 방해되는 것도 있고.
일단 1년 동안 10키로 빼는 게 목표로 지금 68키로다.

 
728x90
반응형

'커리어 디버깅' 카테고리의 다른 글

[면접 회고] W사  (0) 2023.02.27
[면접 회고] C사  (0) 2023.02.27
[코테 회고] 2022 10 01  (0) 2022.10.01
[채용 과제 회고] 2022 09 22 P사  (0) 2022.09.22
패션 쇼핑몰 1년 회고  (0) 2022.09.14
 

특별한 일 없으면 평소에 선크림은 잘 안 바르는데, 연말 여행을 앞두고 선크림 하나 장만했다. 눈 쌓인 동네는 여름철보다 자외선이 많다나 뭐라나... 사실 30 넘으니 슬슬 피부에 노화도 느껴지고, 관리하라는 조언을 많이 듣다 보니 조언 해준 지인에게 선크림 추천까지 받았다. 

전에 사용하던 선크림은 백탁 현상(?) 도 심하고, 지성 피부인 내 얼굴에선 4시간만 지나도 번들번들한 기름기 때문에 눈이 따갑기도 했는데 이 제품은 그렇지 않아서 당황했다. 질감이 생크림 같기도 하고 보송한 느낌인데 바르고 나면 약간의 피부톤이 밝아지는 느낌도 있다. 밀착력이라는게 뭔지 감이 잘 안 왔는데 이 제품으로 말로만 듣던 착 붙는 밀착력이 어떤 느낌인지 알게 됐다.피부 노화의 주범이 자외선이기 때문에 자차제는 외출시 필수라고... 여름 아니면 귀찮아서 잘 안 발랐는데, 올 겨울부턴 로션 바르고 필수로 바를 것 같다.

2023년은 자기관리 좀 하자.

728x90
반응형

'ETC > Daily Life' 카테고리의 다른 글

[프랑코 폰타나]  (0) 2023.02.26
[카시코이] 빛이 예쁜 화과자 카페  (0) 2022.12.19
RICOH GR3  (1) 2022.12.19
[한탄] tibero  (0) 2020.06.14
 

경의선 숲길의 가좌역 끝 지점에 가깝다

아기자기한 분위기에 들어오는 빛이 예쁘다

 

말차 라떼와 콜드 브류 그리고 그날 있던 화과자를 종류별로 하나씩 다 시켰다.

화과자는 색이 예쁘고 달달했다. 다 같은 맛일 줄 알았는데 종류별로 조금씩 다른 맛.

선물용으로 괜찮을 것 같지만 저렴한 편은 아니다.

728x90
반응형

'ETC > Daily Life' 카테고리의 다른 글

[프랑코 폰타나]  (0) 2023.02.26
내돈내산 선크림 후기 - 2023년엔 외모 관리도 하자  (0) 2022.12.19
RICOH GR3  (1) 2022.12.19
[한탄] tibero  (0) 2020.06.14
 

연말 여행 사진 촬영 겸 취미생활을 위해 중고로 구매한 리코 RG 3

장점은 내장 필터 기능을 사용하면 보정 없이도 꽤나 괜찮은 질감의 사진을 찍을 수 있고 부피가 작아 가볍게 사용하기 좋다

 

 

필름 사진 느낌 나는 색감은 좋은데, 그 색감을 살려 찍는 게 쉽지 않다. 아마도 내가 노출의 3요소를 컨트롤하지 못해서 인 듯?
사실 생각 없이 막 찍으면 폰카보다 못하다.

모든 사진은 보정 없이 jpeg 원본이다

 

 

 
 
 
 
728x90
반응형

'ETC > Daily Life' 카테고리의 다른 글

[프랑코 폰타나]  (0) 2023.02.26
내돈내산 선크림 후기 - 2023년엔 외모 관리도 하자  (0) 2022.12.19
[카시코이] 빛이 예쁜 화과자 카페  (0) 2022.12.19
[한탄] tibero  (0) 2020.06.14

한 4주간 야근 + 주말 출근으로 그동안 코테 공부했던 거 원복 됬음. 어쨌든 겨우 프로그레머스 레벨 2 시작하는 수준이라 이번 코테 합격은 꿈도 안 꾸긴 했지만, 일 하면서 공부한다는 게, 특히나 일정 관리가 어려운 이 회사에서는 참 어렵구나 다시 한번 상기하게 됐음.
어쨌거나 코테 준비로 인강 듣고 공부하는 것도 중요하지만 실전경험도 쌓여야 찐으로 집중 해야 할 코테에서 효율이 나올테니까 최대한 많이 응시해보려고 하는데, 저번 주에 카카오 코테도 출근하느라 응시조차 못해서 많이 화났었음...

1번

간단한 구현, 문제는 정말 간단했지만 역시나 실력이 모자라서 푸는데 30분 걸렸음. 10~15분 안에 풀어야 뒷 문제 푸는데 문제없었을 듯함.
어쨌거나, 이런 문제조차도 풀 수 없는 실력에서 이 정도면 발전을 했다고 봄. 물론 뒷 문제를 못 풀어서 문제.

2번

읽기엔 간단해 보였지만 역시나 실력이 부족해서...
간단한 구현 + 스택 구조 이해로 보임.
TC 1, 2, 3는 통과했는데, 4번은 통과 못했고, TC 난이도가 3 < 1 < 2 < 4 순으로 보여 순서대로 해결하며 확장하다 보니 2번에서 해결하면서 4번으로 구조 변경하기가 어려웠다고 판단됨.
문제 푸는데 1시간 반 가까이 걸렸는데, 이 문제도 한 30분 안에 해결했어야 뒷 문제 푸는데 여유 있었을 듯?

3번 / 4번

어려움;
문제 처음 읽는 순간 아 2개는 포기해야겠다고 생각했음.
4번은 트리, 완 탐으로 해결 가능해보임.
어쨌거나 언젠가는 이 정도 문제는 풀어야 하는데...

728x90
반응형

'커리어 디버깅' 카테고리의 다른 글

[면접 회고] C사  (0) 2023.02.27
2022년 회고 및 2023년 목표 설정  (0) 2023.01.03
[채용 과제 회고] 2022 09 22 P사  (0) 2022.09.22
패션 쇼핑몰 1년 회고  (0) 2022.09.14
2022 07 13 채찍  (0) 2022.07.13

+ Recent posts