일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 개발
- 코드
- 그리디알고리즘
- 프레임워크
- 애자일프로그래밍
- 그리디
- 코딩
- ES
- database
- Java
- Baekjoon
- Spring
- Elasticsearch
- 코딩테스트
- 클린코드
- 데이터베이스
- cleancode
- 자바
- 애자일
- framework
- 엘라스틱서치
- 알고리즘
- 애자일기법
- 스프링
- spring boot
- API
- 백준
- 읽기쉬운코드
- 개발자
- JPA
- Today
- Total
목록개발 (14)
튼튼발자 개발 성장기🏋️
본 글은 소프트웨어 학습 태도를 읽고 참고하여 개인적인 생각과 경험을 바탕으로 작성한다. 1. 내가 걷는 속력과 방향을 인지하자. 개발은 혼자 하는 것이 아니다. 같은 팀원, 타 팀원, 그리고 관리자와 함께 진행한다. 이렇게 많은 사람들과 함께 업무를 진행하면서 각각 업무량도 다를 것이고 각자 일처리 속도와 습득속도 등 차이점이 있을 수 있다. 특히 일처리 속도에 대해서는 개발방향을 잘못 잡거나 필요한 기술 학습에 대해 잘못 접근하는 등에 이유로 인해 필요 이상으로 시간을 낭비할 수도 있다. (물론 언젠가는 도움이 될 수도 있겠지만 당장 처리해야하는 업무 관점에서 볼 때는 시간낭비) 문제 해결을 위해 방안을 몰색하고 방안을 구현하기 위해 필요한 부분들을 학습하여 내가 맞닥뜨린 문제와 일관성이 있는지 판단..
존경하는 어느 팀장님께서 추천해주신 또 다른 책. 경력을 쌓는 방식과 관점을 만들어주고 시야를 넓혀준다. 그러나 모두 공감대를 형성하지 않았고 때때로 비판하고 "왜?"라고 되묻는다. 때론 겸허히 수긍한다. 제목을 처음 보았을 때 팀장님께서 갑자기 왠 소설책을 추천해주시길래 당황했던 기억이 난다..ㅎㅎ 도입부부터 인도의 IT 이야기로 시작하기에 정말 소설을 읽는 줄 알았다..하핳 이 책 저자가 말하고 싶은 것은 "진정 개발자가 되고 싶으면 노력해라."인데 어떻게 노력해야하는지에 대해서 서술하였다. 연구하고, 투자해라. 그리고 실행에 옮기고 이제 마음껏 자기PR을통해 자신을 마케팅하라. 사실 이 모든게 대학생 때 끝내는 것이아니라 평생 연구하고 투자해야한다고 생각한다. 기술은 나날이 발전하고 새로운 기술이 ..
TDD는 상당히 어려운 부분인 것 같다. 이전에도 TDD에 대해서 여러가지 알아보았는데 너무 깊게 들어갔는지 이해도 할 수 없었고 어떻게 해야할지고 모르겠어서 포기하고 말았다👊 짧게나마 다시 TDD 관련 글을 보았다. 쉽게 설명되어 잘 읽혔지만 새발의 피인 것을 우째😥 TDD 주제 하나로 책 한 권을 낼 수 있는데 여긴 고작 한 챕터로 다루고 있다. 언젠간 꼭 TDD를 아주 잘 설명한 책이 있다면 읽어보고 말테다! 가장 핵심은 테스트 코드 또한 깨끗하고 보기 좋아야 본 코드가 수정이되거나 새 기능이 추가되어도 테스트 코드도 쉽게 작성할 수 있다. 즉 가독성이 최우선이라 할 수 있다. FIRST 조건을 잘 되새김질 해보며 이해를 도와보자🤟
우리가 무언가를 개발 할 때에 모든 것들을 전부 만들지는 않는다. 외부 패키지를 사용할 수도 있고 잘 짜여진 프레임워크를 쓸 수도 있고 오픈 소스를 사용할 수도 있다. 모두가 하나같은 마음을 가지면 좋겠지만 각기 다른 성격과 특성을 가지고 있고 서로 다른 목적이 뚜렷하고 그 목적에 맞게 설계되어 mix하여 사용할 땐 큰 어려움이 따른다. 이를테면 버전이 호환 안되서 잘 따져 보아야 하고, 캡슐화, 독립성 등을 고려해서 구조를 잡아 가는 것이 핵심. 그 외에도 고민해야할 것들이 많을 것 같다. 난 이 책을 읽고 Map이 얼마나 위험하고 귀찮게 하는 녀석인지 깨달았다. Map을 사용할 땐 캡슐화를 고려해보자!!!☝️ 그 이유는 Map(Collection과 같은) 혹은 Object 등 많은 데이터를 포함할 수..
조금씩 책의 내용이 어려워지고 있다. 한 문장을 무려 10번 읽고 되새김질 해보기도 한다.ㅠㅠ 최근 나는 싱글톤을 사용하여 개발한 적이 있는데 싱글톤 특징을 제대로 살리지 못하는 실수를 하고 말았다...😥 바로 생성자를 자동생성 생성자로 두었던 것... 알고 있으면서도 알아차리지 못했던게 더 괴씸하다!!! 경솔한 나의 생각때문에 큰 오류를 범할 뻔했다. java에서 access level을 둔 이유가 다 있다. 그것을 잘 활용하여 지켜주어야 한다..🙄 잘 생각해보면 protected는 거의 써본적이 없는 것 같고 변수는 private, 메소드는 public을 많이 사용하는데 이런거 하나하나 생각하면서 코드를 작성해야한다는걸 몸소 느끼며 깨달았다. 너무 익숙해지지 말자. 코딩에 당연한건 없다! 난 이 책을..
문제 기출 : [https://www.acmicpc.net/problem/1541] 풀이 방법 [그리디알고리즘] 접근 연산자는 +와 -만을 다루고 피연산자는 양수인 것만 알아도 쉽게 접근할 수 있다. 괄호를 사용해서 최소값을 만든다고 했는데 괄호에 현혹될뻔했다. 먼저 +연산 먼저 해서 크기를 키운 다음 -연산을 하면 되지 않는가? 한 마디로, +연산으로 최대한 값을 키운 다음 그 값을 빼면 최소 값을 쉽게 도출할 수 있다. 식에서 '-'를 기준으로 식을 잘라 저장하면 나머지는 +연산이 되고, 그 값을 모두 더한 다음 -연산하면 정답을 빠르게 구할 수 있다. ※ 번외. 어디선가 비슷한 문제를 풀어본 적이 있다. 문자열로 사칙연산과 괄호를 포함한 문자열(String)을 input으로 주고 그 연산을 실행한 ..
좋은 주석은 뭐고 나쁜 주석의 차이는 뭔지 곰곰히 생각해보자.. 내 생각은 좋은 주석은 없다. 주석이 없는 주석이 가장 좋은 주석이다. 물론 코드가 개발자 의도를 100% 표현 했다는 가정 하에!☝️ 나의 경우는 내가 짠 코드의 일부분을 혹시나 다른 개발자가 못알아 듣거나 이해를 못할까 걱정이 되어 주석을 사용하곤 한다. 즉 내가 나를 못믿는데 누군가 나를 어떻게 믿을까😥😥😥 대부분의 주석은 쓸때 없는 주석, 주절거리는 주석 등으로 이루어 지지만 난 가장 필요한 주석은 히스토리 주석과 TODO주석이라 생각한다. ☝️소스코드 관리 시스템이 있다 한들, 특정 부분이 수정된 사유와 날짜 등을 파악하려면 시간을 들여야한다. ✌ TODO주석이 있다는 말은 일을 다 못끝냈다는 이야기. 그러나 그 누가 하루만에 개발..
문제 기출 : [https://www.acmicpc.net/problem/11399] 풀이 방법 [그리디알고리즘] 접근 굉장히 쉽게 접근할 수 있다. Pi를 오름차순으로 정렬해서 최소로 걸리는 사람부터 탐색하는 것이 기본. 다음과 같은 조건을 만족하면 된다. 기다리는 시간 = i번째 사람이 돈 뽑는데 걸리는 시간 x (사람 수 - i) 즉 기다리는 시간을 누적해 나아가면 답이 나올 것이다. 문제 풀이 public class Main { public static void main(String[] args) { int answer = 0; Scanner sc = new Scanner(System.in); int peopleCount = sc.nextInt(); int[] peopleTime = new int..