개발자 오승언

모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, 행위(behavior)와 구조(structure)가 바로 그것이다.  여기서 이야기하는 이해관계자, 행위, 구조란 무엇일까?책의 문맥을 보고, GPT를 활용하고 뇌피셜을 적어본다. 이해관계자 뒷 내용에 '프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 ...' 이라는 내용이 있는 걸 봐서는 이해관계자라는 표현은 소프트웨어 시스템과 관련된 "모든 사람"이 아니라, 개발자보다 윗 단에서 개발을 지시하는 사람(매니저, CTO, 리더 등)임을 짐작할 수 있다. 행위 사용자가 로그인UI에서 올바른 방식으로 로그인하고, 데이터를 보고, 쓰는 것이다.즉, 행위는 기능 명세를 구현하고 버그를 수정하는 것이다. 구조..

기존 구현된 헤더뷰 기존 구현한 헤더뷰의 모습입니다.스크롤이 위에 있을 때는 큰 헤더뷰를 보이다가, 스크롤을 내리면 헤더뷰를 고정하고 상단바처럼 동작하게 했습니다.  개선 목표1) 헤더뷰 변경 위치 정확하게 구하기사용자의 태그가 있을 때랑 없을 때 헤더뷰의 크기가 다릅니다.이는 정확히 언제 헤더뷰가 고정상태로 변경되어야 하는지에 대한 정보가 가변적이라는 것을 의미합니다.기존의 방식은, 특정 높이(고정값) 만큼 스크롤을 했을 때 헤더뷰의 상태를 바꾸는 방식으로 구현했는데, 이를 새로운 방식을 사용하거나 기존 방식을 수정해서 "가변적인 헤더 상태 변경 위치"를 정확히 잡는 것이 목표입니다. 위에 gif를 보면, 헤더뷰 상태가 변경될 때 셀들과 헤더 사이의 간격이 생기는 문제가 있습니다.상태 변경 높이가 잘못..

동기 진행하고 있는 프로젝트에서, 그리고 이전 프로젝트에서 저는 항상 화면 크기를 고려해서 뷰의 동적인 사이즈를 계산했습니다.근데, 이 방식은 두 가지의 문제가 있었습니다.1) 협업하는 개발자는 이러한 방식을 사용하지 않는다.2) systemLayoutSizeFitting 함수를 사용하는 데에 문제가 있다. 1) 의 경우 사실 지금까지 무시해왔습니다. 각자 화면 별로 역할을 맡아왔기에, 굳이 통일성이 없다는 생각이 있었습니다.하지만 2) 의 경우 무시할 수 없었습니다. 그래서 getRelative 코드를 삭제하는 리팩토링을 진행하려 합니다. 리팩토링 getRelative... 함수는 다음과 같이 생겼습니다. 모든 화면에 대해서 같은 크기를 보여주는 것이 아닌, 화면의 너비와 높이를 고려해 비율에 맞는 뷰..