新卒API担当エンジニアが【プログラマが知るべき97のこと】で刺さった項目集
はじめに
あけましておめでとうございます！ 上長からお借りしたプログラマが知るべき97のことを読んで 自分がAPI担当として働く中で、いいなぁと思った項目を簡易的にまとめてみました。 新卒一年目として現場に配属されて7カ月目ですが、自分にとってとてもモチベーションが上がったいい本でした。 読んだ人によってで刺さる項目が変わると思いますので、みなさんも是非読んでみてください
(一部解釈が異なる場合があります)
良いと思った項目
リファクタリング関係の話
6 : リファクタリングの際に注意すべきこと
すべてをゼロから書き直したいが、これまでのコードレビューを通ってきたものなので、できる限り既存のコードを活かす
リファクタリングの修正は少しずつを行うべきである。
必ず再テストは行う。
コードを書き換えても元のコードより必ずしも質が良くなるとは限らないということを念頭におくこと
8 : ボーイスカウト・ルール
- モジュールの変更を行ったら、必ず変更前よりコードを美しくする(大きい関数を２つの小さくよりシンプルな関数に分割するなど)
24 : 変更を恐れない
変更後の動作不具合を恐れるような態度を取るべきではない。一時の労力と時間をみるより長期的にリファクタリングして生み出す将来的利益をみるべき
大事なのは積極的にシステムを改良していく姿勢であり、その姿勢はいずれチームにも伝搬して意識高く質のいいシステムをつくることができる。
72 : シンプルさは捨てることによって得られる
既存のコードを無理に残そうとした結果、手間になる場合もあるのでそういう部分は即座に破棄すべき
質の悪いコードは容赦なく書き直す、いっそ全部消してしまう、というくらいの姿勢で取り組むほうが、確実に質の向上につながる(ただし、6を思い出す)
コードはシンプルであるべき
テスト関係の話
12 : コードは設計である
スパイやフェイクなどのテストに関する話。
大事なのは多数の過酷なテストに耐えるものであると証明されない限り、【設計が完了した】とはいえないということ。
34 : API設計の黄金律
規模が大きいと、少量の変更を加えた時の影響力を考えなければならない。
77 : 偶然の仕様ではなく本物の仕様のためのテストを書く
現状の実装コードのやっていることを、あまりに細部にいたるまで厳密にテストしてしまうことがある
偶然でてしまうバグに沿ってテストを行うと、かえって本来動いて欲しい仕様にまで影響を及ぼす可能性がある。
テスト対象のコードの中身ではなく、外から見た動きに注目してテストを書くべきである。
90 : コードを見る人のためにテストを書く
良いテストとは何かを見極めるには「誰のためにテストを書いているのか」を問うべき。そしてそれはコードを見る人のためである。
以下３つの点がわかれば良い
コンテキスト、出発点、満たすべき事前条件がわかる。
ソフトウェアがどのように起動されるかがわかる。
- 期待される結果と、確認すべき事後条件がわかる。
API設計の話
19 : 誰にとっての「利便性」か
呼び出す側の利便性、APIを使う側の利便性を考慮するべきである。
APIを作るということは複雑な処理を隠するということ。
APIは言ってみれば【一つのと言うに対する動詞(メソッド)が必要でそのメソッドは一つに限らない】 例：walkメソッドにrunの機能を追加するより、walk, runと似たような処理を使うほうが使う側にとってはわかりやすく便利なのである。
73 : 単一責任原則
モジュール開発の話
1つのサブシステムやモジュール、クラス、関数などに、変更する理由が2つ以上あるようではいけない
違う理由で変更し得るコードを別の要素に分けること
働き方の話
18 : 学び続ける姿勢
本当に身につけたい技術は、コードを自ら書き、手を動かして学ぶ
常に自分よりレベルの高い人間と仕事する
自分の良き師になりうる人をネットなどでも探しておく、判断基準は書いていることがどれも面白く勉強になるかどうか
今使っているフレームワークなどの知識を深める(vendor中を見るなど)。 理由：最高に頭のいい人たちが書いて、レビューもされているコードを直接見るいい機会だから
勉強会に参加したり、ポッドキャストを利用したりする
毎年一つは新しい言語を学ぶ。必ずしもコンピュータ技術にかかわらなくてもドメインなどでも良い
36 : ハードワークは報われない
長時間オフィスにいてもプロジェクトに多大な貢献をしているとは限らない
神経を集中させる時間、製品を産み出すのに使う時間が週に30時間を超えるようなら「自分は働き過ぎだ」と考えるべき。
ソフトウェア開発はいわばオリエンテーリングしながらマラソンをするようなものであり、自分の現在地と向かっている方向を常に確認し、調整していくことが大事
勉強など、備えるための時間を大事にするべきで、プロの仕事は入念な準備と効率化のための努力、日々の反省振り返りが必要である。
46 : すべきことは常に明確に
どの作業も必ず目的を明確に定め、十分短い時間で区切るべき。
やるべき作業を明確にするべきである
大事なのは「いつの間にか手探り状態になっていた」ということを絶対に避けるということ。
64 : プロのプログラマとは？
プロのプログラマの最大の特徴は、【自分が責任を取るという態度、責任感がある】ということ。
自分で最新の知識をえるように勉強し、自分の書いたコードに責任を持ちます。
チームプレイヤーであり、チーム全体のアウトプットに責任を持ちます。
限られた時間の中でも平常心を保ち、そのときにでき得る最善の処置を尽くします。
67 : コードを読む
ある人が「エレガント」と思うコードが別の人には「読みにくい」と感じられる、というのは大いにあり得る
読みやすいコードをみつけたら、よく調べ、そこから出来る限り多くのことを学び取りましょう。
自分が書いたコードを読み返すと、書いたときには読みやすいと思っていたのに、今読むとそうでもないと気づくがあるかも
とにかくコードを読むことが成長の秘訣
88 : コードは生涯サポートするつもりで書く
ベストプラクティスは多種多様であり、ずっと守り続ける事が大事
いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書くべきである。
これまでに書いてきたコードは、どれほど前のものであっても、好むと好まぎるとにかかわらず、必ず今の自分の仕事に影響を与えている。
コードを1行書く度に、ユーザのこと、顧客のこと、そして自分のキャリアのことを考えるべき
その他の話
14 : コードレビュー
大事なのは、コードレビューを行うことでチーム全員に同じ知識を共有させる事。
レビュアーは単に間違いを探すのではなく、個々のコードについて学び、理解することを心がけるべきである。
レビュアーやレビューされる人の関係性は常にフラットであるべきで、有効的な態度で望むべきである(そこに先輩後輩、上司部下はないのです)
レビューは楽しいものにするべきである(昼食やお菓子を食べながらなど)
17 : コードに書けないことのみをコメントにする
なんでもコメントにするのは良くない、コード自身が語れないことをコメントするべきであるということ。
コメントをみる側の立場に立って【価値のあるコメント】をするべきである
49 : 見積りとは何か
「ある機能を、ある期日までに(あるいは、あるイベントまでに)、一定以上の品質で提供する」などの【約束(コミットメント)】と、 「システムAは、同時に400人のユーザが利用できなければならない」などの【ターゲット】は、本来無関係なものである。
見積もりの目的とは、ターゲット、コミットメントを現実的なものにすることである。
見積もりという言葉の意味をプロジェクトに関わる人達が正しく認識しないと、見積もりの価値はない。
54 : 見えないものを見えるように
目に見えないということは危険なこと
ユニットテストを書くことで、対象コードのテストが難しいものかを明確にできる等 目に見える証拠がたくさんあるという状態を維持しておくべきである、
84 : 正しいアルゴリズムとデータ構造を選ぶ
適切なアルゴリズムを選ぶことは重要だが、それには適切なデータ構造を選ぶということも含まれており、 例えば、検索すべき項目の数が百万にもなる時には、リンクリストを使うか、ハッシュを使うか、それともバイナリツリーを使うかで、評価も変わるはず。
参考
プログラマが知るべき97のこと 無料で公開されているので気になった方は是非。
