요즘 팀플젝을 깃허브로 하고 있는데, 저 두 파일이 자꾸 떠서 신경쓰여서 찾아봤다. pom.properties 응용프로그램의 구성 가능한 파라미터들을 저장하기 위해 자바 관련 기술을 주로 사용하는 파일들을 위한 파일 확장자라고 나와있다. ko.wikipedia.org/wiki/.properties .properties 위키백과, 우리 모두의 백과사전. .properties는 응용 프로그램의 구성 가능한 파라미터들을 저장하기 위해 자바 관련 기술을 주로 사용하는 파일들을 위한 파일 확장자이다. 국제화와 지역화를 위 ko.wikipedia.org MANIFEST.MF ko.wikipedia.org/wiki/%EB%A7%A4%EB%8B%88%ED%8E%98%EC%8A%A4%ED%8A%B8_%ED%8C%8C%E..
꾸역꾸역 프로젝트를 진행하고 있었는데... 열심히 해서 진도를 빼놓고 다른 기능 추가하고 있는데 갑자기 400이 떴다. 콘솔에도 아무 것도 안 찍히고, 400만 뜨니 답답해죽을 지경이었는데... form에서 전송방식을 (원래는 POST였다.) GET으로 바꾸는 아주 간단한 방법으로 다음 페이지로 전달되는 변수들을 확인했더니 한 놈이 제대로 안 가고 있었다... 그래서 수정하다가 혹시 까먹을까봐, 그리고 누군가에게 도움이 될까해서 글로 써둔다. 400이 뜨면 주소창을 통해 데이터가 제대로 가고 있는지 확인하자... 값이 맞다면 데이터 타입을 의심해보는 게 좋을듯하다.
요즘은 스프링을 공부하고 있는데 좀 더 깊게 알고 싶은 마음에 낮에는 학원에서 공부하고 밤에는 추가적으로 스프링 인터넷강의를 듣고 있다. 그러다보니 학원에서는 A를 알려주는데, 인터넷강의에서는 B를 알려주는 경우가 있다. 오늘이 그랬다. 학원에서는 Bean을 설정할 때 xml파일을 통해 의존관계 주입 설정하고 아래와 같은 코드를 사용했다. ApplicationContext context = new ClassPathXmlApplicationContext("config.xml"); 그런데 오늘 스프링 인터넷강의를 듣다보니 자바로 config클래스파일(Config)을 만들고 아래와 같은 코드를 사용했다. ApplicationContext applicationContext=new AnnotationConfigA..
요약에 들어가기 전에 에서 말하는 객체와 자료구조의 의미 차이를 정리해둘 필요가 있어서 여기에 정리해둔다. 실제 현업에서도 이런 것을 자료구조라고 하는지는 모르겠지만. 객체란 자료를 숨기고 공개한 함수로 그 숨긴 자료를 다루는 것이고, 자료구조는 자료는 공개하되 아무 메서드도 제공하지 않는 것을 말한다. 객체라고 하면 private으로 인스턴스 변수를 선언하고 그 외의 메서드들을 가지고 있지만, 자료구조는 멤버변수만을 가지고 있는 것이다. 이 책에서는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다고, 아무 생각없이 getter/setter 메서드를 만드는 것이 제일 나쁘다고 한다. 객체(객체지향기법)와 자료구조(절차적인 코드)는 요약 전에 설명한 것 같은 차이가 있기 때문에 서로..
ko.wikipedia.org/wiki/휴리스틱_이론 휴리스틱 이론 위키백과, 우리 모두의 백과사전. 휴리스틱(heuristics) 또는 발견법(發見法)이란 불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 ko.wikipedia.org 클린코드를 읽다가 휴리스틱이라는 말이 나와서 찾아봤다. 복잡한 문제를 단순화시킬 때 사용한다는듯. '어떤 문제를 해결하거나 제어하기 위해 필요한 정보를 느슨하게 적용시키는 접근을 시도하는 전략'이 제일 맞는듯하다.
코드를 작성하면서 굳이 고쳐야 한다거나, 집중해서 신경쓰지 않았던 것이 있다. 바로 형식 맞추기. 누구나 코딩을 한다면 굳이 크게 신경쓰지 않고, 처음의 그 습관을 그대로 가져가는 경우가 많을 것 같다. 클린 코드에서 굳이 한 챕터를 '형식 맞추기'로 꺼낼 정도로 의미가 있나 싶기도 했는데 읽어보니 역시 그렇구나, 하고 고갤 끄덕이게 됐다. 한 파일은 200줄 정도로 하는 것이 바람직하다. 가로로도 저자 개인적으로는 120자 정도로 행 길이를 제한한다고 한다. 개념은 행(띄어쓰기)으로 분리해야 한다. 서로 밀접한 개념의 경우는 가까이 둔다. 변수는 사용하는 위치에 최대한 가까이 선언하고, 인스턴스 변수들은 메서드와 섞이지 않게 한쪽으로 잘 정리한다.(보통은 위쪽) 한 함수가 다른 함수를 호출할 때도 가까..
나는 평소에 협업을 하기 위해서는 내 코드를 보기 편하게 만들 필요가 있다고 생각했고, 그래서 주석을 자주 활용하곤 했는데 이 부분을 읽으면서 그게 과연 맞는 것일까 하는 생각이 들었다. 저자는 주석을 다는 것을 지양해야 한다고 말하고 있다. 주석을 다는 것보다 코드로 충분히 표현할 수 있는 방법을 찾아야 한다고. 우리의 일은 코드를 짜는 것이지, 주석을 짜는 것이 아니기 때문에 코드를 작성하고 수정하다보면 주석이 그 자체의 의미를 잃어버릴 수 있기 때문이다. 예전의 코드는 수정됐지만, 주석은 업데이트되지 못하고 예전의 상태를 유지하는 걸 (짧은 경험이지만) 많이 봐왔고, 느꼈다. 결국 주석은 거짓이 되어버리고, 주석을 단 의미가 사라진 것이다. 그럼에도 저자가 좋은 주석이라고 생각하는 몇 가지가 있었다..
https://ko.wikipedia.org/wiki/SOLID_(객체_지향_설계) SOLID (객체 지향 설계) 위키백과, 우리 모두의 백과사전. ko.wikipedia.org 의 저자인 로버트 C.마틴이 소개한 좋은 객체 지향 설계의 5가지 원칙이다. 1. SRP : 단일 책임 원칙(Single Responsibility Principle) - 하나의 클래스는 하나의 책임만.(변경이 있을 때 파급효과가 적어야 한다.) 2. OCP : 개방-폐쇄 원칙(Open/Closed Principle) - 소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다. -> 다형성 활용! 3. LSP : 리스코프 치환 원칙(Liskov Substitution Principle) - 프로그램의 정확성은 유지하..