케라스의 아버지 새해 목록, 2019년에 받을 자격이 있습니다

개발 중 주의할 점

• 코드는 단지 실행되기 위해 존재하는 것이 아닙니다. 코드는 또한 팀 전체의 의사소통 수단이며, 다른 사람에게 문제에 대한 해결책을 설명하는 방법입니다. 읽을 수 있는 코드는 아닙니다 있으면 좋은 것이는 코드 작성의 근본적인 부분입니다. 여기에는 코드를 명확하게 인수분해하고, 자체 설명이 가능한 변수 이름을 선택하고, 암묵적인 내용을 설명하는 주석을 삽입하는 것이 포함됩니다. 당신이 작성한 코드는 당신에 의해서만 실행되는 것이 아닙니다. 코드는 또한 팀 간 의사소통의 수단이며, 동료와 사용자에게 문제에 대한 해결책을 설명하는 방법이기도 합니다.읽기 쉬운 코드는 "있으면 좋지만 없어도 괜찮은" 것이 아닙니다.하지만 코드 작성에 있어서 가장 중요한 부분 중 하나입니다. 코드가 읽기 쉽도록 하려면 코드를 명확하게 나누고, 이해하기 쉬운 변수 이름을 선택하고, 주석을 추가하여 암시적인 내용을 설명해야 합니다.
• 다음 프로모션에 풀 리퀘스트가 무엇을 할 수 있을지 묻는 것이 아니라, 풀 리퀘스트가 사용자와 커뮤니티에 무엇을 할 수 있을지 묻는 것입니다. 어떤 경우에도 "눈에 띄는 기여"는 피하세요. 제품의 목적에 도움이 되지 않는 기능은 추가하지 마세요. 풀 리퀘스트가 다음 직장에서 승진하는 데 어떻게 도움이 될지 생각하는 것에 그치지 마세요.사용자와 커뮤니티에 무엇을 제공할 수 있는지 생각해 보세요.. 만약 어떤 기능이 제품이 달성하려는 목적을 달성하는 데 분명히 도움이 되지 않는다면, 추가하지 마세요.
  
• 취향은 코드에도 적용됩니다. 취향은 단순함에 대한 욕구에 의해 정규화된 제약-만족 과정입니다. 단순함을 중시하세요. 간단하게 유지하세요.
• 거절해도 괜찮습니다. 누군가가 기능을 요청했다고 해서 꼭 해야 하는 것은 아니니까요. 모든 기능에는 초기 구현 비용을 넘어서는 비용이 발생합니다. 유지 관리 비용, 문서화 비용, 사용자의 인지 비용 등이 있습니다. 항상 이렇게 물어보세요. 우리가 정말 이걸 해야 할까요? 대개 대답은 단순히 '아니요'입니다. '아니오'라고 말하는 법을 배우세요. 누군가가 기능을 요청했다고 해서 반드시 구현해야 하는 것은 아닙니다. 각 기능을 개발하려면 일정 금액의 비용이 필요합니다. 여기에는 유지 관리 비용, 문서화 비용, 사용자 인지 비용이 포함됩니다. 항상 다음과 같은 질문을 스스로에게 해보세요.정말 이렇게 해야 할까? 대답은 대개 '아니요'입니다.
  
