Skip to content

Vol.360

Kota Furusawa

Best practices for writing code comments Jump to heading

コードコメントを書くためのベストプラクティス Jump to heading

コードコメントを書かないことが美しいと考えることもできるが、まったくコメントを書かないという極端なケースが適切なケースは少ないだろう。この記事では、コードコメントを書く際のベストプラクティスを紹介する。

  • ルール1：コメントはコードを複製してはならない
  • ルール2：不明瞭なコードをコメントで解説しない
  • ルール3：明確なコメントを書くことができない場合は、コードに問題があると考える
  • ルール4：コメントで混乱を引き起こさないようにする
  • ルール5：コメントを用いて、単純で省略したくなるようなコードを解説する
  • ルール6：コピーされたコードの元のソースへのリンクを記す
  • ルール7：外部参照へのリンクを記述する
  • ルール8：バグを修正するときにコメントを追加する
  • ルール9：コメントを使用してTODOを記す

Evolving Software: SOLID principles as a continuum Jump to heading

連続体としてSOLIDの原則を適用させる Jump to heading

SOLIDの原則の5つのルールはそれぞれが独立したルールではなく、それぞれが関連したものとして考えることで理解が深まる。この記事では、擬似コードを用いてSOLIDの原則をどのように関連したものとして考えることができるのかについて解説し、この原則の理解を手助けしてくれる。

Design Systems Aren’t Cheap Jump to heading

デザインシステムの価値 Jump to heading

デザインシステムの価値はどれほどあるのか。例えば、Reactを使ったコンポーネントを揃えた場合、このReactフレームワークを変更する日が訪れたとき、大きなコストを払うことになってしまうだろう。プラットフォームはフレームワークよりも寿命が長いことを鑑みると、デザインシステムを利用してアクセシブルで十分にテストされた、有用なコンポーネントを揃えることが、どれだけそういったコストの排除に繋がるのかは自明である。

Design is about facilitation not creation Jump to heading

デザインとは創造をするものではなく、相互作用を促進させること、そして現実へのアウトプットを手助けすることである。 デザイナがすべきことは、アウトカムを現実にするために、意思決定やを促進することであり、アーティファクトの作成は副産物に過ぎない。

The euclidean design model Jump to heading

Atomicデザインに対して、ユークリッド空間の考えを適用して拡張をするアイディアを紹介している。

In Brief Jump to heading