Computation suite

Python 리팩토링 원칙1과 예시 원칙 1. Dependency Inversion Principle 클래스는 상세한 구현이 아닌 추상화에 의존해야 한다. [before] class Pedal:     def __init__(self, _type:str):          self.pedal_type = _type     def get_pressure(self)->int:            if self.pedal_type == 'accelerator':               sensor = AcceleratorSensor()               pressure = sensor.copy_pressure_buffer()                # do something           elif self.pedal_type == 'brake':             sensor = BrakeSensor()             pressure = sensor.copy_pressure_buffer()             # do something          elif self.pedal_type == 'clu...

짧은 기간 동안 Java로 쓰여진 클린 코드 책을 읽으며 코드를 짤 때 더 정성을 들여 쓰는 습관을 들였다. 당장 작동하는 코드보다는 유지 보수가 편한, 수정보다는 확장을 할 수 있는, 잘 읽히는, 정직하고, 하나의 일에 몰두하는 그런 코드를 짜려고 했다. 퇴근을 하고 책상 앞에 앉으면 오늘 작성했던 class가 아른거리고 과연 이게 최선이었을까 생각하게 되었다. ========================================================== 책을 읽으면서 대부분 공감하고 고개를 끄덕일 수 있었지만 좋은 코드를 쓰는 법을 아는 것과 좋은 코드를 쓰는 것에는 큰 차이가 있다. 좋은 코드를 쓰는 법을 알기만 해서는 그저 말로만 잘난 체 할 수 밖에 없을 것이다. 좋은 코드를 쓰는 사람은 코드 리뷰를 하며 시스템 변경에 유연한 구조인지 고민한다. 확실히 후자가 더 고된 작업이지만 견고한 프로덕트를 만드는, 실체가 있는 실력이 는다고 생각한다. ========================================================== Java기 반의 코드를 이해하기는 쉽지 않았지만 확실히, Java가 객체 지향적인 장치가 많다고 느꼈다. Python 웹 개발자라면 당장 객체지향 원칙이나 디자인 패턴을 익히기 보다는 웹 애플리케이션 프레임워크를 익히기를 추천한다. 그 중에서도, FastAPI를 추천하는데 Layer와 Depends를 사용한 설계 장치를 사용하며 실전 감각을 기르면서 객체지향적인 사고를 할 수 있다. 혼자 상향식으로 배우기 버겁다면 Framework의 규칙을 따르며 배워나가는 것이 효율적이라고 생각한다. 그리고 이렇게 해야 실전 감각을 느낄 수 있다. ========================================================== 클린 코드 북클럽 챌린지 덕분에 오늘도 나는 하나의 괴이한 모듈을 처리했다. util 패키지의 fileutil이라는 모듈인데 온갖 잡다한 파일 처리를 다 도맡아 하...

         오늘 TIL 3줄 요약 구체적인 클래스는 상세한 구현을 포함한다. 추상 클래스는 개념만 포함한다. 새 기능을 수정하거나 기존 기능을 변경할 때, 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면  새 기능을 추가할 때,  시스템을 확장할 뿐 기존 코드를 변경하지 않는다. TIL (Today I Learned) 날짜 2025. 06.08 오늘 읽은 범위 10장 클래스 기억하고 싶은 내용을 써보세요. 리팩터링한 프로그램은 좀 더 길고 서술적인 변수 이름을 사용한다. 리팩터링한 프로그램은 코드에 주석을 추가하는 수단으로 함수 선언과 클래스 선언을 활용한다. 가독성을 높이고자 공백을 추가하고 형식을 맞춘다. 클래스에 손대는 순간 설계를 개선하려는 고민과 시도가 필요하다. 모든 파생 클래스가 공통적으로 사용하는 비공개 메서드는 유틸리티 클래스에 넣었다. DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 변경으로부터의 격리 Part에서, 시시각각 값이 변하는 외부 API 테스트를 위한 방법을 설명한다. 고정된 주가를 반환하는 테스트 코드를 통해 시스템 결합도를 낮추는 것에 핵심이 있다. Java를 배우지 않았지만 그냥 눈으로 읽으며 이해하는 것과 , 따라 치면서 이해하는 것엔 큰 차이가 있다. 그래서 Java코드를 따라 치면서 코드를 이해했다. Portfolio 클래스에서 TokyoStockExchange API를 직접 호출하는 대신 Stock Exchange라는 인터페이스를 생성한 후 메서드를 하나 선언한다. public interface StockExchange { Money currentPrice(String symbol); }  다음으로 StockExchange 인터페이스를 구현하는 TokyoStockExchange 클래스를 구현한다. 또한 Portfolio 생성자를 수정해 Stoc...

       오늘 TIL 3줄 요약 논리가 오류 처리 코드와 뒤섞이지 않으므로 오류가 발생하면 예외를 던지는 편이 낫다. 확인된 예외는 OCP를 위반한다. 하위 단계의 코드 변경이 상위 단계 메서드 선언부 전부를 고치게 만들기 때문이다. 외부 라이브러리, API 가 던지는 예외를 전부 잡아내지말고 감싸는 클래스, Wrapper를 사용하여 의존성을 줄이자. 가능하다면, 예외 유형 하나로 오류를 구분하자. TIL (Today I Learned) 날짜 2025. 06.03 오늘 읽은 범위 7장. 오류처리 기억하고 싶은 내용을 써보세요. 오류 플래그, 호출자에게 오류 코드 반환하기  vs 예외 던지기. 에외를 지원하지 않는 프로그래밍 언어가 많았다. try-catch-fianally try 블록은 트랜잭션과 비슷하다. catch 블록에서 예외 유형을 좁혀라. 확인된 예외는 OCP를 위반한다. 하위 단계의 코드 변경이 상위 단계 메서드 선언부 전부를 고치게 만들기 때문이다. 예외에 의미를 제공하라. 특히, 애플리케이션이 로깅을 제공한다면 catch 블록에서 오류를 기록하도록 충분한 정부를 넘겨준다. 오류를 처리하는 대부분의 로직. 1) 오류를 기록하고 2) 프로그램을 계속 수행해도 좋은지 확인한다. 정상 흐름부터 정의하라. NULL을 반환하지 마라. 호출자에게 문제를 떠넘기는 것이다. NULL확인이 누락된 코드를 고치는 게 아니라 특수 사례 객체를 통해 NULL확인을 만들지 마라! NULL을 전달하지 마라. null을 전달받는 쪽에서 처리하지 말고 null 을 전달하는 쪽에서 전달을 막아라. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 NULL을 확인할 일 자체를 최소화해야겠다. NULL대신 적합한 기본값을 사용하자. 깨끗한 코드는 가독성도 좋아야하지만 안전성이 높아야한다. 그리고 이 둘은 시간-공간 개념처럼 Trade off되는, 상충되는 개념이 아님. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면...

  오늘 TIL 3줄 요약 의도가 분명한 이름 명료하고 맥락에 맞는 일관성 '코드 감각'을 기르려면 디자인 패턴같은 이론만으로는 부족하고 실천해야한다. TIL (Today I Learned) 날짜 2025. 05. 25 오늘 읽은 범위 2장. 의미 있는 이름 기억하고 싶은 내용을 써보세요. 따로 주석이 필요하다면 이름에 의도를 분명히 드러내지 못한 것 코드의 단순성이 아니라 코드의 함축성이 좋아야함. 약어와 같은 그릇된 단서를 남기지 마라. 일관성이 떨어지는 표기법 = 그릇된 정보. 불용어를 피하라. 다만 a, the를 사용한 지역변수의 구분은 최신 IDE에서 필요가 없어짐. 읽는 사람이 차이를 알도록 이름을 짓기 발음하기 쉬운 이름 사용하기. 지적인 대화를 위해.. 프로그래밍은 사회 활동이다 !  검색하기 쉬운 이름을 사용하기 접두어는 구닥다리 작가는 Abstract Factory 구현을 위한 인터페이스 클래스도 Interface를 의미하는 I 접두어를 피하는 편이 좋다고 생각한다. 명료함이 최고 의미가 분명하다는 조건 하에 짧은 이름이 긴 이름보다 좋다. 불필요한 맥락을 없애고 의미 있는 맥락을 추가하자 기술 개념엔 기술 이름을 쓰고 문제 영역에서는 문제 영역의 이름을 쓰자. 한 개념에 한 단어를 사용하여 어휘의 일관성을 높이자. Controller/ Manager fetch/retrieve/get 단, 같은 맥락일 때만. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 전부 공감함 ! 마지막 Controller/Manger 예시의 경우 실제 내가 못생긴 코드를 짠 기억이 있어서 매우 뼈아프다. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. Visitor 패턴은 뭘까? FastAPI 프로젝트에서 repository패턴을 쓰고 있는데 이 패턴의 개념과 장단점을 알고 싶다. 오늘 읽은 다른사람의 TIL 책을 읽는 이유, 목표   #노개북   #노마드코더   #개발자북클럽  

     오늘 TIL 3줄 요약 맨 처음 잡아놓은 구현 스타일은 유지보수 용이성과 확장성에 계속 영향을 미친다. 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 잘 알려진 위치에 인스턴스 변수를 모아라. TIL (Today I Learned) 날짜 2025. 05. 31 오늘 읽은 범위 5장. 형식 맞추기 기억하고 싶은 내용을 써보세요. 200줄로도 큰 시스템을 구축할 수 있다. 적절한 행 길이를 유지한다면. 줄바꿈은 개념을 분리하기 때문에 개념 사이는 빈 행으로 유지한다.  세로 밀집도는 연관성을 의미하며 연관있는 코드끼리는 세로로 가깝게 유지한다. 지역 변수는 각 함수 맨 처음에 선언한다. 연산자 강조를 위한 공백 글쓴이가 2002년 FitNesse 프로젝트를 처음 시작했을 때, 팀과 마주 앉아 구현 스타일을 논의했다(10분 소요). -> 팀규칙  오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 오른쪽으로 스크롤 할 필요가 없는 가로행 길이로 코드를 짜자. 코드 자체가 최고의 표준이다. 표준이 되는, 귀감이 되는 패키지 하나를 제대로 설계하면 그 패키지의 코드 스타일을 따를 수 있다. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.   #노개북   #노마드코더   #개발자북클럽  

