noob log.

Hearthstone, 電子工作, プログラミング, and more...

プログラマが知るべき97のこと まとめ 2

まとめ記事続きです。

個々のエッセイはクリエイティブ・コモンズでライセンスされています。

 

7.共有は慎重に
「再利用」はいいこととされているが、システムにおける役割が大きく違っていればメリットは小さい。
また、再利用したばかりに依存関係が大きくなり、テストのコストが増大する危険性もある。
まずはシステム同士の関係をよく見て、どこを共有すべきかを慎重に考えること。

10.ツールの選択は慎重に
既存のツール(ライブラリ、フレームワーク等)を使用することで、
質が高く、安上がりで、効率がいい開発ができる。
だが、目的とツールの前提条件がかみ合っていないと必要以上にコードが複雑になる。
また、ツールを多様化すると、複雑な設定作業やツールのアップデートによる不具合、
アプリの肥大化などの問題が発生する。
そのため、どうしても必要だと判断したものだけに絞ること。(インフラ関連の低水準プログラミングの手間と問題を防ぐためなど)
また、直接ソケットでつなぐのではなく、ミドルウェアを利用することで変更の手間を抑えられる。

11.ドメインの言葉を使ったコード
暗黙の了解があると余計な時間がかかり、バグや仕様の誤解が発生しやすくなるため、
ユーザ定義型を使うことで概念を名前定義し、システムのモデリングを行うとよい。
こうすることで、コードがどのような概念を表現しているか一目でわかる。
カプセル化も十分なら、特定のルールに対応するコードを1箇所に集中させることもできる。

12.コードは設計である
コードを書くことは機械的な作業ではなく、創造的な仕事であることを肝に銘じなければならない。
高度で複雑な設計をしつつ早く開発をするためには、「自動テスト」が鍵。
システムが膨大でも、言語や設計手法の改善を図れば光が見えてくるはず。
決して忘れてはならないのは、優れた設計には「人間」が必要だということ。
そうなるためには技術の習得のための相当の努力が必要。

13.コードレイアウトの重要性
コードを探したり読んだりする作業はレイアウトによって効率化できる。
定数、パブリックメソッド、プライベートメソッドなどをレイアウトする規則を決めておけば、
違いをすぐに見つけることができる。
各構成要素のフォーマットのルールを決め、自動化し、細かい部分は各自で調整する。
コンパクトにまとめることで、一度に見渡せる範囲を広げ、スクロール量やファイルの切り替えを減らす。
ただし、レイアウトはコードの理解を助けるためだけに行うべきで、それ以上は求めてはいけない。

created by Randy_Hoo.