noob log.

組み込みSE兼プログラマの備忘録。

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

まとめ記事続きです。

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

 

19.誰にとっての「利便性」か
優れたAPIを設計するのは難しく、原則を意識していたとしても適切なAPIができるとは限らない。
設計時、本当に使う側にとって「便利」かどうかを考えなければならない。
整合性とボキャブラリーを兼ね備えたAPIを作成できるのが理想。
複数処理を1つのメソッドにまとめられたら便利だと思っていても、それはしないほうが賢明である。

22.1万時間の訓練
「エキスパート」と呼ばれるようになるには、1万時間の、入念に計画された、集中的な訓練を実施する必要がある。
集中的訓練では、自分の現在の能力を少し超える課題を挑戦→分析→修正の繰り返しで反復訓練すべき。
得意なことに取り組むのではなく、まだ得意でないことに取り組む。楽しいとは限らない。

24.変更を恐れない
システムの構造自体に問題があるようなプロジェクトは、いわば「病気にかかっている」状態。
変更・改良を怖がっていてはプロジェクトの容態は悪くなるばかり。
時間や労力はかかるが、投資は何倍もの利益として返って来るばかりではなく、
プロジェクトのメンバーが「システムは本来どうあるべきか」について学び、改良できる知識を身につけられる。
システムの改良では、内部I/Fの再定義、モジュールの再構築、コピペしたコードのリファクタリングなどをするとよい。
改良はゆっくり少しづつ加えていき、改良の都度テストをする。
こうして、システムの「健康」への留意は常に怠らないようにすること。

26.言語だけでなく文化も学ぶ
プログラミング言語には、文法、構文だけではなく、文化がある。
どのような言語でも、一定の書き方に統一できるが、真に言語を理解するには文化も理解する必要がある。
言語の文化を理解することにより、他の言語に応用でき、コードの質が上がる。
新たな言語を学べば、従来から使っていた言語でも、より美しいコードが書けるようになることが多い。

35.超人の神話
いくら超人でも、人間は人間である。
経験から来る勘や知識があっても、現状の状況などが分からなければ答えられない。
人に質問する際には、(相手がどんなに優れた人であっても)何が障害になって物事が進まないのか、
具体的に示すこと。

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

まとめ記事続きです。

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

 

14.コードレビュー
コードレビューの目的はコードの誤りを修正することだけではなく、チームに同じ知識を共有させること。
自分の書いたコードを他のプログラマと共有することで、「コードの共有所有」が可能になる。
コードレビューは辛辣で辛く、硬い場にするより、砕けた雰囲気で、主な目的を「メンバー内で知識を共有すること」に
すると成功させやすい。

15.コードの論理的検証
コードの正しさを検証するには、コードを短いセクションに分割し、チーム内で話し合うことが有効。
また、下記のコーディングプラクティスを守ることで検証が楽になる。
・セクション内での機能を1つのタスクに絞りこむ。
・goto文の使用を避ける。離れたところにあるセクションに強い依存関係が生まれてしまう。
・変更可能なグローバル変数は作らない。使用するすべてのセクションが相互依存関係になるため。
・変数のスコープは可能な限り小さくする。
・オブジェクトは可能な限り不変オブジェクトにする。
・オブジェクトや関数などには、特性や機能がすぐ分かる、短い名前を付ける。
・セクションを入れ子にする場合には、関数化する。
・関数はできる限り短くし、機能を1つに絞り込む。「24行制限」は現代でも有効である。
・関数のパラメータは最高でも4つまでにする。関数で扱うデータを減らすだけでなく、凝集性、整合性の検証が容易になる。
・インターフェースはできるだけ狭くすべし。getter、setterは推奨できない。
 カプセル化を強力にすることで、検証の手間を減らすことにつながる。

16.コメントについてのコメント
「コードは、次に見る人がすぐに理解できるように書く」ことが大切。
コードには、「このコードはどういう目的で書かれたものか」を説明するコメントを入れる必要がある。
コメントは多ければいいというものではなく、必要にして十分な量のコメントを入れること。
ヘッダコメントには「コード本体を全く読まなくても利用はできる」くらいの情報を盛り込み、
インラインコメントには「修正や拡張をする人の助けとなるような情報」を適宜盛り込む。

17.コードに書けないことのみをコメントにする
コメントを入れても、不適切なものであれば意味は無い。
コードに書かれていることをオウム返しにするだけのコードはノイズとなり、プログラマの思考の邪魔をする。
Ver.を知らせるコメントや、変更履歴を知らせるコメントは、バージョン管理システムを導入すれば不要になる。
メソッドやクラス名が分かりにくいなら名前を変える、関数が長いなら細かく分割してそれぞれ名前を付けるなどの
工夫でコメントは不要になる。
コードに「書いていない事」ではなく、コードに「書けない事」のみをコメントにすべき。

18.学び続ける姿勢
今の時代、生き残るためには学び続けなければならない。
・書籍や雑誌、ブログ、Twitterを読んで参考にする。
・本当に身に着けたい技術はコードを書き、手を動かして学ぶ。
・常に自分よりレベルの高い人と仕事をする。レベルの高い人から学ぶことは多い。
・「良き師」になりえる人をネット上で探す。
・自分の利用しているフレームワークやライブラリに対する知識を深める。オープンソースなら
デバッガを使い中身を理解するとよい。
・ミスやバグ修正は解決するだけではなく、深く理解するように努める。
・自分が学びたいことを人に教えたり、話したりする。
・カンファレンスに参加する。
・自分のコードに対して静的分析ツールを実行する。レポートや警告の理由を追及する。
・「達人プログラマ」の教えを実行し、毎年1つ新しい言語を学ぶ。技術、ツールでもよい。
学ぶのはコンピュータ関連技術でなくても、システムが使用される分野や生産性を高める方法でも構わない。
技術はすごい速さで変化していきます。学ばなければ置いていかれるのは確実です。

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

まとめ記事続きです。

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

 

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

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

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

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

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

created by Randy_Hoo.