기억 파편

유지보수하기 좋은 코드를 구현하는 개발 문화 어떻게 만들 것인가? by 박재성님

1. 변화를 어떻게 가져오는가

• 의지력이 아닌 환경. 환경(상황)을 바꿔라
  • 퇴근 후 다른 곳(스터디 카페)으로 퇴근한다
  • 티비를 버린다, 폰을 버린다. 앱을 삭제한다.. 등
• 책임감
  • 삶이 앞으로 나아가는데 필요한 견인력

2. 의식적인 연습

• 그냥 한다고 다 되는건 아닌건 아니다. 목적이 있는, 의식이 있는 연습이 필요하다.
• comfort zone을 벗어난 지점에서 진행, 자신의 현재 능력을 살짝 넘어가는 작업을 지속적으로 시도
• 명확하고 구체적인 목표를 가지고..
• 신중하고 계획적으로, 온전히 집중하고 의식적으로 행동할 것을 요구
• 피드백과 피드백에 따른 행동 변경

2-1. 요즘 제일 비싼 비용은? 인건비!! => 가독성이 제일 중요; 읽기 좋은 코드

• 인덴트를 줄이고
• else를 없애고
• stream을 써보고
• 메서드 분리! 

• 모든 원시값과 문자열을 포장한다.
• 일급 콜렉션
• 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
• 함수의 인자 수를 줄인다. 3개 이상은 가급적 피한다.
• 클래스 분리

3. 리팩하려면 테스트 코드가 기반이 되어야 함

4. 개인 -> 동료로 영향력 확대 => 힘든게 당연하다.

변화를 만들려면 리더쉽을 발휘하고 감정 노동을 해야한다.

리더쉽 / 감정 노동은 AI 시대에 가장 필요한 역량이다...ㅋ

- 사람은 변화를 거부해

- 팀은 더 거부해

- 대부분의 사람들은 변화에 실패해봤어

4-1. 시작

묵묵히 혼자 진행!! 내가 맡은 기능에는 적용. 나를 위해서

-> 관심있는 사람이 생기면 전파

-> 작은 성공 경험

4-2. 리팩기준(레이어드 아키텍처)

서비스의 로직을 도메인으로...

-> TDD하기 쉬움

- 서비스 : 도메인 객체 생성, 메세지 보내는 역할, 외부에 전달 only

- 도메인에 로직 구현하면 mock할게 없으니까 테스트가 쉽다는거임..

5. 리더/시니어로서 만들고 싶은 개발 문화

거창한 포부! 야 우리 같이 성장하쟈???

* 아웃사이드 인 접근 방식: 외부에, 과거에 좋았다고 한 것들을 그대로 도입(탑다운)

-> 실패의 지름길

* 인사이드 아웃 접근 방식: 팀원들의 의견에 의한 변화; 시간이 오래걸림(바텀업)

• 리더가 하자고하면 싫어함(뭘 듣고 왔다냐)
• 팀원들은 침묵을 선택한다. 나한테 이득이 어딧나
• 팀원들 말문이 트어야 한다.
• 어떤 의견을 제기해도 벌을 받거나 보복당하지 않을 거라고 믿는 조직
• 팀원들과의 신뢰 형성이 우선
  • 1:1 면담
    • 어떻게 하면 될까? 너라면 어떻게 할래? -> 해답을 스스로 제시하도록
  • 잘 듣고 힘들겟구나 공감하고, 반문
  • 이 중 우선순위 높고, 가장 효과있을 것 하나 골라서 시작, 익숙해질 때 까지 집중
  • 하나만 성공하도록 -> 성공 경험이 중요; 한번에 한 가지에 집중 -> 작은 성공

> 도서 "두려움 없는 조직" 추천

- 심리적 안정감! 이 필요

정리

• 새로운 문화를 정착하기 위해 가장 중요한 것은 리더의 인내심의 용기
• 새로운 문화를 만들면서 초기 학습 비용 등으로 인해 생산성 저하
• 안정화하는데 최소 1년 이상의 시간을 투자해야 한다는 마음으로 믿고 기다려야 함
• 현재보다 조금씩 나아지고 있다는 방향성이 중요
  • 중요한 것은 지금 어떤 practice를 적용하는가가 아님
• 문화를 만들고 변화를 만드는 일은 리더만의 책임이 아니다.
• 누구도 대체할 수 없는 존재가 되고 싶으면 지금 당장 도전
• 좋은 회사는 실패해도 같이 도전하는 사람을 원한다.
• 실패의 책임을 묻는다면 그만둔다. 굳

사람에 대한 존중, 신뢰, 심리적 안정감이 기반되어야 한다.

인프런, 김영한님의 모든 개발자를 위한 http 웹 기본 지식 강의를 기반으로 함.

post를 사용한 등록

• POST /members
• 서버가 새로 등록된 리소스 uri를 생성해준다.
• collection(컬랙션)
  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스 uri를 생성하고 관리
  • 위 예시에서 컬랙션은 /members

put을 사용한 등록

• PUT /files/star.jpg
• 클라이언트가 직접 리소스의 uri를 지정한다.
• store(스토어)
  • 클라이언트가 관리하는 리소스 저장소
  • 클라이언트가 리소스 uri를 알고 관리
  • 위 예시에서 스토어는 /files

html form :

• GET/POST 만 지원
• 헤더:Content-Type: application/x-www-form-urlencoded
• 파일 업로드 같은 바이너리 데이터 전송 시 헤더; Content-Type: multipart/form-data
• GET/POST만 지원하기 때문에 control-uri를 사용하여 부가적인 설명을 함(/edit, /delete 등)

관련 용어

PRG: post/redirect/get; 일시적인 리다이렉션(307)

