잼있는 블로그

어플리케이션의 복잡도를 다루기 위해 적절한 응집도와 결합도를 찾아야 한다. SOLID는 높은 응집도와 낮은 결합도를 위한 OOD의 설계 원칙이다. SOLID SOLID는 지향해야 될 목표로 이상향에 가까움 현실적인 문제로 Trade off는 항상 있다. SRP(Single Responsibility Principle)::단일 책임 원칙 하나의 객체는 하나의 책임을 가져야 한다. ex) 예금 잔고 객체 단일책임은 정해진 게 아니라 어디까지 하나의 책임으로 볼 건지 고민 필요 입금, 출금이 있을 때 입출금 하나의 책임인지 따로따로가 단일 책임인지에 대한 고민 하나의 객체가 있는데 두개의 책임이 있다면 분리 package main ​ type FinanceReport struct { ​ } ​ func (r ..

delete는 builtin 함수로 아래와 같이 나와 있는데 no-op가 궁금해서 찾아봤다. // The delete built-in function deletes the element with the specified key // (m[key]) from the map. If m is nil or there is no such element, delete // is a no-op. func delete(m map[Type]Type1, key Type) Unnecessary guard around call to delete 아래와 같이 map에 key가 있는지 채크하고 있으면 지우는 코드를 짰을 때 그렇게 할 필요 없다고 staticcheck에서 알려준다. sampleMaps := []map[string..

Concurrent한 HTTP Requests가 python과 go는 어떻게 다른지 알아봅니다. multiple requets를 간단하게 go로 작성하여 직접 확인해 봤습니다. python으로는 httpx를 사용해볼 수 있겠습니다. package main import ( "encoding/json" "fmt" "log" "net/http" "sync" "time" ) type response struct { Hello string `json: "hello"` Client string `json: "client"` } func main() { defer timeTrack(time.Now(), "main") server := []string{"A", "B", "C", "D", "E"} var wg sync...