1.기존에 진행하던 모듈식 개발 방법으로 진행할 경우
모든 코드가 한 곳에서 뒤엉켜 있기 때문에
규모가 커질수록 관리하기가 어려워지고
그렇기 때문에 엑셀에 버전등을 기록하며 관리해야 하게 된다.
패키지 개발로 변경할 경우 아래와 같은 차이점이 있다.
- 팀 개발 및 협업 개선.
- 패키지 간의 종속성을 지정하는 모듈식 개발 프로세스
- 변경 관리에 도움이 되는 버전 관리
- 자동화된 테스트 및 지속적인 통합을 촉진
- 릴리스 주기가 보다 효율적이고 민첩
- 설정 기능의 변경 추적을 통해 버전 제어 시스템(VCS) 동기화 개선
- 프로덕션 조직의 변경 관리에 대한 보다 세분화된 가시성과 명확성
회사에서 진행하는 방식 또한 x.y.z 형태로 버전관리를 하고 있는데
이 또한 패키지 관리의 일종이라고 볼 수 있는 것 같다.
2.VSC에 Salesforce Extentions를 사용할 경우 아래와 같은 확장이 가능하며
- Salesforce CLI와 상호 작용하는 기능
- 패키지 개발을 위한 프로젝트 생성 기능
- 구문 강조 표시 및 코드 완성을 위한 Apex 언어 서버 액세스
- Lightning 구성 요소 번들 지원
- Visualforce 페이지 및 구성 요소 지원
- 대화식 및 재생 디버거 지원
버전관리 또한 쉽게 할 수 있다.
스크래치 조직을 생성해 일시적으로 테스트를 진행해볼 수 있는데
새 프로젝트, 기능 분기, 기능 테스트, 자동 테스트 등
기존 작업에서는 충돌이 발생할 수 있는 위험한 테스트들도 부담없이 실행 가능하다.
3.기존의 폭포수 방식으로 개발을 진행할 경우 처음부터 끝까지 계획을 해서 진행하기 때문에
수정하기가 쉽지 않지만 애자일 방식으로 개발을 진행할 경우
목적에 맞게 신속하게 수정하며 진행할 수 있다.
기존 방식 또한 예측 가능하며 작업 완료까지 분담해 따로 진행해도 무리가 없다는 장점이 있지만
규모가 커질수록 정확한 예측 또는 설계가 어려워진다는 단점이 있다.
애자일은 계속적으로 피드백을 확인하며 올바른 경로를 확인해나가기 때문에
예측하기 어려운 새로운 도전 또는 복잡한 개발등을 진행할 때 유리하며
명확하지 않은 요청에 맞추기 위한 개발을 진행할 때도 적합하다.
4.애자일은 다음과 같은 가치를 가지고 있다.
- 프로세스 및 도구보다 개인 및 상호 작용이 더 중요합니다.
- 포괄적인 문서보다는 작동하는 소프트웨어가 더 중요합니다.
- 계약 협상보다는 고객 협업이 더 중요합니다.
- 계획을 따르기 보다는 변화에 대응하는 것이 더 중요합니다.
또한 아래와 같은 원칙을 가지고 있는데
- 단순성을 유지합니다
- 변화를 수용하여 경쟁력을 유지합니다
- 대면 커뮤니케이션이 최고입니다
- 비즈니스 직원 및 개발자가 프로젝트 내내 협업합니다
이런 가치와 원칙을 통해 더 만족도 높고 경쟁력있는 제품을 생산할 수 있다.
5.세일즈포스 버전의 Lean 원칙은 다음과 같다.
- 사람 존중 - 서로 존중하고 협업하는 방식
- 낭비 제거 - 시간 낭비를 제거하기 위해 준비에 대한 표준 정의 사용
- 신속한 제공 - 경쟁력을 유지하기 위해 빠르게 전환할 수 있도록 짧은 스프린트 작업
- 적시 결정 - 사전 설계를 피하고, 중요한 결정은 책임 있는 마지막 순간까지 미루기
- 전체 최적화 - 크게 생각하고 작게 행동하며, 서로 협업하고, 빠르게 실패하고, 재빠르게 배우는 환경 구축
- 지식 만들기 - 새로운 기술을 습득하여 성장하는 환경 제공
- 품질 구축 - 모두가 품질에 대한 소유권을 가지고 품질을 관리
6.Scrum에는 아래와 같은 다섯 가지 가치가 존재한다.
- Focus
- 함께 작업을 완료하고 다음 작업으로 넘어가기
- 우선순위 설정
- 직원들이 개별 진행 상황이 아닌 결과에 집중하도록 책임 공유
- 명확한 제품 비전 설정
- Courage
- 진행 상황을 투명하게 유지
- 실수와 새로운 학습을 발견한 경우 보고
- Openness
- 어떻게 하고 있는지 말로 표현하고, 문제를 표시 하고, 우려 사항을 직접적으로 표현
- 서로에게 도움을 요청하고 제공함으로써 서로를 지원
- 타이밍, 계획 및 에러에 대해 투명한 공유를 통해 마감 시점에서 문제 발생 차단
- 팀이 틀렸을 때 인정하고 앞으로 개선하려는 의도로 실수를 수정
- Commitment
- 각 팀원은 개인의 성취보다는 팀의 전반적인 성공에 기여
- 지속적 개선을 위해 새로운 정보나 경험적 데이터를 기반으로 새로운 것을 시도
- 작업 항목, 작업 계약, 완료 정의 및 역할을 함께 결정하며 존중하기
- Respect
- 다양한 배경과 경험을 존중
- 모든 사람이 최선의 의도를 가지고 있다고 가정하기
- 더 강력한 제품과 팀을 위해 모든 의견과 관점을 수용
7.스크럼의 역할에는 스크럼 리더, 제품 소유자, 팀, 기능 관리자 등이 있다.
스크림 리더는 넓은 시야로 계획을 세우며 프로세스적인 문제를 개선하고
팀이 협력할 수 있도록 지원하는 역할이며
제품 소유자는 이해 관계자와 팀, 스크럼 리더간의 커뮤니케이션을 촉진하고
작업 및 우선순위를 정의하며 고객이 원하는 기능을 정의하고
팀은 3~9인의 작은 팀으로 개별적인 책임과 권한을 부여해
지속적으로 개선 작업을 진행하며 협업한다.
8.제품 백로그는 필요할 수 있는 모든 작업 목록을 아는 한도 내에 정의하는 것이고
스프린트 백로그는 2주 안에 처리가능한 우선순위 높은 작업들을 포함한다.
9.칸반은 작업 흐름 시각화, 진행 중 작업 제한, 메트릭 포함 등의 특징을 가지고 있다.
이를 통해 조금 더 체계적으로 진행중인 작업량을 통제할 수 있으며
무슨 작업을 하는지 쉽게 파악할 수 있다.
10.Lightning Platform은 데이터베이스와 긴밀하게 통합되어 있으며
사용자 인터페이스, 보안 및 보고와 같은 모든 종류의 기능이 플랫폼에 내장되어 있기 떄문에
앱을 초고속으로 구축할 수 있다.
11.apex는 C#과 유사하며( 분명 전에는 자바와 유사하다고 배웠는데)
Integer, Double, Long, Date, Datetime, String 및 Boolean과 같은 기본 유형의 데이터 유형을 지원한다.
Apex에서는 모든 변수가 기본적으로 null로 초기화되지만 문자열은 항상 기본 값 유형으로 취급되고
.NET 문자열은 변경할 수 없기 때문에 값 유형처럼 작동하더라도 실제로는 참조라는 점을 주의해야 한다.
List라는 배열과 유사한 척 하는 뭔가가 있는데
자바스크립트가 아닌 다른 언어와는 유사한 것 같다.
List, []는 거의 동급으로 사용되며 push는 stack에 사용되기 때문에(여기서는)
list.add(value) 형식으로 값을 넣어준다.
Set는 중복과 순서 없는 요소 모음이다.
Map은 키, 값 쌍의 모음으로 JS의 객체와 조금 유사하다고 볼 수 있는데
찾고 싶은 값의 키를 아는 경우 키를 넣으면 바로 값을 얻을 수 있다.
12.통과 코드
//연락처에서 입력값과 BillingState가 같을 때 id, name을 받아오는 클래스
public class AccountUtils {
Public static Account[] accountsByState(String strValue){
Account[] searchList = [SELECT Id,name FROM Account WHERE BillingState = :strValue];
return searchList ;
}
}
(1).백준 2864번 5와 6의 차이는 max에 들어갈 때 5가 있을 경우 6으로 교체해야하고
mix에 들어갈 때는 6이 있을 경우 5로 교체해야 하는 문제였다.
5를 6으로 교체, 6을 5로 교체하는 함수 두개를 만든 후 합쳐서 max, mix에 보내도 됐을 것 같은데
시간에 쫓기면서 호다닥 하다보니 예전에 봤었 던 padStart를 사용해 자릿수를 맞추고
5,6체크로 min, max 계산을 했는데 지금 보니 코드가 상당히 지저분하다.
브론즈3에서 2로 한단계 올려서 푸는데
생각보다 조건들이들어가서 쉬운 실버 문제들보다 손이 더 가는 것 같기도 하고
브론즈 3이 조금 무지성 문제풀이의 마지노선인 느낌이다.
const [num1, num2] = `16796 58786`.split(' ').map(el => el.padStart(7,'0'))
let max = 0
let min = 0
for(let i = 0 ; i < 7 ; i++){
max *= 10
min *= 10
if(num1[i] === '5' && num2[i] === '5'){
max += 12
}
else if(num1[i] === '5'){
max += (6 + Number(num2[i]))
}
else if(num2[i] === '5'){
max += Number(num1[i]) + 6
}
else{
max += Number(num1[i]) + Number(num2[i])
}
if(num1[i] === '6' && num2[i] === '6'){
min += 10
}
else if(num1[i] === '6'){
min += 5 + Number(num2[i])
}
else if(num2[i] === '6'){
min += Number(num1[i]) + 5
}
else{
min += Number(num1[i]) + Number(num2[i])
}
}
console.log(min, max)'회고' 카테고리의 다른 글
| [수습일지] - 21(주말) (0) | 2023.04.16 |
|---|---|
| [수습일지] - 20(주말) (0) | 2023.04.15 |
| [수습일지] - 18 (0) | 2023.04.13 |
| [수습일지] - 17 (0) | 2023.04.12 |
| [수습일지] - 16 (0) | 2023.04.11 |