1  Hint❕ : 검색하기 쉬운 이름을 사용하세요. blastOFF는 로켓 발사를 의미. 86400000은 하루의 밀리초 (milliseconds) 의미. // What the heck is 86400000 for? setTimeout(blastOff, 86400000); // GOOD 😎 // 위 코드를 깨끗하게 다시 작성해 주세요. ONE_DAY_IN_MILLISECONDS = 86400000 blastOffAfter(ONE_DAY_IN_MILLISECONDS); // 어떻게 고쳤는지, 사례에서 무엇을 배워야 하는지 설명해주세요. 본 코드에서 말하고자 하는 바는 "하루 뒤에 로켓 발사"임. '시간을 정한다' 라는 의미의 함수보다 말하고자 하는 바를 다음과 같이 그대로 표현하였음. '발사한다, 얼마 뒤에? 하루 뒤에.' 2 Hint❕ : 의미있는 이름을 사용해 주세요. const yyyymmdstr = moment().format("YYYY/MM/DD"); // GOOD 😎 // 위 코드를 깨끗하게 다시 작성해 주세요. const now = moment(); const todayDate = now.format("YYYY/MM/DD"); // 어떻게 고쳤는지, 사례에서 무엇을 배워야 하는지 설명해주세요. moment()가 무슨 함수인지 잘 모르겠지만 지금 당장의 시각을 반환하는 , 내가 바꿀 수 없는 표준 함수로 이해했다. 현재 Timestamp에서 yyyy/mm/dd는  오늘의 date에 해당하므로 todayDate라고 명명함 3 Hint❕ : 불필요하게 반복하지 마세요. const Car = {   carMake: "Honda",   carModel: "Accord",   carColor: "Blue" }; function paintCar(car, color) {   car.carColor = color; } // G...