• 새로운 사용 사례를 지원해 달라는 요청에 '예'라고 답할 때, 사용자가 요청한 내용을 그대로 추가하는 것이 종종 최적의 선택이 아니라는 점을 기억하세요. 사용자는 자신만의 특정 사용 사례에 집중하고 있으며, 이에 맞춰 전체 프로젝트에 대한 전체적이고 원칙적인 비전을 제시해야 합니다. 대부분의 경우, 올바른 답은 기존 기능을 확장하는 것입니다. 새로운 사용 사례를 지원하기로 결정했을 때, 사용자가 분명히 충족하기를 원하는 요구 사항을 추가하는 것은 일반적으로 최선의 방법이 아니라는 점을 알아두세요. 사용자는 자신만의 특정 사용 시나리오에 집중하고, 개발자는 제품의 전반적인 비전이라는 관점에서 전체 프로젝트를 살펴봐야 합니다.일반적으로 올바른 접근 방식은 기존 기능을 확장하는 것입니다.
• 지속적인 통합에 투자하고 전체 단위 테스트 범위를 목표로 하세요. 자신감을 가지고 코딩할 수 있는 환경에 있는지 확인하세요. 그렇지 않은 경우, 올바른 인프라를 구축하는 데 집중하세요.완전한 단위 테스트 범위를 달성한다는 목표로 지속적인 통합에 투자하세요.자신있게 코드를 작성할 수 있는 환경에 있는지 확인하세요. 그렇지 않다면 먼저 올바른 인프라를 구축해야 합니다.

• 모든 것을 미리 계획하지 않아도 괜찮습니다. 여러가지 일을 시도해 보고 결과가 어떻게 되는지 살펴보세요. 잘못된 선택은 일찍 되돌리세요. 그것이 가능한 환경을 조성하세요. 모든 것을 미리 계획할 필요는 없습니다.먼저 테스트해서 어떻게 작동하는지 확인하세요.이렇게 하면 일찍 잘못된 선택을 하는 것을 방지하는 데 도움이 됩니다. 물론, 먼저 사용하기 쉽고 안정적이며 포괄적인 개발 환경을 구축했는지 확인해야 합니다.

• 좋은 소프트웨어는 어려운 일을 쉽게 만들어줍니다. 문제가 처음에 어려워 보인다고 해서 해결책이 복잡하거나 사용하기 어려워야 하는 것은 아닙니다. 엔지니어들은 종종 원치 않는 복잡성을 도입하는 반사적 솔루션(ML을 사용해 보자! 앱을 만들어 보자! 블록체인을 추가하자!)을 선택하는데, 이는 훨씬 쉽지만 덜 명확한 대안이 있는 상황에서 그렇습니다. 코드를 작성하기 전에 선택한 솔루션이 더 이상 간단해질 수 없는지 확인하세요. 모든 것을 기본 원칙으로부터 접근하세요. 좋은 소프트웨어는 어려운 일을 쉽게 만들어줍니다. 문제가 처음 보기에 어려워 보인다고 해서 그 해결책이 복잡하거나 사용하기 어려울 필요는 없습니다. 많은 경우 엔지니어들은 매우 복잡한 솔루션을 제시하는 경향이 있지만, 실제로는 더 간단하고 쉬운 솔루션이 있으며, 이 간단한 솔루션은 그다지 명확하지 않을 수 있습니다.코드를 작성하기 전에, 선택한 솔루션이 가장 간단한지 확인하세요.
• 암묵적인 규칙은 피하세요. 스스로 개발하게 된 암묵적 규칙은 항상 명확하게 만들어야 하며 다른 사람들과 공유하거나 자동화해야 합니다. 반복적이고 준알고리즘적 업무 흐름을 생각해 낼 때마다 그것을 문서화된 프로세스로 공식화하여 다른 팀원들이 그 경험으로부터 이익을 얻도록 해야 합니다. 또한, 자동화할 수 있는 워크플로의 모든 부분(예: 정확성 검사)을 소프트웨어에서 자동화하도록 해야 합니다. 암묵적인 규칙은 피하세요. 당신이 형성한 모든 암묵적 규칙을 명시적으로 만들고 다른 사람들과 공유하거나,자동으로 만들어주세요. 반복적이고 준알고리즘적 업무 흐름을 생각해내는 경우, 다른 팀원들도 그로부터 이익을 얻을 수 있도록 프로세스를 표준화하고 문서화할 방법을 찾아야 합니다. 또한 자동화가 가능한 워크플로의 경우 소프트웨어에서 최대한 많은 워크플로를 자동화해야 합니다.
• 디자인 과정에서는 수익이나 성장 등 집중하고자 하는 부분만이 아니라 선택 사항의 전반적인 영향을 고려해야 합니다. 모니터링하는 지표를 넘어, 귀하의 소프트웨어가 사용자와 세상에 미치는 전체적인 영향은 무엇입니까? 가치 제안보다 더 큰 바람직하지 않은 부작용이 있습니까? 소프트웨어의 유용성을 유지하면서 이러한 문제를 해결하기 위해 무엇을 할 수 있을까요? 설계 과정에서는 수익이나 성장뿐 아니라 선택한 옵션의 전반적인 영향을 고려하세요. 이미 모니터링한 지표 외에도 소프트웨어가 사용자와 더 나아가 세상에 미치는 다른 영향은 무엇입니까? 바람직하지 않은 부작용은 있나요? 소프트웨어 가용성을 보장하면서 이러한 문제를 해결하기 위해 무엇을 할 수 있을까요?

