Keras の新年リストの父、あなたは 2019 年にそれを受け取る資格があります

開発時の注意点

• コードは実行するためだけのものではありません。コードはチーム全体のコミュニケーション手段でもあり、問題の解決策を他の人に説明する手段でもありません。 あったら嬉しいこれはコードを書くということの基本的な部分であり、コードを明確に分解し、わかりやすい変数名を選択し、暗黙的なものを説明するコメントを挿入することが含まれます。 あなたが書いたコードはあなただけが実行するものではありません。コードはチーム間でコミュニケーションを図る手段でもあり、問題の解決策を同僚やユーザーに説明する手段でもあります。リーダブルコードは「あったほうがいい、なくても大丈夫」というものではありません。, しかし、コードを書く上で最も重要な部分の 1 つです。コードを読みやすくするには、コードを明確に分割し、適切な自明の変数名を選択し、暗黙の内容を説明するコメントを追加する必要があります。
• プル リクエストが次のプロモーションに何ができるかを考えるのではなく、プル リクエストがユーザーやコミュニティに何ができるかを考えてください。明らかに役に立たない機能は絶対に追加しないでください。製品の目的。 自分のプル リクエストが次のキャリア プロモーションにどのように役立つかだけを考える必要はありません。ユーザーやコミュニティに何をもたらすことができるかを考えてください。製品が達成しようとしていることを達成するのに機能があまり役に立たない場合は、その機能を追加しないでください。
  
• テイストはコードにも当てはまります。シンプルさへの欲求によって規則化された制約を満たすプロセスです。 シンプルにしてください。
• ノーと言うのは問題ありません。誰かが機能を要求したからといって、それを実行する必要があるという意味ではありません。どの機能にも、メンテナンス コスト、ドキュメント コスト、およびユーザーの認知コストなどのコストがかかります。本当にそうすべきでしょうか? 多くの場合、答えは単純に「ノー」です。 ノーと言う方法を学びましょう。誰かが機能を要求したからといって、それを実行する必要があるという意味ではありません。各機能の開発には、保守コスト、文書化コスト、ユーザー意識向上コストなど、一定のコストが必要です。常に次のような質問を自分自身に問いかけてください。本当にこれをすべきでしょうか？ 答えは通常ノーです。
  
• 新しいユースケースのサポートのリクエストに「はい」と答えるときは、ユーザーが要求したものを文字通り追加することは、多くの場合最適な選択ではないことを覚えておいてください。ユーザーは自分自身の特定のユースケースに焦点を当てており、全体的で原則に基づいたビジョンでこれに対抗する必要があります。多くの場合、正しい答えは既存の機能を拡張することです。 新しいユースケースのサポートに取り組む準備ができたら、ユーザーが表面上満たす必要がある要件を追加することは、通常、最良のアプローチではないことを知っておいてください。ユーザーは自分の特定の使用シナリオに注目するため、プロジェクト全体を見て、製品の全体的なビジョンを考慮する必要があります。通常、正しいアプローチは、既存の機能特徴に基づいて拡張することです。
• 継続的インテグレーションに投資し、単体テストを完全にカバーできるようにしてください。そうでない場合は、適切なインフラストラクチャの構築に集中してください。単体テストを完全にカバーすることを目標として、継続的統合に投資します。自信を持ってコードを作成できる環境にあることを確認してください。そうでない場合は、まず適切なインフラストラクチャを構築する必要があります。

• 事前にすべてを計画しなくても大丈夫です。間違った選択を早い段階で元に戻してください。 事前にすべてを計画する必要はありません。まずテストして、どのように機能するかを確認してください。そうすることで、早い段階で間違った選択をするのを防ぐことができます。もちろん、使いやすく安定した包括的な開発環境をまず作成する必要があります。

• 優れたソフトウェアは難しいことを簡単にします。問題が一見難しそうに見えるからといって、エンジニアは望ましくない複雑さをもたらす反射的なソリューションを採用することがよくあります (ML を使用しましょう、構築しましょう)。アプリです! ブロックチェーンを追加しましょう!) より簡単な代替手段が利用できる場合は、コードを作成する前に、選択したソリューションがこれ以上単純ではないことを確認してください。 優れたソフトウェアは難しいことを簡単にします。問題が一見難しいからといって、対応する解決策が複雑であったり、使用が困難であったりする必要があるというわけではありません。多くの場合、実際にはもっと単純で簡単な解決策があるにもかかわらず、エンジニアは習慣的に非常に複雑な解決策を提示しますが、この単純な解決策はそれほど明白ではない場合があります。コードを記述する前に、選択したソリューションが最も単純なものであることを確認してください。
• 暗黙的なルールを避けてください。自分で開発した暗黙的なルールは、常に明示的に作成して他のユーザーと共有するか、自動化する必要があります。反復的な準アルゴリズムのワークフローを思いついたときは、それを文書化したプロセスに形式化するように努める必要があります。さらに、そのようなワークフローの自動化できる部分 (正確性チェックなど) をソフトウェアで自動化するよう努める必要があります。 暗黙のルールは避けてください。あなたが開発したすべての暗黙のルールを明示的なルールに変えて他の人と共有する、またはそれを自動化する。繰り返し行われる準アルゴリズム的なワークフローを思いついた場合は、他のチームメンバーがその恩恵を受けることができるように、プロセスを標準化して文書化する方法を探す必要があります。さらに、自動化できるワークフローについては、ソフトウェアで可能な限り自動化するように努める必要があります。
• 設計プロセスでは、収益や成長など、監視している指標以外に、ソフトウェアがユーザーに与える全体的な影響だけでなく、選択による全体的な影響も考慮する必要があります。ソフトウェアの有用性を維持しながら、それらに対処するために何ができるでしょうか? 設計プロセスでは、収益や成長だけでなく、選択したオプションの全体的な影響を考慮してください。監視されている指標に加えて、ソフトウェアはユーザーや世界全体にどのような影響を及ぼしますか? 何か悪い副作用はありますか? ソフトウェアの可用性を確保しながらこれらの問題を解決するにはどうすればよいでしょうか?