오늘 TIL 3줄 요약 정직한 태도로 코드를 작성하자. 오늘날의 소프트웨어는 대부분 유지보수이며 그렇기 때문에 깨끗한 코드를 만들기 위해 무수한 관심을 쏟아야한다. '코드 감각'을 기르려면 디자인 패턴같은 이론만으로는 부족하고 실천해야한다. TIL (Today I Learned) 날짜 2025. 05. 24 오늘 읽은 범위 추천사 ~ 1장. 깨끗한 코드 기억하고 싶은 내용을 써보세요. 첫 아이 이름 짓듯이 심사숙고하여 변수명을 지어라. 품질은 위대한 방법론이 아닌, 사심없이 기울이는 무수한 관심에서 얻어진다. 간단함 != 단순함 !=쉬움 자신의 코드에 대해 정직하라 세세함에 몰두하는 태도 원칙과 디자인 패턴을 안다고 깨끗한 코드가 나오지 않는다. 르블랑의 법칙은 "나중은 결코 오지 않는다"라는 법칙으로, 소프트웨어 개발에서 "나중에 수정하겠다"는 생각은 실제로는 거의 이루어지지 않는다는 것을 의미. 코드를 개발할 때 미리 깨끗하게 유지하는 것이 중요하며, 그렇지 않으면 나중에 수정하기 어려워지고 프로젝트 전체의 품질에 부정적인 영향을 미칠 수 있다. 나쁜 코드는 개발 속도를 크게 떨어뜨린다. 깨끗한 코드를 만드는 노력은 비용을 절감할 뿐 아니라 전문가로서 살아남는 길이다. 기한을 맞추는 유일한 방법 = 빨리 가는 유일한 방법 = 코드를 언제나 깨끗하게 유지하는 습관 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아님. 깨진 창문 효과 깨끗한 코드는 한 가지에 집중한다. 코드는 추측이 아닌 사실에 기반해야 함 문학적 프로그래밍은 인간이 읽기 좋은 코드를 작성하는 것이다. 중복, 표현력 에 신경 쓰면 코드가 한결 나아진다. + 초반부터 간단한 추상화 고려하기.(집합에서 항목 찾기와 같은 기능 구현시) 깨끗한 코드는 읽으면서 놀랄 일이 없어야한다. 언어 자체가 프로그램을 단순하게 보이게 만들지 않는다. 프로그래머가 한다. 주변 코드를 읽지 않으면 새 코드를 짤 수 없다. 그러므...

    오늘 TIL 3줄 요약 결과를 경고하는 주석은 적절하다. 표준 라이브러리나 프로그래머가 직접 변경할 수 없는 코드라면 의미를 명료하게 밝히는 주석이 유용하다. 되도록이면, 주석이 필요없는, 의도가 명확하게 표현된 코드를 짠다.  TIL (Today I Learned) 날짜 2025. 05. 28 오늘 읽은 범위 4장. 주석 기억하고 싶은 내용을 써보세요. 법적인 이유로 특정 주석을 넣기가 강제되는 경우, 타당한 주석이다. (저작권 정보, 소유권 정보) 이해가 되지 않아 다른 모듈까지 뒤져야 하는 주석은 독자와 제대로 소통하지 않는 주석이다. 코드와 같은 이야기를  중복으로 설명하는 주석을 달지 말자. (함수나 변수와 같은 코드를  또 다시 주석으로 달 필요는 없다.) 지나친 참견의 주석이 많이 있다면, 정작 필요한 주석을 개발자가 무시할 수 있다. 현대에는 VCS, 버전 관리 시스템의 등장으로, 이력을 기록하는 주석을 달 필요가 없어졌으며 저자 또한 기록할 필요가 없다. 위치를 표시하기 위한 주석 //// #### 을 지양하자. 주석으로 처리한 코드는 소스 코드 관리 시스템이 대신 코드를 기억해주기기 때문에 지우기를 주저하지 말자. 너무 많은 기술적, 역사적인 정보를 첨부하지 않기. 모호한 주석으로 주석 자체가 다시 설명을 요구한다면, 좋지 않은 주석이다. 코드 일부에 전역적인 정보에 대한 주석을 달지 않는다. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 TODO 주석을 적극적으로 활용하여 개발팀과 소통해야겠다. 함수 + 인수에 대한 정보를 주석으로 제시하기보다, 함수, 인수를 "잘" 명명하자. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.   #노개북   #노마드코더   #개발자북클럽  

      오늘 TIL 3줄 요약 구현을 감추려면 추상화가 필요하다. 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉽다. 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다. -> 특히 기차 충돌 코드를 피하라. TIL (Today I Learned) 날짜 2025. 06.01 오늘 읽은 범위 5장. 형식 맞추기 기억하고 싶은 내용을 써보세요. 도형 클래스는 간단한 자료구조로, 도형 동작 방식은 Geometry 클래스에서 구현한다. 객체라면 내부 구조를 감춰야 한다. 정확히는, 1. 동작을 공개하고  2. 자료를 숨겨라. 함수나 타입을 보호할지 공개할지에 대한 확신이 부족할 때 잡종 구조가 생긴다.  DTO = 자료 전달 객체 db, 통신을 위한 소켓에서 받은 메시지의 구문을 분석하여 db의 raw data를 애플리케이션의 객체로 변환할 때 유용. 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 새로운 동작을 추가하는 유연성이 필요하다면, 자료구조와 절차적인 코드가 더 적합하다. 활성 레코드는 자료로 취급하며 비즈니스 규칙를 담고 내부자료(높은 확률로 활성 레코드 인스턴스)를 숨기는 객체는 따로 생성한다. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 잡종 구조 !! 내가 최근에 구현한 클래스 인 것 같다. 다시 리팩토링 할 까? 한 때는 이론적인 책이구나라고 생각했는데, 이 챕터를 읽고 생각이 바뀌었다. 아주 좋은 실례를 다루고 있어서 고개를 끄덕이면서 읽게 되었다. 특히, 활성 레코드의 취급에 대한 부분이 명쾌했다. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.   #노개북   #노마드코더   #개발자북클럽  