더 나은 API를 작성하는 방법은?

• 귀하의 API에는 사용자가 있으므로 사용자 경험이 제공됩니다. 모든 결정을 내릴 때 항상 사용자를 염두에 두십시오. 초보자든 숙련된 개발자든 사용자 모두에게 공감하세요. API에는 사용자가 있으므로 사용자 경험도 포함됩니다.모든 결정을 내릴 때 사용자를 고려하세요. 사용자가 초보자이든, 경험이 많은 개발자이든, 사용자 관점에서 생각해 보세요.
• API를 사용하는 동안 사용자에게 가해지는 인지 부하를 최소화하도록 항상 노력하세요. 자동화할 수 있는 것은 자동화하고, 사용자에게 필요한 작업과 선택을 최소화하고, 중요하지 않은 옵션은 노출하지 말고, 간단하고 일관된 정신 모델을 반영하는 간단하고 일관된 워크플로를 설계하세요. 제품 API를 사용할 때 사용자의 인지 부하를 줄이도록 노력하세요. 자동화할 수 있는 모든 단계를 자동화하세요.사용자가 해야 하는 작업과 선택의 수를 최소화합니다.중요하지 않은 옵션은 표시하지 말고, 간단하고 일관된 정신 모델을 반영하는 간단하고 일관된 워크플로를 디자인하세요.
• 간단한 일은 간단해야 하고, 복잡한 일도 가능해야 합니다. 틈새 사용 사례를 위해 일반적인 사용 사례의 인지 부하를 최소한으로 늘리지 마세요. 간단한 일은 가능한 한 간단하게 처리해야 하며, 복잡한 일은 가능한 한 단순화해야 합니다.몇 가지 특수한 사용 사례 때문에 일반적인 사용 사례의 인지 부하를 늘리지 마세요.

• 워크플로의 인지 부하가 충분히 낮으면 사용자는 한두 번만 실행해 본 뒤에도 (튜토리얼이나 문서를 찾아보지 않고도) 기억을 더듬어 실행할 수 있어야 합니다. 만약워크플로우의 인지 임계값은 충분히 낮습니다., 그러면 사용자는 1~2회 사용 후 느낌과 기억으로 작업을 완료할 수 있으며,튜토리얼 문서를 찾을 필요가 없습니다..