より良い API を作成するにはどうすればよいでしょうか?

• API にはユーザーが存在するため、あらゆる決定を行う際には、初心者であろうと経験豊富な開発者であろうと、常にユーザーのことを念頭に置いてください。 API にはユーザーが存在するため、ユーザー エクスペリエンスも関係します。あらゆる決定を下す際にはユーザーを考慮してください。ユーザーが初心者であろうと経験豊富な開発者であろうと、ユーザーの視点から問題を考えてください。
• API の使用中にユーザーに課される認知的負荷を最小限に抑えるよう常に努め、自動化できるものは自動化し、ユーザーが必要とするアクションと選択肢を最小限に抑え、重要でないオプションを公開せず、シンプルで一貫したワークフローを設計します。シンプルで一貫したメンタルモデルを反映しています。 製品 API を使用する際のユーザーの認知的負荷を最小限に抑えます。自動化できるステップはすべて自動化し、ユーザーが行う必要のある操作と選択を最小限に抑える、重要でないオプションは表示せず、シンプルで一貫したメンタル モデルを反映したシンプルで一貫したワークフローを設計します。
• シンプルなものはシンプルであるべきであり、複雑なものは可能でなければなりません。ニッチなユースケースのために、たとえ最小限であっても、一般的なユースケースの認知的負荷を増加させてはいけません。 単純なものは単純に扱うべきであり、複雑なものはできるだけ単純にする必要があります。少数の特殊な使用シナリオに対して、一般的な使用シナリオの認知負荷を増加させないでください。

• ワークフローの認知負荷が十分に低い場合、ユーザーは 1 回か 2 回実行した後で (チュートリアルやドキュメントを参照することなく) 記憶を頼りにワークフローを実行することが可能です。 もしワークフローの認知閾値が十分に低い、その後、ユーザーは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 のエラー メッセージは慎重に設計する必要があります。
• コードはコミュニケーションであるため、プロジェクトに名前を付けるか、変数に名前を付けるかにかかわらず、名前には問題についての考え方が反映されます。過度に一般的な名前 (x、変数、パラメーター) を避け、OverlyLongAndSpecificNamingPatterns を避け、不必要な摩擦を引き起こす可能性のある用語 (マスター、変数) を避けます。名前付けの一貫性とは、内部的な名前付けの一貫性 (他の場所で「軸」と呼ばれるものを「dim」と呼ばないでください) と、問題のドメインの確立された規則との一貫性の両方を意味します。名前を決める場合は、ドメインの専門家 (または他の API) が使用している既存の名前を必ず検索してください。 コードはコミュニケーションであるため、項目に名前を付ける場合でも、変数に名前を付ける場合でも、名前付けは重要です。名前は問題についての考え方を反映します。一般的すぎる名前の使用を避け、長すぎる名前付けパターンの使用を避け、不必要な誤解を引き起こす可能性のある用語の使用を避け、名前の選択に一貫性があることを確認してください。名前付けの一貫性とは、内部的な名前付けの一貫性と、問題が対処される領域で確立された規範との一貫性の両方を意味します。名前を決める前に、その分野の専門家によってすでに使用されている名前を必ず探してください。
• ドキュメントは API のユーザー エクスペリエンスの中心です。これはアドオンではありません。より多くの機能に投資するよりも、高品質のドキュメントに投資する方が大きな成果が得られます。 ドキュメントは API ユーザー エクスペリエンスの鍵です。追加パーツではありません。質の高い文書を書くことに力を入れ、これにより、より多くの機能を開発するよりも大きな利益が得られます。

• 説明するのではなく、説明する: ドキュメントでは、ソフトウェアの動作方法について説明するのではなく、エンドツーエンドのワークフローのコード例を示し、すべての一般的なユースケースと主要な機能のコード例を示す必要があります。 API の。 ユーザーに説明することは、直接示すことよりも悪いです。ドキュメントでは、ソフトウェアがどのように機能するかについて説明するのではなく、ソフトウェアの使用方法を直接示す必要があります。エンドツーエンドのワークフローを示すコード例。API の一般的なユースケースと主要な機能ごとにコード例を示します。
  

  Keras で試験がある場合は、チートシートを用意します

スーパーニューロペディア

言葉

単変量

 [ju:nɪ'veərɪrt] 単変量

多変量

 [mʌltɪ'veərɪɪt] 多変数

フレーズ

ロジスティック回帰  ロジスティック回帰

サービスの実装  サービスの実装