• POST로 주문후에 새로 고침으로 인한 중복 주문 방지
• POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
• 새로고침해도 결과 화면을 GET으로 조회
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청

api url naming 참고: https://restfulapi.net/resource-naming/

김영한님 버전

1. 도메인 주소 치고 엔터

2. 웹브라우저가 DNS 서버 조회 -> ip/port 정보를 찾아와 -> http 요청 메시지 생성

[DNS 흐름]

(로컬피씨) 브라우저 캐시 -> 로컬 DNS(OS) 캐시 -> 호스트파일

(외부)  <-> 로컬 DNS서버(ISP나 회사 네트워크):: 캐시 <-> 루트 네임서버 <-> TLD네임서버(.com) <-> 권한있는 네임서버

3. 브라우저는 http 메세지 생성 후 -> 소캣 라이브러리를 이용해서 tcp/ip 3 hand shake 후 데이터 전달 -> 패킷 생성

4. 인터넷 망으로 던져, ip 찾아가

5. 도착하면 tcp/ip까서 버리고 http메시지만 꺼내서 해석

6. 응답 메세지 만들어서 tcp/ip 씌워서 전송

7. 다시 응답을 받고, http메시지 꺼내서 그 결과를 브라우저에 출력(html 렌더링)

내가 맡고 있는 프로젝트 중 지금은 보기 힘든 프래임워크를 사용하는 것이 있는데, 구조가 낯설기에 매번 어려움을 느낀다.

(20년은 된 소스인데 지금까지 잘 돌아가는거 보면 잘 짜져있음은 분명하다ㅋㅋ)

오늘은 해당 프로젝트를 오랜만에 보면서 MVC framework 중 webwork에 대해 기술한다.

• 환경: webwork-2.2.7 / xwork-1.1.1(or 1.2.3? 1.2.4? 관련 jar의 버전이 다 달라 혼동스럽다)

struts / webwork / xwork 이것들의 차이는 무엇인가..

팀장님이 처음에 나에게 설명해주실 때 이 소스를 두고 struts를 사용했다고 하셨는데, 직접적인 struts*.jar이 임포트 되어 있진 않다. webwork를 기반으로 하고 있으며 그냥 구조가 struts와 유사하여 그렇게 부른 것 같다..

그래서 더 혼동스러웠다.

요즘에는 잘 사용하지 않는 framework여서인지 정확한 정보는 현재로서 찾기는 힘드나 여러 글들을 종합한 바 아래와 같다.

• 우선 webwork와 xwork는 만든 회사가 같다(opensymphony; 지금 찾아보니 인수되었거나 망한 듯.. 홈피가 안나온다).
• webwork은 커맨드 패턴에 기반하여 설계되었고, xwork의 wrapper다. 그래서인지 webwork으로 통합되었다는 말도 많고 webwork와 xwork 를 같게 보는 글이 많다. 하지만 계속 헷갈리는 건 소스안의 파일에 두 이름이 혼용되어 사용되고 있기 때문이다.

And webwork is just a wrapper for xwork into servlet environment.

WebWork is designed around the principle of the command pattern. In fact, it is really a wrapper XWork - a generic command-pattern framework.

• struts는 webwork을 기반을 만들어진 프래임워크다. 초기의 struts framework 는 webwork framework 와 같다고 여겨진다.

관련파일

web.xml : 필터 매핑, 서블랫 매핑

xwork.xml : 각 화면별 인터셉터 정의, url에 맞는 액션 클래스 매핑, execute()함수 결과값에 따른 화면 정의

webwork.properties : 확장자 정의, method지정 변수 설정, 인코딩, i18n 등 프래임워크 안의 세팅 값

보통 디버그할 때 xwork.xml을 열어서 url 매핑을 확인하고 액션.java 나 연관된 화면(.jsp)을 열어서 분석한다.

보던 소스가 인터셉터 덩어리라(한 화면에 기본30개) 액션에 대한 로그를 확인하기가 어려운 문제가 있다. 근데 로그를 잘 보니 인터셉터가 여러번 불리는 것 같은데(정확히는 인터셉터 -> 액션 -> 인터셉터) 이해가 잘 안간다.

자세히 설명하자면...

모니터링 - before interceptor > 점검 interceptor > 유저 interceptor > action > 유저 - PreResultListener interceptor > 모니터링 - after interceptor > 모니터링 - before interceptor > 점검 interceptor > 유저 interceptor > 유저 - PreResultListener interceptor > 모니터링 - after interceptor

위처럼 인터셉터만 두번 돌았다.. 소스만 봤을 때에는 위 회색 부분은 안 돌았어야 하는데 말이다.

혹시 다른 요청이 또 들어오나 싶어 네트워크 창을 같이 봤는데, 딱히 다른 액션 요청은 없고, 액션 요청 후 리소스를 불러오는 부분 뿐이었다.

디버그 걸린상태에서 관찰한 결과 첫번째 루프(정상이라고 생각한)에서 액션이 바로 200 응답을 받고(qna.nhn; 사진의 보라색 동그라미시점) 두번째 루프(회색)가 시작할 때 보니 .css, .js 등 모든 리소스파일이 pending 이었다. 두번째 루프의 디버그를 풀어갈 때 쯤 점차적으로 불러져왔다.

지금 추측은 리소스 파일을 불러오려는 시점에 내부 콜?이 더 있지 않을까 싶은데, 딱히 잡히는건 없다.. ㅠㅠ

참고: 커맨드 패턴

https://huisam.tistory.com/entry/CommandPattern

webwork

https://blog.naver.com/tyboss/70047272213

webwork properties 항목

https://babtingdev.tistory.com/66