• 도메인 전문가와 실무자의 정신 모델에 맞는 API를 갖추세요. 도메인 경험은 있지만 API에 대한 경험이 없는 사람이라도 최소한의 문서만 보고 직관적으로 API를 이해할 수 있어야 합니다. 대부분은 몇 가지 코드 예제를 보고 어떤 객체를 사용할 수 있는지, 각 객체의 시그니처는 무엇인지 확인하는 것만으로도 가능합니다.도메인 전문가와 실무자의 정신 모델에 맞는 API를 만들기 위해 노력하세요.도메인 경험은 있지만 API를 사용해 본 적이 없는 사람이라도 최소한의 문서만으로도 직관적으로 API를 이해할 수 있어야 합니다. 예를 들어, 몇 가지 코드 예제를 살펴보고 어떤 객체를 사용할 수 있는지, 어떤 특징이 있는지 확인하는 것만으로도 API를 잘 이해할 수 있습니다.
• 주장의 의미는 기본 구현에 대한 맥락이 없어도 이해할 수 있어야 합니다. 사용자가 지정해야 하는 인수는 코드의 구현 세부 사항이 아닌 문제에 대한 사용자의 정신적 모델과 관련되어야 합니다. API는 소프트웨어가 백그라운드에서 어떻게 작동하는지가 아니라, 해결하는 문제에 관한 것입니다. 매개변수의 의미는 기본 구현에 대한 배경 정보가 없어도 쉽게 이해할 수 있어야 합니다. 사용자가 지정해야 하는 매개변수는 코드의 구현 세부 사항이 아닌 사용자의 문제 모델과 관련되어야 합니다. API의 핵심은 API가 해결하는 문제에 있으며, 이는 소프트웨어의 실제 작업 흐름과는 아무런 관련이 없습니다.
• 가장 강력한 정신 모델은 모듈식이고 계층적입니다. 즉, 높은 수준에서는 간단하지만, 세부 사항을 파고들어야 하므로 정확합니다. 마찬가지로, 좋은 API는 모듈식이고 계층적입니다. 즉, 접근하기 쉽지만 표현력이 풍부합니다. 적은 수의 객체에 복잡한 서명을 갖는 것과, 더 간단한 서명을 가진 더 많은 객체를 갖는 것 사이에는 균형을 맞춰야 합니다. 좋은 API는 비교적 간단한 시그니처와 함께 적당한 수의 객체를 갖습니다. 가장 강력한 모델은 모듈식이고 계층적입니다. 즉, 높은 수준에서는 간단하지만 세부 사항은 정확합니다. 비슷하게,좋은 API는 모듈식이고 계층적이어야 합니다. 즉, 사용하기 쉽고 표현력이 풍부해야 합니다.. 좋은 API는 간단한 기능을 갖춘 적당한 수의 객체를 가지고 있습니다.
• 귀하의 API는 필연적으로 귀하의 구현 선택, 특히 귀하가 선택한 데이터 구조를 반영합니다. 직관적인 API를 구현하려면 해당 도메인에 자연스럽게 맞는 데이터 구조, 즉 도메인 전문가의 정신 모델에 맞는 데이터 구조를 선택해야 합니다. 귀하의 API는 귀하의 구현 선택 사항, 특히 귀하가 선택한 데이터 구조를 반드시 반영해야 합니다. 직관적인 API를 구현하려면해당 도메인에 적합한 데이터 구조를 선택해야 합니다. 즉, 도메인 전문가 모델과 일치하는 데이터 구조를 선택해야 합니다.

