TheCodestReview #1 - 주간 소프트웨어 엔지니어링 주스

왜 하는 건가요?

1. 지식 공유는 기술 개발에 있어 매우 중요하며, 저희는 이를 중요하게 생각합니다.

2. 엔지니어링 리더가 증거 기반 의사 결정을 내리는 데 필요한 솔루션을 찾도록 돕기 위해 소프트웨어 프로젝트.

3. 우리는 항상 새로운 것을 배우고 스스로를 강화하기 위해 노력하는 자기 교육의 힘을 강력하게 믿습니다. 

4. 온라인에는 더 많은 주목을 받을 만한 훌륭한 기술 콘텐츠가 무수히 많으며, 이에 대한 공로를 인정해드리고자 합니다.

구축 로드맵 이 시리즈를 위해 LinkedIn 설문 조사를 실시하여 다음과 같은 질문을 던졌습니다. CTOs 엔지니어링 관리자에게 이미 충분히 어려운 2020년과 그 이후의 주요 과제에 대해 설명합니다.

그들이 한 말은 다음과 같습니다: 

더 이상 고민하지 마시고, 개발 및 프론트엔드 리드인 CTO의 게스트 기고와 함께 아래 주제를 다루는 더코데스트리뷰 1편에 여러분을 초대합니다:

Software Architectures 확장을 위한 6가지 경험 법칙 작성자: Ian Gorton

"시스템에 병목 현상이 발생했습니다. 어딘가에!" - 애플리케이션의 성능을 개선하기 위해 노력할 때 우리는 시스템의 주요 제한 사항을 잊어버리고, 애플리케이션에서 가장 인기 있는 요소는 아니지만 나머지 요소에 부정적인 영향을 미칠 수 있으며 확장이 여기서 도움이 되지 않을 수도 있습니다.

"모니터링은 확장 가능한 시스템의 기본입니다." - 비즈니스에서 맹목적인 태도는 있을 수 없으며, 사용자나 CEO가 문제를 알리기 전에 미리 문제를 파악하는 것이 좋습니다. 모니터링은 신뢰성의 핵심입니다.

"데이터 계층은 확장하기 가장 어려운 부분입니다." - 데이터베이스는 애플리케이션의 심장이며, 모든 심장과 마찬가지로 정맥 시스템에 영향을 주지 않고 데이터 계층을 잘라내기가 어렵기 때문에 병목 현상이 발생하는 경우가 많습니다. 반면에, 데이터 계층을 오래 사용할수록 시장를 사용하면 처리하는 데이터가 많아질수록 예상 성능을 유지하기가 더 어려워집니다.

언급된 글에서 저자는 고성능 애플리케이션 아키텍처의 몇 가지 구체적인 측면을 강조합니다. 수년에 걸쳐 다음과 같은 솔루션을 사용하는 방법을 배웠습니다. AWS 또는 Azure를 사용하지만 클라우드 는 우리 자신을 보호하지 못합니다. 애플리케이션을 만들 때 우리는 존재하지 않는 문제를 미리 예측하여 해결하는 데 집중하지 않습니다. 따라서 나중에 애플리케이션이 성장할 때 많은 문제에 직면하게 됩니다. 이 기사의 저자는 최적화를 어디에서 찾아야하는지, 가장 큰 문제는 무엇이며 애플리케이션에 어떤 영향을 미치는지에 대한 많은 귀중한 팁을 제공합니다. 업계에서 다년간의 경험을 바탕으로 저는 Ian의 의견에 전적으로 동의합니다. 또한 이 글에서 제공하는 조언은 저희가 유지 관리하는 모든 애플리케이션에 적용된다는 점도 덧붙이고 싶습니다. 이러한 가이드라인을 구현하면 다음과 같은 이점을 얻을 수 있습니다. 프로젝트 의 신뢰성과 예측 가능성 측면에서 비즈니스 성장에 중요한 기능을 제공합니다.

후안 파블로 부리티카의 엔지니어링 제공 메트릭에 대한 입문서

- 일반적으로 사용되는 성능 측정은 엄밀히 말해 기술적이지 않습니다.

- 소프트웨어 제공 속도는 측정할 수 있지만, 원하는 효과를 얻으려면 최적화를 위해 사용된 지표를 올바르게 해석해야 합니다.

- 가장 효과적인 팀 엔지니어링 리더는 개발자의 문제와 동기를 이해하고 그 반대의 경우도 마찬가지여야 건강하고 시너지 효과를 얻을 수 있습니다.

후안 파블로 부리티카가 여전히 틈새 시장으로 보이는 주제를 제기했습니다. IT 프로젝트를 관리하는 사람들은 종종 몇 가지 효율성 측정(예: JIRA의 기본 번다운 차트)을 채택하지만, 여전히 다음과 같은 제공 사항과 밀접한 상관관계가 없습니다. 코드 를 기반으로 소프트웨어 배포 프로세스를 최적화할 수 있습니다. 일반적으로 최적화는 팀 내 작업 분배 및 커뮤니케이션과 관련이 있지만, 저자가 언급하는 '병합 시간'과 같은 엄격한 기술 지표를 추적하는 경우는 드뭅니다. 통합이 가능한 GitHub 웹 후크와 작업 관리 시스템의 시대에는 이러한 유형의 접근 방식을 비교적 쉽게 적용할 수 있습니다. 데이터를 손끝으로 가져와 올바른 방식으로 처리하기만 하면 되기 때문입니다.

저자는 그가 설명하는 통계가 빠르게 반대 방향으로 바뀔 수 있다는 사실을 올바르게 지적합니다. 개발 팀하지만 이는 관리 직원이 프로그래머의 작업 세부 사항을 완전히 이해하지 못하는 경우에만 발생합니다. 따라서 PM이나 PO는 기술적으로 정통하고 시스템에서 개별 작업의 이면에 무엇이 있는지 감지할 수 있어야 합니다.

최신 CTO 팟캐스트 - 댄 콘래드와 함께하는 에피소드 217 - 하나의 아이덴티티에서 CTO

팬데믹 시대에 많은 직원이 다음과 같은 방식으로 전환했습니다. 원격 근무 설정할 때 데이터 보안에 더욱 주의를 기울여야 합니다. Dan이 인용한 좋은 예는 사용자가 모든 곳에서 동일하거나 매우 유사한 비밀번호를 사용하면서 이와 관련된 위험을 인식하지 못하는 상황입니다.

여러 곳에서 동일한 비밀번호를 사용하는 경우 사이트 중 하나에 "보안 문제"가 발생하거나 데이터베이스가 인터넷으로 유출되거나 실수로 모든 문을 여는 하나의 비밀번호를 입력하는 것을 누군가 지켜볼 수 있습니다. 제 생각에는 모든 온라인 서비스는 가입 과정에서 동일한 비밀번호를 입력하는 것과 관련된 위험에 대해 교육해야 한다고 생각합니다.

싱글싱온(SSO) 또는 비밀번호 관리자를 하나의 아이덴티티 또는 LastPass로 사용하는 것은 기본적인 온라인 위생 및 보안 표준을 유지하여 취약성과 디지털 위협으로부터 직원과 업무 공간을 보호하는 데 매우 유용합니다.

직원들에게 신중한 비밀번호 관리에 대해 교육하고 있나요?

끝까지 읽어주셔서 감사드리며 곧 공개될 다음 에피소드를 기대해 주세요!