밤에 쓴 코드

객체와 자료구조 객체는 일을 한다 . 자료구조는 자료를 저장한다. 이 둘을 적절한 상황에 사용하기 위해 한번 공부해보자 우리는 객체를 디자인함에 있어서 , 객체의 내부의 변수를 private로 감추어둔다. 외부의 객체가 내 변수에 의존하지 않게 하기 위해서 이다. 변수의 수정에 외부에 영향을 주지 않게 하기 위해서, 외부에서는 내 변수에 대해 아무것도 모르게 하려고 더 좋은 구조를 위해서 변수의 수정에 자유로울 수 있기 위해서이다. 객체는 내부의 구현을 숨기고 *객체가 무슨 일을 하는지 * 만을 공개한다. 자료구조는 내부의 변수(자료)를 공개하고 별다른 동작을 하지 않는다 struct MyPoint { private var x: Int private var y: Int func getX() -> Int ..

형식맞추기 코드형식은 의사소통형식이다. 가독성 수준은 유지보수 용이성과 확장성에 밀접하게 영향을 준다. 코드는 일차적으로 구현을 생각하고 , 기능이 수행되는 것에 만족해왔었다. 그 이유중 하나는 왜 깨끗하게 코드를 짜야할까? 의문을 가져본 적이 없었고, 그 이유를 몰랐었다. 왜냐면 난 학생이었고, 언제나 혼자 소프트웨어를 개발해왔었으며, 한번 완성된 소프트웨어에 기능을 수정하고, 기능을 추가하는 등, 변경되는 요구사항에 대해서 소프트웨어를 지속적으로 수정해 본 적이 없었다. 깨끗한 코드 ? 좋다는 건 알겠다. 깨끗한 코드 그게 기능구현의 중요성에 비해 노력을 투자할 가치가 많이 있는가? 를 항상 의심해왔다. 우리가 사용하는 소프트웨어는 대부분 단 한명의 개발자가 완성하지 않고, 많은 유능한 개발자들이 함..

주석 주석은 기껏해야 필요악이다. - 로버트.C.마틴 책을 읽기전까진 , 주석은 읽기 편하게 설명을 해주고 있다고 느꼈고, 꼭 필요하다고 생각했었다. 코드를 읽는 것보다 주석을 읽으면 빠르게 이해되고, 이해가 안되는 코드도 주석을 읽고 보면 술술 읽혀 나갔던 적이 많았다. 하지만 이 책에서는 주석은 코드의 실패라고 한다. 내가 주석이 유용하다고 느낀 건 주석이 유용해서가 아니라 코드가 의도를 표현하지 못하고 복잡하고 명료하게 작성되서라는 것을 알게 되었다. "주석이 필요한 코드는 잘못 작성된 코드이다" 라고 생각된다. // 이름을 가져오는 메서드 func get() -> String { return self.name } 위와 같이 주석이 메소드의 동작을 설명해주는 주석을 보는 것보다는 func getNa..

함수 함수는 작게 작게 작게 길어지면 읽기힘들다 인덴트가 2단 이상이면 읽기 힘들다 한가지만 해라 큰개념을 하는 메소드는 더 작은 개념을 수행하는 메소드들로 나누어야한다. 내부에서 의미있는 이름의 동작로 분할해 낼 수있다면 , 한가지 일을 하지 않는다는 증거이다. // 안좋은 예 func getCoffee()->Coffee{ let coffeeMenu = readLine() // 커피 메뉴를 입력 받는 의미있는 동작을 내부에 포함하고있다. let coffee = Coffee(menu:coffeeMenu) return coffee } // 사실상 어떤 커피를 만들지 입력을 받고 출력을 하고있다. TO문단으로 확인해보자 메소드명 하기위해서 , 코드 의 동작을 해야한다. func getCoffee(menu:S..

의미있는 이름 의도를 분명히 밝혀라 명확한 이름이 좋다 짐작하기 쉽게 함축성을 가진 코드는 의도를 숨긴 코드이다. 단순성과 함축성은 다르다. // 함축적 -> 무슨 일을 하는지 구체적으로 드러나지 않은 이름 func getList() -> [String] { } // 짐작하기 쉬운 이름 func getNameOfFriendsList()->[String]{ } 올바른 정보 유사한 개념은 유사한 표기법을 사용한다. func add(_ item:Int ){ // 배열에 추가하는 로직 } func append(_ item:Int ){ // 배열에 추가하는 로직 } 같은 기능을 수행하나 표기가 다른 건 잘못된 정보전달의 예 이다. 널리쓰이는 단어를 다른 의미로 사용하는 것도 옳지않다 func getFriendLi..