• 원자적 기능의 집합이 아닌, 종단 간 워크플로를 의도적으로 설계하세요. 대부분의 개발자는 API 설계에 다음과 같은 질문을 던지며 접근합니다. 어떤 기능을 사용할 수 있어야 할까요? 이에 대한 구성 옵션을 제공해 보겠습니다. 대신 이렇게 질문해 보세요. 이 도구의 사용 사례는 무엇인가요? 각 사용 사례에서 사용자 작업의 최적 순서는 무엇입니까? 이 워크플로를 지원할 수 있는 가장 쉬운 API는 무엇입니까? API의 원자 옵션은 고수준 워크플로에서 발생하는 명확한 요구 사항에 답해야 합니다. "누군가에게 필요할지도 모른다는 이유로" 추가해서는 안 됩니다.일련의 원자적 기능이 아닌 엔드투엔드 워크플로를 의도적으로 설계합니다.API를 설계할 때 대부분의 개발자는 다음과 같은 질문을 합니다. 어떤 기능을 제공해야 할까요? 해당 기능에 대한 구성 옵션을 제공해 보겠습니다. 사실, 개발자에게 가장 중요한 질문은 "이 도구의 사용 시나리오는 무엇인가?"입니다. 각 사용 사례에서 사용자에게 가장 적합한 작업 순서는 무엇입니까? 이 워크플로를 지원할 수 있는 가장 간단한 API는 무엇입니까?
• 오류 메시지와 일반적으로 API와 상호 작용하는 과정에서 사용자에게 제공되는 모든 피드백은 API의 일부입니다. 상호작용과 피드백은 사용자 경험에 필수적입니다. API 오류 메시지를 의도적으로 설계하세요.API와 상호작용하는 동안 오류 보고 및 사용자에게 제공되는 모든 피드백은 API의 일부입니다.상호작용과 피드백은 사용자 경험의 필수적인 부분입니다. API 오류 메시지는 신중하게 설계해야 합니다.
• 코드는 의사소통이므로 프로젝트나 변수의 이름을 지정하는 것이 중요합니다. 이름은 문제에 대한 당신의 생각을 반영합니다. 지나치게 일반적인 이름(x, 변수, 매개변수)을 피하고, 지나치게 길고 구체적인 이름 패턴, 불필요한 마찰을 일으킬 수 있는 용어(마스터, 슬레이브)를 피하고, 이름 선택에 일관성을 유지하세요. 명명 일관성은 내부 명명 일관성(다른 곳에서 "axis"라고 불리는 것을 "dim"이라고 부르지 마세요)과 문제 도메인에 대한 기존 규칙과의 일관성을 모두 의미합니다. 이름을 정하기 전에 도메인 전문가(또는 다른 API)가 사용하는 기존 이름을 찾아보세요. 코드는 의사소통이므로 프로젝트 이름이나 변수 이름 등 명명이 중요합니다. 이름은 문제에 대한 생각 방식을 반영합니다.지나치게 일반적인 이름을 사용하지 말고, 지나치게 긴 명명 패턴을 사용하지 말고, 불필요한 오해를 불러일으킬 수 있는 용어를 사용하지 말고, 명명 선택에 일관성을 유지하세요.명명 일관성은 내부 명명 일관성과 문제 분야의 확립된 규범과의 일관성을 모두 의미합니다. 이름을 정하기 전에 해당 분야 전문가가 이미 사용하고 있는 이름을 찾아보세요.
• 문서화는 API 사용자 경험의 핵심입니다. 이것은 추가 기능이 아닙니다. 고품질 문서에 투자하세요. 더 많은 기능에 투자하는 것보다 더 높은 수익을 얻을 수 있습니다. 문서화는 API 사용자 경험의 핵심입니다. 이것은 추가 기능이 아닙니다.고품질 문서를 작성하는 데 에너지를 투자하세요.이렇게 하면 더 많은 기능을 개발하는 것보다 더 높은 수익을 얻을 수 있습니다.

• 말로 표현하지 말고 직접 보여주세요. 설명서에서는 소프트웨어의 작동 방식에 대해 설명하지 말고, 사용 방법을 보여줘야 합니다. 종단간 워크플로에 대한 코드 예를 보여줍니다. API의 모든 일반적인 사용 사례와 주요 기능에 대한 코드 예를 보여줍니다. 사용자에게 설명하는 대신 보여주세요. 설명서에는 소프트웨어의 작동 방식을 설명하는 대신 사용자에게 사용 방법을 보여주어야 합니다.종단 간 워크플로를 보여주는 코드 예제API의 일반적인 사용 사례와 주요 기능에 대한 코드 예를 보여주세요.
  

  케라스 시험이 있다면, 나는 치트시트를 준비했습니다.

슈퍼 뉴로피디아

단어

단변량

 [ju:nɪ'veərɪrt] 형용사. 단변량

다변량

 [mʌltɪ'veərɪɪt] 형용사. 다변량

구절

로지스틱 회귀  로지스틱 회귀

서비스 구현  서비스 구현