API 設計ガイド | Cloud API Design Guide | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
システムに不可欠なセキュリティ対策、漏れを食い止める設計書3点セット
「セキュリティ対策はシステム開発で不可欠だが、設計書でうまく表現できている開発現場はまだ少ない」――。 ラックの永井英徳氏（エンタープライズ・セキュリティサービス事業部セキュリティディレクションサービス部長 兼 第一グループ部長）はこう指摘する。よく見られるのが、「クロスサイトスクリプティングの脅威には、Aフレームワークを利用することで対処する」などと、個別の脅威ごとに対策を記述するケースという。しかしこれでは、「システム全体として必要なセキュリティ対策を網羅できているのか判断しにくい」（永井氏）。 とはいえ、機能に関する設計書に、想定しうるあらゆる脅威の内容と対策を書き込むのも問題だ。記述が膨大になり、読みにくい設計書になってしまう。後工程の開発メンバーの作業ミスを招く恐れがある。セキュリティ要件が変わったときの修正作業の負荷も大きい。 このような問題意識のもと、ラックの永井氏は、セキュ
今日から使える文章校正テクニック | DevelopersIO
渡辺です。 昨日のエントリーが結構反響大きめだったので、第二弾です。 文章校正をしていてよくあるパターンを幾つか抽出してみました。 ただし、前回紹介しているパターンは除外していますので、あわせて確認ください。 重複を減らす 文章校正の基礎は 重複を減らす ことです。 次の文章を見てみましょう。 AWSを使い慣れている人にとっては簡単な作業ですが、使い慣れていないと戸惑う所も多いところです。 この文章がくどく感じる理由は、「使い慣れている」が重複していることです。 前後関係もありますが「ところ」がなにを指しているのかも曖昧ですね。 後半の「使い慣れている」を削除し、バランスを取るために作業を後ろに移動しました。 さらに、前の文章を受けるため、「これは」を追加します。 これは、AWSを使い慣れている人にとっては簡単ですが、そうでないと戸惑う作業です。 スッキリしました。 しかし、「慣れていると
Javadoc ドキュメンテーションコメントの書き方 - Qiita
出展: プログラム内のコメントの書き方 | 天才まくまくノート はじめに（モチベーション） こんな話があります。あるソフトウェア企業が一人の技術者の採用を決めました。その決め手となった理由は、「公開しているオープンソースソフトウェアのドキュメントが素晴らしかったから」です。彼らは、作成されたドキュメントを見ただけで、その人には技術力がある、一緒に働いて欲しいと判断したのです。 ある国の言語を学ぶために読み書きの練習が必要であるのと同様に、コーディング技術をつけるには、多くの良質なコードを読み、多くのコードを書くことが必要です。設計ドキュメントを書くのも同じことです。日頃から分かりやすいドキュメントを書く鍛錬を怠らず、長年の経験を積んでいかなければ、良質なドキュメントを書く力は身に付きません。今日からドキュメンテーションコメントをバリバリ書いて、ドキュメンテーション力を付けていきましょう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
