TIL 2일차 (문자열 나누기 - Kotlin | 앱 개발 용어 정리 | 프로젝트 관련 피드백 정리)

코드카타

 

문자열 나누기

 

문제

 

 

입출력 예시

 

 

정답

class Solution {
    fun solution(s: String): Int {
        var rs = s // 남은 문자열
        var res = 0 // 분배한 문자열의 개수
        
        // 남은 문자열이 공백이 될 때까지 문자열 분배 과정 반복
        while (rs.isNotEmpty()) {
        
            // 변수 초기화 구문
            
            var x = rs[0] // 첫 글자
            var xCnt = 0 // x와 같은 글자가 나온 횟수
            var nCnt = 0 // x와 다른 글자가 나온 횟수
            val arr = mutableListOf<Char>() // 분배한 문자열을 담을 배열
            
            // 남은 문자열 순회하면서 배열에 조건에 따라 분배한 문자열 추가
            for (i in rs) {
                if(i == x) xCnt++ else nCnt++ // i값에 따라 각 cnt에서 1을 증가시킴
                
                arr.add(i) // i를 arr에 추가
				
                // 두 횟수가 같아지는 순간 카운트 후 반복문 종료
                if (xCnt == nCnt) {
                    res += 1
                    break
                }
            }
            
            // 문자열을 순회하는 반복문이 종료되면 아래 구문이 실행된다.
            
            rs = rs.substring(arr.size) // rs에서 분배한 문자열 빼기
            if (xCnt != nCnt) res += 1 // 두 횟수가 다른 상태에서 더 이상 읽을 글자가 없을 때
        }
        return res // 분배한 문자열 개수 반환
    }
}

주어진 문자열을 규칙에 따라 분해하고, 분해한 부분 문자열의 개수를 반환한다.

 

 

---

 

앱개발 용어 정리 2

 

버그(Bug)

 

"버그"란 소프트웨어가 의도한 대로 작동하지 않거나

비정상적으로 동작하는 문제 또는 결함을 뜻한다.

 

요구된 기능을 올바르게 수행하지 못하는 경우는 기능적 버그,

애플리케이션이 느리게 동작하거나 리소스를 과도하게 사용하는 경우는 성능 버그,

특정 장치나 운영체제 버전에서 제대로 작동하지 않는 경우는 호환성 버그에 해당한다.

 

그 외에도 사용자 인터페이스 버그, 로직 버그, 보안 버그 등이 존재한다.

 

 

에러(Error)

 

"에러"란 소프트웨어 실행 중에 발생하는 예기치 않은 상황으로,

애플리케이션이 정상적으로 동작하지 않도록 만드는 문제를 뜻한다.

 

작성한 코드의 문법이 잘못됬거나 자료형이 불일치 할 땐 컴파일 에러,어

플 실행 중에 논리적 오류나 외부 환경 문제가 발생하면 런타임 에러,

하드웨어나 운영체제에 문제가 있을 땐 시스템 에러가 발생한다.

 

논리적 오류는 null 참조나, 배열 인덱스 초과 등의 경우에 해당한다.

 

 

예외처리

 

예외 처리는 런타임 에러를 잡아내고, 이를 적절히 처리하여

애플리케이션의 비정상 종료를 방지하는 방법이다.

 

 

라이브러리(Library)

 

라이브러리는 특정 기능이나 작업을 수행하기 위해 재사용 가능한 코드의 모음이다.

라이브러리를 사용하면 개발 시간을 절약하고 생산성이 향상 시킬 수 있다.

 

라이브러리는 다양한 형태로 존재하며, UI 컴포넌트, 데이터 처리, 네트워킹,

데이터베이스 연결 등 다양한 기능을 제공한다.

 

 

프레임워크(Framework)

 

프레임워크는 소프트웨어 개발에서 특정 애플리케이션이나 솔루션을 개발하기 위한

기본 구조와 표준 방법을 제공하는 플랫폼이다.

 

프레임워크는 일반적으로 특정 프로그래밍 언어로 작성된 라이브러리,

도구, 규칙 및 지침의 집합으로 구성된다.

 

 

퍼블리싱

 

퍼블리싱은 콘텐츠를 제작하고 배포하는 과정을 뜻한다.

 

퍼블리싱 과정은 주로 개발 완료 후에 이루어지며,

테스트, 배포, 유지보수의 과정을 포함한다.

 

 

UI(User Interface)

 

사용자가 소프트웨어 애플리케이션과 상호작용할 수 있도록 하는

시각적이고 기능적인 요소들의 집합을 의미한다.

 

UI는 시스템과의 상호작용 방식을 정의한다.

 

 

UX(User Experience)

 

UX는 사용자가 제품이나 서비스를 사용하는 동안

느끼는 총체적인 경험을 의미한다.

 

UX는 사용자가 느끼는 만족도, 편리함, 효율성, 감정 등을 포함한다.

 

 

클라이언트

 

클라이언트는 서버로부터 서비스를 요청하고 응답을 받는

