📚 클린코드 1장 깨끗한 코드 및 2장 의미 있는 이름 을 읽고 생긴 궁금증을 정리해 보았습니다
동아리 트랙을 운영하게 되어 평소 하고 싶었던 서적 읽고 블로그 쓰기를 하기로 했습니다!
하나의 주제에 대해 깊이 고민하고 포스팅하는 것을 은근히 안 하게 되어서...
함께 진행하고 또 파생된 다양한 생각들을 보고자 했어요
근데 생각보다... 깊이 다룰 주제를 아직은 찾기 어려워서 1장 2장을 읽으며 좀 더 찾아 봐야겠는데? 생각했던 것들을 가볍게 적어 보고자 합니다
프로젝트를 진행하다 보면 서로가 너무 다른 느낌으로 코드를 짜서 누가 봐도 다른 사람이 짠 것 같은 티가 날 때가 있습니다!
학부생의 프로젝트이고 어쩔 수 없지만서도 이걸 보면서 문득 든 생각이 특정 한 회사의 코드 원칙 (이하 코드 컨벤션)을 적용할 수도 있지 않았을까? 싶네요
이걸 왜 이제서야 떠올렸을까
그래서 몇 가지 유명한 회사의 코드 컨벤션을 대략 훑어 보고자 합니다
https://naver.github.io/hackday-conventions-java/
위를 읽고 몇 가지 평소에 아무 생각 없이 저질렀던 것들을 반성하게 되었습니다
https://google.github.io/styleguide/
다양한 언어가 모두 기재되어 있습니다!
자바 부분만 나중에 각잡고 읽어 볼 예정입니다
checkstyle이라는 도구로 인텔리제이에서 특정 컨벤션을 준수하도록 설정할 수 있다고 합니다!
어떠한 예시가 있을까 궁금해서 좀 찾아봐야겠다 생각하고 메모해 둔 주제인데 특별하게 설명할 게 없기는 하더라고요
해당 주제를 다루고 싶었던 이유는 사실 코드를 작성하다 보면은 너무 고려해야 될 점들이 많기에 하드웨어적인 부분이 조금 뒷전이 되는 경우가 많았습니다
따라서 자원 (CPU와 메모리)를 좀 더 효율적으로 쓰는 방법을 뒤늦게 고민하고는 하는데 지켜야 할 규칙이 따로 존재하는가 싶었는데 그렇지는 않더라고요
무한 루프(Infinity Loop): 프로그램이 끝나지 않는 무한한 반복문을 실행하는 경우 CPU 자원을 계속 소비합니다. 이로 인해 CPU가 다른 작업을 수행할 여유가 없어집니다.
비효율적인 알고리즘: 비효율적인 알고리즘을 사용하면 CPU가 작업을 완료하는 데 오랜 시간이 걸릴 수 있습니다. 예를 들어, 정렬 알고리즘을 선택할 때 효율성을 고려하지 않으면 CPU 자원을 낭비할 수 있습니다.
불필요한 대기 상태: CPU를 사용하지 않는 동안 프로그램이 대기 상태에 있을 때도 CPU 자원을 낭비합니다. 이것은 예를 들어 파일을 읽거나 네트워크 요청의 응답을 기다리는 동안 발생할 수 있습니다.
스핀락(Spinlock): 다중 스레드 환경에서 스핀락을 잘못 사용하면 CPU가 계속해서 스핀락을 확인하며 대기하게 됩니다. 이는 다른 스레드가 실행할 기회를 얻지 못하고 CPU 자원을 낭비하게 만듭니다.
부적절한 리소스 관리: 리소스를 효율적으로 관리하지 않는 경우, CPU 자원을 낭비할 수 있습니다. 예를 들어, 너무 많은 스레드를 생성하거나 메모리를 불필요하게 많이 사용하는 경우 CPU가 작업을 처리하는 데 더 많은 시간을 할애해야 합니다.
무한 대기 상태(Deadlock): 다중 스레드나 프로세스 간에 서로를 기다리며 블록시키는 경우, CPU가 낭비될 수 있습니다. 이러한 상황을 무한 대기 상태 또는 데드락(Deadlock)이라고 합니다.
비효율적인 I/O 작업: I/O 작업을 수행할 때 비효율적인 방식으로 파일 또는 네트워크 리소스를 사용하는 경우 CPU가 불필요하게 대기하거나 작업을 반복할 수 있습니다.
이러한 상황을 피하기 위해서는 코드를 최적화하고, 효율적인 알고리즘을 선택하며, 리소스를 효율적으로 관리해야 합니다. 또한 다중 스레드나 프로세스를 사용할 때는 동기화를 신중하게 처리하여 CPU 자원의 낭비를 최소화해야 합니다.
챗 지피티의 도움을 받아 간단하게 작성해 보았는데 읽어 보니 이거... 알고리즘을 공부하며 어느 정도 터득한 사실인 것 같네요 뜻밖의 알고리즘 공부 다짐을 하며 글을 마무리하려 했는데 문득 이에 파생된 주제가 생각나서 밑에 추가적으로 적겠습니다
이거는 프로젝트를 진행하며 상대분이 이렇게 활용하시길래 문득 궁금해져서... 작성해 봅니다!
저는 자동으로 알아서 배치를 해서 데이터 베이스 os가 그것을 관리하는 게 아닌가? 즉, 실제로는 메모리 효율적인 문제로 제가 배치를 하더라도 파편화되어 보관할 수도 있고~ 그것은 os가 관리하지 않을까? 하는 생각으로 10 100 등으로 할당하려 했으나 2의 거듭제곱으로 할당하는 게 어떻겠냐고 질문 주셔서 그렇게 진행하였습니다!
=> 적절한 답변을 찾지 못해 역시나 지피티에게 물어봤더니 효율성의 측면에서 더 낫다고 합니다
생각해 보니 관리해 주는 OS가 있다고 하여도 결국 더 효율적으로 입력할수록 OS가 할 일이 줄어들 것 같다는 생각이 듭니다
추후 더 정확한 자료를 찾게 될 경우 수정하여 추가하겠습니다
무슨 뜻으로 작성했는지 명확하게 이해하기 어려워서 추가 개념을 찾아 보았습니다
설명을 찾아 보니 이미 준수하고 있는 사항이었지만 문장을 보니 무슨 말인지 이해가 안 돼서 추가 설명을 첨부합니다!
"생성자를 중복 정의할 때는 정적 팩토리 메서드를 사용한다"는 객체 지향 프로그래밍에서의 디자인 원칙 중 하나입니다. 이 원칙은 객체를 생성하는데 있어서 생성자(constructor)보다는 정적 팩토리 메서드(static factory method)를 사용하는 것을 권장합니다.
가독성과 의미 전달: 정적 팩토리 메서드는 이름을 가질 수 있으며, 이름을 통해 해당 메서드가 어떤 종류의 객체를 생성하는지 명확하게 드러낼 수 있습니다. 생성자는 객체의 타입에 대한 정보를 이름에서 바로 알기 어렵기 때문에 가독성이 떨어질 수 있습니다.
재사용성과 캐싱: 정적 팩토리 메서드를 사용하면 매번 새로운 객체를 생성하는 대신, 기존 객체를 재사용하거나 풀링(pooling) 등을 통해 성능을 최적화할 수 있습니다. 이를 통해 불필요한 객체 생성을 방지하고 자원을 효율적으로 관리할 수 있습니다.
하위 클래스 확장과 유연성: 정적 팩토리 메서드는 하위 클래스를 사용하여 객체를 생성하고 반환할 수 있으므로, 팩토리 메서드 패턴을 활용하여 객체 생성과 관련된 로직을 하위 클래스에 숨길 수 있습니다.
생성자 시그니처 변경 회피: 클래스의 생성자 시그니처를 변경하려면 기존 코드를 수정해야 합니다. 하지만 정적 팩토리 메서드를 사용하면 시그니처를 변경하지 않고도 새로운 버전의 객체 생성 메서드를 추가할 수 있습니다.
싱글톤(Singleton) 패턴과 같은 디자인 패턴 적용: 정적 팩토리 메서드를 통해 싱글톤 객체를 생성하거나 객체 생성 방식을 조절하는 등의 디자인 패턴을 적용할 수 있습니다.
아래는 정적 팩토리 메서드를 사용하는 예제입니다:
public class MyClass {
private int value;
// 생성자를 사용하지 않고 정적 팩토리 메서드를 정의
public static MyClass createInstance(int initialValue) {
MyClass instance = new MyClass();
instance.value = initialValue;
return instance;
}
public int getValue() {
return value;
}
}