소프트웨어

최근에 인프런에서 프론트엔드 테스트에 대한 강의를 들으면서 생각한 내용을 주절주절 적어보려고 한다.프론트엔드에서 테스트가 필요한지? 에 대해서는 과거에는 논쟁이 있었던 것으로 기억한다. 누군가는 필요하다, 누군가는 필요하지 않다.내가 이전에 다니던 회사는 프론트엔드 테스트 코드가 없었고, 지금 회사는 있다. 하지만 테스트 코드가 있다고 크게 더 나은 점이 있는지는 잘 모르겠다. 가끔씩 프론트엔드 측에서 코드만 수정했을 때 테스트를 수정해 주지 않아서 테스트 CI가 깨지는 일이 몇 번 있었는데 오히려 번거롭다는 생각이 들 때도 있었던 것 같다.그런데 이번에 강의를 들으면서 프론트엔드에서도 테스트 코드가 필요하다 는 생각이 강하게 들었다. 어떠한 이유들로 테스트 코드의 필요성에 대해 느끼게 되었는지 이번 글..

본문은 교보문고 7호 - 개발하는 마음 에 기고한 글입니다. 안녕하세요. 저는 의료 도메인의 문제를 해결하는 헬스케어 스타트업 굿닥에서 웹 프론트엔드 엔지니어로 일하고 있는 오원종입니다. 저는 비전공자 출신 개발자입니다. 대학에서는 신소재공학을 전공했고 군 전역 후 스물다섯이라는 다소 늦은(당시에는 그렇게 생각) 나이에 프로그래밍에 입문하게 되었습니다. 개발을 시작한지는 약 5년, 개발자로 커리어를 쌓은지는 이제 3년이 되어가는 시점에서 저는 지금 적성에 잘 맞는 일을 하고 있다고 생각해서 그 점은 정말 다행이고 감사합니다. 이번 글에서는 제가 어떠한 계기로 프로그래밍을 시작하게 되었는지 저에 대한 소소한 이야기를 들려드릴까 합니다. 스타트업에 관심을 가지다 제가 군 전역을 한 2016년 여름, 저는 여..

Adios 2022 (Part 1. 회사편)에 이어서 두 번째 회고록을 작성해 본다. 개인편 회고록은 크게 개발 관련, 개발 외적인 내용 관련으로 나누어서 작성해 본다. 개발 넥스터즈 올해 1월부터 2월까지 넥스터즈 20기 활동을 했다. 넥스터즈는 두 번째 기수 활동이었는데, 이 때도 마찬가지로 코로나로 인해 전면 온라인으로 세션을 진행했었다. 여담이지만 이 때 내가 첫 세션 시간에 결혼식 축가와 겹쳐서 불참을 했었는데, 이 날이 팀빌딩 날이었다. 사전에 운영진 분들께 다 양해를 구하고 부탁을 드리고 하긴 했지만, 결혼식 축가 준비하면서 계속 불안한 마음을 지울 수가 없었다. 너무나 감사하게도, 정말 좋은 분들과 팀빌딩이 되어서 프로젝트를 두 달동안 재밌게 할 수 있었다. 우리는 팬시마우스라는 서비스를 ..

올 해도 어김없이 한 해가 마무리가 되는 시점이 왔다. 나는 연례 행사로 연말에 한 해를 정리하면서 회고록을 쓴다. 올 해도 마찬가지로 2022년 회고록을 써보려고 한다. 정리를 하다 보니 내용이 많아서 Part 1. 회사편, Part 2. 개인편 으로 나누어서 회고를 작성해 보려고 한다. 지난 회고록이 궁금하다면? Adios 2021 Adios 2020 Adios 2019 올해 여름 회사에서 프로필 사진을 다시 찍었다. Table of contents DropBox Career Framework SWE 2 기준표 점검 잘 한 부분 잘 못한 부분 프로덕트 (Product) 비대면진료 서비스 V4 전사 마이그레이션 B2B 웹 B2C 모바일 비즈니스 (Business) 시리즈 A 투자 유치 안드로이드 의료 ..

사내에서 디미터 법칙을 주제로 작은 세미나를 준비했었는데, 그 내용을 정리해 보았습니다. Table Of Contents 디미터 법칙(Law Of Demeter) 결합도 통제(Coupling Control) 정보 은닉(Information Hiding) 메시지와 인터페이스 참고 자료(Reference) 디미터 법칙 위키피디아에서는 디미터 법칙에 대해 다음과 같이 정의하고 있다. 💡 The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specif..

6.1 아키텍처 특성 측정 아키텍처 특성을 정의할 때 흔히 다음과 같은 문제들이 발생한다. 물리학이 아니다 : 아키텍처 특성은 대부분 의미가 모호하다. 정의가 너무 다양하다 : 부서마다 정의를 통일하기 전까지는 원활한 소통이 어렵다. 너무 복합적이다 : 바람직한 아키텍처 특성은 대부분 더 작은 다른 여러 특성들로 구성된다. 이 세가지 문제들은 아키텍처 특성을 객관적으로 정의하면 모두 해결된다. 6.1.1 운영적 특성 아키텍처 특성은 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 따른 해석은 미묘하게 갈릴 때가 많다. 예를 들어 특정 요청에 대한 평균 응답 시간을 측정할 경우, 어떤 경계 조건 때문에 1%의 요청이 다른 요청보다 처리 시간이 10배 오래 걸리면 어떻게..

4. 아키텍처 특성 정의 아키텍트는 개발팀과 함께 도메인 또는 비즈니스 요구사항을 정의할 수 있지만, 주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성(architectural characteristic)을 정의, 발견, 분석하는 일을 수행한다. 아키텍처 특성은 다음 세 가지 기준을 충족한다. 비도메인(nondomain) 설계 고려 사항을 명시한다. 어플리케이션 설계 시 어플리케이션으로 처리할 일은 구체적인 요구사항으로 정리한다. 아키텍처 특성은 이 요구사항을 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시한다. e.g. 일반적으로 어느 정도의 어플리케이션의 성능은 중요한 아키텍처 특성이지만, 요구사항 정의서에는 적혀있지 않는 경..

플랫폼마다 제공하는 코드 재사용 메커니즘은 제각각이지만, 연관된 코드를 모듈(module)로 묶는 방법은 모두 지원한다. 본인이 선택한 개발 플랫폼에서 모듈성과 그것을 구현한 수 많은 코드를 이해하는 것은 아키텍트에게 대단히 중요한 일이다. 우리가 아키텍처를 분석해야 할 (메트릭, 피트니스 함수, 시각화 등) 많은 도구가 이 모듈성에 기반하기 때문이다. 모듈성은 일종의 구성 원리(organizing principle)이다. 아키텍트가 대충 아무렇게나 조각들을 이어 붙여 시스템을 설계하면 무수한 난관에 봉착해 옴짝달싹 못 하는 시스템이 되어 버린다. 물리학에 비유 하자면, 소프트웨어 시스템은 엔트로피(entropy, 무질서)가 증가하는 방향으로 움직이는 복잡한 시스템을 모델링한다. 질서를 유지하려면 물리적..