회고 (335) 썸네일형 리스트형 UML 실전에서는 이것만 쓴다 로버트 C.마틴 지음 이용원,정지호 옮김 유명한 저자 로버트 C.마틴의 책은 정말 실전에서 쓰는 유형들을 압축해서 보여줍니다. 이 책에서 놀라웠던 것은, 세세한 백과사전으로 우리에게 사용법을 안내하는 것이 아니라, UML이란 어떻게 활용해야 하는가, 정말 실전에서 사용할만한 효과적인 방법들은 무엇인가, 더 나아가 객체지향은 무엇인지까지도 설명합니다. 절대 UML의 사소한 사용법으로 에너지를 낭비하지 말 것을 당부하며, 결국 코드로 증명하는 것이 최고임을, 절대로 UML을 몇백장 심지어 몇십장을 그리는 행위를 그만두라고 엄청나게 강조합니다. 왜 모델을 만들어야 하는가? UML 다이어그램에는 확고한 시험 기준이 없다. 우리가 UML 다이어그램을 살펴보고 평가하고 여러 원칙과 패턴을 적용할 수는 있지만 언제나.. TIL_2022.09.19 1. Facts(사실, 객관) - TDE를 위한 DB 복호화 하기 2. Feelings(느낌, 주관) 특정 칼럼의 DB를 복호화해야하는데, 해당 암호화 함수를 사용하지 않으면, 복호화 시 오류가 납니다. 1000만건이 넘는 데이터가 있는 특정 칼럼을 복호화 해야 하는데, 몇 건이 제대로 암호화가 되어있지 않아서 오류가 났습니다. 저는 그 오류를 칼럼의 길이를 기반으로 알아보려고 했는데, 그걸로는 특정할 수 없었습니다. 팀장님이 도와주셨는데, 복호화를 하는데, 오류가 난 것을 새로운 테이블에 INSERT 하도록 프로시저를 돌려서 특정 경우들을 따로 분리해냈습니다. 그래서 복호화가 되지 않은 칼럼들을 따로 분리해냈고 특정 경우를 처리해서 모두 복호화가 제대로 될 수 있도록 했습니다. 저는 이런 아이디어를 생.. TIL_2022.09.16 1. Facts(사실, 객관) - 'The Nature of Software Development' 정리 - 'UML 실전에서는 이것만쓴다' 읽기 - 개인 프로젝트 페이징 코드 개선 - 개인 프로젝트 스터디 조회 오류 개선 2. Feelings(느낌, 주관) 개인프로젝트에서 Querydsl을 이용해 조회하는 것까지는 잘 했다고 생각했는데, 쿼리를 몇번이나 날리는지는 유심히 살펴보기 않았습니다. 그러다가 지연로딩에서 쿼리문이 많이 나간다는 것을 알게되었고 개선해야겠다고 생각했습니다. in절을 활용하도록 default_batch_fetch_size를 사용했습니다. 수십번의 쿼리가 나가던 것에서 한번에 쿼리가 나가도록 수정이 되어서 기뻤습니다. 3. Findings (배운 점) - default_batch_f.. TIL_2022.09.15 1. Facts(사실, 객관) - 각종 잡일 처리 - 통계 조회 오류 수정 - 홈페이지 새로운 이미지 파일등 적용 - 모바일 발주서 조회 안되던 것 수정 2. Feelings(느낌, 주관) 대부분 업무는 무난하게 처리했는데, 모바일 화면에서 발주서가 갑자기 조회가 안된다는 연락에 계속 고민했습니다. 딱히 개발로 해결되는 것이 아니라 인프라 요소가 들어갔습니다. 내부망으로 사용하는 프로그램과 달리 모바일은 외부망에서도 접속이 가능한데, 따라서 협력사는 모바일 버전을 하나의 설치형 파일로 만들어서 배포를 한 상태였습니다. 이것을 이용하던 협력사들이 UbiViewer의 발주서가 조회가 안된다고 하는데, 결론적으로 보니 내부망과 모바일버전의 UbiViewer 경로가 같은 곳을 바라보고 있었습니다. 모바일 버전은.. The Nature of Software Development 저자 :론 제프리스 번역 :이기곤 출간 :2016-12-31 론 제프리스가 누구? 론 제프리스는 애자일 선언문 작성과 익스트림 프로그래밍 창시에 한몫 했던 사람으로 애자일과 소프트웨어 발전에 풍부한 경험과 실력을 가지고 있는 분입니다. 따라서 이 책을 읽기 전부터 신뢰가 갔고, 역시 풍부한 경험을 담아서 간접 경험을 할 수 있었습니다. -Chapter1- 이 책의 핵심은? 작동 하는 소프트웨어로 피처 보여주기 우리 모두 가치를 원합니다. 바꿔 말하면, 가치는 우리가 원하는 것입니다. 소프트웨어에서는 보통 피처를 통해 가치를 얻습니다. 가치를 확인해보고 싶다면 이렇게 말하세요 "작동하는 소프트웨어를 보여주세요" 필요한 피처만 모아 만든 간결한 제품으로 높은 작업 효율을 낼 수 있습니다. 이렇게 만든 제품을.. TIL_2022.09.14 1. Facts(사실, 객관) - 견적서 개선 - 페이징 관련 강의 수강 2. Feelings(느낌, 주관) 이번 견적서는 다양한 부서에서 요청이 온 만큼 개선사항도 많았습니다. 사소한 오탈자부터 글씨체 통일과 추가개발까지 있습니다. 각 부서와 협력하여 어느정도 수준까지 구현하고 언제 완성할지를 정했습니다. 모든 것이 완벽하게 만들어진 상태에서 운영을 시작하는 것이 아닌, 구동 가능한 기능이 만들어진 상황에서 오픈하고, 추가적인 간편화 작업들이 이후에 더해지도록 했습니다. 또한 QueryDsl로 열심히 쿼리문을 작성했었는데, 페이징과 관련해서 좀 더 성능을 잘 내고 싶었습니다. 따라서 강의를 다시 보고 어떻게 하면 좋을지 고민했습니다. 항상 코드의 간편성과 성능의 트레이드 오프에 주의해야 합니다. 코드가.. 함께 자라기 개요 워낙 유명한 김창준 님이 쓰시기도 하셨고, 협업에 관심이 많았던 찰나에 회사에서 구매하여 읽게 되었습니다. 책이 그렇게 두껍지 않고 어려운 내용들이 있던 것은 아니라 읽는데 부담은 없었습니다. 사례 중심의 이야기가 많기도 하지만 여러 조사를 통해 근거를 가지고 설명해주는 부분들이 인상 깊었습니다. 최근에 학습 방법과 교육, 협업에 관심이 많았는데 이미 알고있던 부분도 있었지만 새롭게 알게되고 적용해보면 좋겠다고 생각한 부분들이 있었습니다. 가령 전문가에게는 방법을 묻기보다 실제로 과제나 사례를 제시하며 옆에서 어떻게 생각하는지, 해결하는지, 접근하는지 전 과정을 관찰하는 것이 훨씬 도움이 됩니다. 또한 팀이 서로 투명한 공유와 신뢰가 쌓여 있을 때, 환경 변화에 대처하기 쉬우며 같은 작업을 하더라도.. TIL_2022.09.07 1. Facts(사실, 객관) - 견적서 개선 - gitFlow vs Github Flow 차이 개념 2. Feelings(느낌, 주관) 현업이 수정해달라고 요청한 내용들을 수정했습니다. 사실 대면 미팅이 좋습니다. 같은 시간이라도 좀 더 많은 내용을 정확하고 확실하게 전달 할 수 있습니다. 그럼에도 온라인으로 소통을 열심히 해서 잘 취합된 내용으로 개선을 했습니다. 항상 개발은 끝나면 추가 요구사항이나 개선사항이 있습니다. 이에 대해 유연하게 생각하려고 노력합니다, 3. Findings (배운 점) - git flow와 달리 github flow는 main, feature 브랜치 2개로 운영한다 - 세상에 모든 기술들은 다 trade-off가 있다. 4. Action (구체적 계획) - github f.. 이전 1 ··· 3 4 5 6 7 8 9 ··· 42 다음