소프트웨어 또는 하드웨어 시스템을 의미한다.

 

클라이언트는 주로 사용자의 인터페이스를 제공하고,

서버는 데이터를 저장하고 처리하는 역할을 담당한다.

 

 

API

 

API(Application Programming Interface)는 소프트웨어 애플리케이션 간의

상호작용이 가능하도록 정의된 인터페이스를 의미한다.

 

API는 여러 가지 형태로 제공될 수 있으며,

일반적으로 함수, 메서드, 클래스, 모듈 등의 형태로 제공된다.

 

예를 들어, 페이스북 API를 사용하면 외부 애플리케이션이나

웹사이트가 페이스북 서비스의 기능을 사용할 수 있게 된다.

 

쉽게 말하면 API 호출하면 기능을 가져다 쓸 수 있는 것이다. 

 

 

 

와이어프레임 작성

 

와이어프레임이란?

 

웹사이트나 애플리케이션의 페이지 구조를 시각적으로 표현한 것이다.

 

와이어프레임은 사용자 인터페이스의 기본 레이아웃을 정의하며,

콘텐츠 배치, 라우팅, 주요 요소의 위치 등을 간단하게 시각화하면 된다.

 

 

시각화할 요소들

 

위 이미지는 팀 소개 앱의 UI에 해당한다.

 

메인화면에서 이름을 누르면 해당하는 팀원의 소개페이지로 라우팅하고,

소개페이지의 앱바에서 홈버튼을 누르면 다시 메인화면으로 라우팅한다.

 

 

플러터플로우를 이용한 와이어프레임 생성 

 

플러터플로우에서 프로젝트의 스토리보드를 확인할 수 있다.

 

페이지를 만들고 라우팅 기능만 넣으면 이런식으로 페이지 이동경로를 보여주는데

메인화면을 기준으로 모든 페이지의 라우팅이 이루어지기때문에 상당히 난잡하다.

 

 

가독성 있는 와이어프레임 구현

 

그래서 이와 같이 간략한 설명을 추가하여 와이어프레임을 구성하였다. 

 

 

 

피드백 정리

 

피드백 받은 것들

튜터님이 S.A(Starting Assignments)와 와이어프레임을 보고 피드백을 해주셨다. 

 

 

Merge 시간

코드를 최적화하고 작성한 코드를 검토한 뒤 최종적으로 Merge를 하면 좋을 거 같아 

Git Merge하는 시간을 오후 8~9시로 정했는데 이에 대해서 

merge를 되도록이면 자주하라고 피드백을 주셨다.

 

 

메인화면 UI 문제

 

해당 메인화면 UI에서 이름을 누르면 페이지 라우팅이 된다는 사실을 

사용자가 알기 어려울 것 같기에 이를 고려해서 디자인을 하라는 피드백을 받았다.

 

 

코드 효율성

 

코드의 효율성을 고려하여 팀원 소개페이지의 양식을 통일해

하나의 페이지만 만든 뒤 값만 바꾸면 서로 다른 페이지를 출력하는 방식으로

구현하면 좋을 거 같다 라는 피드백을 받았다.  

 

 

피드백 반영

 

Merge 방식 변경

 

 

피드백을 듣고 Merge를 왜 자주하면 좋은 지 찾아보았다.

 

1. 코드를 자주 병합하게 된다면 코드 변경사항이 작기 때문에

충돌이 발생하더라도 해결하기가 상대적으로 쉬워진다.

 

2. 지속적인 병합으로 인해 코드가 항상 최신 상태로 유지가 되며

테스트를 더 자주 실행하고 코드를 리뷰를 자주 하게 되면서,

문제를 초기에 발견하고 해결할 수 있게 된다.

 

3. 작은 변경 사항을 자주 병합하게 되면 변경 사항의 추적이 더 쉬워지고,

코드 검토하기가 더 쉬워짐에 따라 코드의 품질을 높일 수 있다.

 

 

한마디로 정리하자면 지속적인 Merge는

협업 효율성을 높이며, 충돌을 최소화하는 데 도움이 된다.

 

 

 

Merge 자주해야 효율적으로 프로젝트를 진행할 수 있을 거 같아서 

팀 내 Merge 방식을 특정 시간대에 Merge를 진행하는 거에서

변경사항이 있다면 Merge를 진행하는 것으로 변경하였다.

 

 

메인화면 UI 변경

 

이름을 눌러야 할 것 같게끔 디자인을 해야했기에 위와 같이 3개의 디자인을 하였고

팀 내에서 투표를 진행하여 1번 페이지를 메인화면으로 정하였다.

 

 

코드 효율성에 대한 고려

 

자기 소개 페이지는 자기가 디자인을 하는 방식으로 진행했다.

 

아무래도 각자 원하는 디자인이 있을 것 같아서 따로

자기소개 페이지템플릿을 설정하진 않았다.

 

 

이런식으로 템플릿을 만들어서 하나의 액티비티만 만들어도 

프로젝트의 구현이 가능하도록 하는 것도 좋았을 것 같다.