< 빠른 학습엔 3분할 뷰 >   JS와 JS 프레임워크를 독파하고있다. 새로운 언어나 프레임워크를 학습하는 데 있어서 탐구자형 ~ 실속형의 스펙트럼이 있다면 이번 러닝 사이클은 전부 실속형에 치중했다. Vanilla JS https://cpusuite.blogspot.com/2025/02/djnago-fullstack-html-css-vanillajs-js.html Django fullstack 사이드 프로젝트를 하면서 기초적인 html + css + js를 학습했는데 웹 브라우저의 기초인 만큼 vanilla js를 좀 더 체계적으로 기억하기 위해 노마드 코더의 vanilla JS 2주 챌린지를 신청했다. Python 기반으로 개발을 했었기 때문에 js의 동적 타이핑 문법이 이질적이지 않았고 맨 땅에 헤딩식으로 진행한 사이드 프로젝트의 html + css + js 경험 덕에 이틀 안에 50% 이상의 강의를 수강했다. 3일째 되는 날, 수강을 전부 끝내고 남은 React JS, React Native를 실습 할 예정이다. JS Framework로 작성한 소스 코드는 곧 JS로 변환되어 실행되기 때문에 프레임워크 학습 이전에 선행하는 것이 좋다. React JS Frontend Framework html로 작성한 class, id 명을 js에서 검색하여 따르기보다 js로 직접 동적으로 문서 객체를 생성한다. 참조하기도 간편하고 관리하기도 쉬우며 raw value를 하드코딩하는 것을 줄여 개발자의 실수를 줄인다.  react   React element의 interaction. element 생성, event listener 등록 등 react-dom React element를 html에 두는 역할. React Native 메타(구 facebook)에서 만들고 관리하는 오픈소스 모바일 애플리케이션 프레임워크. Typescript(JS확장)으로 개발할 수 있고 Flutter처럼 iOS Android 2가지 플랫폼을 동시에...

        오늘 TIL 3줄 요약 프로그램에 필요한 인터페이스만 클래스에서 제공하여 코드를 이해하기 쉽지만 오용하기 어렵게 한라. 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. 테스트 함수 하나는, 개념 하나만 테스트하고 개념당 assert 문 수를 최소로 줄여라. 깨끗한 테스트의 다섯 가지 규칙, FIRST Fast : 테스트는 빨리 돌아야 한다. 빨리 돌아서 자주 실행해야 한다. Independent : 각 테스트가 서로 의존하면 안 된다. Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다.                       테스트가 돌아가지 않는 환경이 하나라도 있다면                       (QA, Production, Test, local development 등)                       실패의 변명이 생긴다. Self-validating : 부울 값으로 결과를 내야 한다.                            성공 아니면 실패다.                            텍스트 or 로그 파일에 따로 만들어서 결과를 비교하지 않는다. Timely : 테스트는 적시에 작성해야 한다.              ...

   오늘 TIL 3줄 요약 switch를 사용해야한다면 추상 팩토리에 숨겨라 여러 섹션으로 나뉘어진 다는 것은 여러 일을 하고 있다는 뜻. 부수효과를 일으키지 마라. 이는 남몰래 거짓말하는 것이다. TIL (Today I Learned) 날짜 2025. 05. 26 오늘 읽은 범위 3장. 함수 기억하고 싶은 내용을 써보세요. 오류 오류 처리도 한 가지 작업이며 오류를 처리하는 함수는 오류만 처리해야한다. 함수에 키워드 try가 있다면 catch/fianlly로 끝나야한다. 새 오류 코드를 추가하는 대신 기존 오류 코드를 재사용한다. 오류 코드보다 예외를 사용하라. 명령과 조회 구분하기 함수는  뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 함. 둘 다하면 혼란을 일으킨다. 반복(중복) 소프트웨어에서 중복은 악의 근원이다. 많은 원칙과 기법이 중복을 제어하고 없애기 위해 탄생했다.   ...DB에서 중복을 피하기 위해 정규식을 사용한다. ...OOP에서 - 코드를 부모 클래스로 몰아서 중복을 없앤다. ...구조적 프로그래밍에서 - 함수는 return 문이 하나여야한다. - 루프 내에서 break, continue를 쓰지 말 것.   goto는 절대로 쓰지 말 것, * 처음 작성한 함수가 뒤죽박죽이더라도 다듬으면서 항상 단위 테스트를 통과하게한다. * 대가 프로그래머는 시스템을 구현할 프로그램이 아니라 풀어나갈 이야기로 여긴다. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 상당히 빡빡한 기준을 가지고 있으며 한 가치 원칙을 고수하다가 다른 원칙을 무시해버리는 상황이 잘 발생할 것 같다. 특히, 추상적인 작업, 개념을 Class화하는 것은 두려운 작업임. 기준 없이 2개, 3개정도의 함수 인자는 막연하게 괜찮다 생각했는데 될 수 있으면 0개로 유지하라는 덕에 혼난 기분이 든다. 나도 도메인 특화 언어를 작성하고 있는 프로그래머다. 이 사실에 자부심을 가지자! 나는 시스템이라는 이야기를 풀어나가고 ...

* 11장부터는 노마드 코더 개발자 북클럽 챌린지가 아닌   개인적으로 읽고 작성한 후기입니다.