「プログラマが知るべき97のこと」を読んだ① 1〜30
読みながら思ったこととかぐっときたとことかをメモ。
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
分別のある行動
- 技術的負債のために払っているコストを常にトラッキングすること
- ここでいう「技術的負債」は、「正しく作る」と「手早く作る」が対立したときに後者を取ったために発生した「正しくない作り」のこと
- 💬 たしかに額がわからないと負債の重要性もわからない
関数型プログラミングを学ぶことの重要性
- 参照透過性:同じ入力に対して常に同じ出力を返す。状態に左右されない
- 反対にオブジェクト指向プログラミングでは、オブジェクトの持つ変数の値が状態によって変わっていく
- オブジェクトではなくロール( 💬 インタフェースと同じ意味合い?)をモックするようなテストを書いて開発すれば、状態依存は避けられるかもしれない
- 反対にオブジェクト指向プログラミングでは、オブジェクトの持つ変数の値が状態によって変わっていく
- 💬 関数型プログラミング、ちょっとやってみるとしたらScalaかElixirあたりになるのかな
ユーザが何をするかを観察する(あなたはユーザではない)
- ユーザはたとえ非効率でも一度確立したやり方を変えない
- 💬 そうなんだよなーーー
- 💬 その点、ギーク向けのツールとそうでないツールで見た目とかカスタマイズ性とかがだいぶ違う気がしているので、他サービスを参考にするときはそれのターゲットが自分のサービスと重なっているか注意する必要がありそう
- (まあ他を参考にするとかの前にユーザを観察しろという話である)
コーディング規約を自動化する
- コードの整形処理をビルドプロセスに含めてしまう
- コードの静的解析でNGが見つかったり、テストカバレッジが低すぎたりしたらビルドプロセスを止める
- 💬 rubocopとCodecovは前職のCIに入ってた
美はシンプルさに宿る
- 💬 rubocopでmethod lengthとかABC sizeとかでひっかかるということはシンプルでないということなんだよな
- そういうときは抽象化がうまくいってないのかもしれない、デザインパターンの力が借りられるかも?
リファクタリングの際に注意すべきこと
- 既存のコードベースやテストの良い点・悪い点を洗い出す
- 一度にゼロから書き直すのではなく、インクリメンタルに変更する
- 修正する理由を明確にする
- 💬 1つ目のエッセイのとおり負債の「額」を明確にしておくとやりやすそう
- 書き換えると必ずコードが良くなるというわけではないことを肝に銘じる
共有は慎重に
ボーイスカウト・ルール
- 来たときよりも美しく🚿
他人よりまず自分を疑う
- 💬 ウッ頭が
- 💬 原因の候補をまず洗い出して、自分絡みのものからつぶしていくとか?
ツールの選択は慎重に
ドメインの言葉を使ったコード
- ドメインに沿ったクラスを作り、それが何のために何をするかわかるメソッドを作る
- 💬 そうか、クラスは「ユーザー定義型」なのか。納得
コードは設計である
作る人間の能力を超えるほどの高度な製品、複雑な設計が求められていて、しかも製品を早く市場に出せという圧力が強いような状況
- 💬 設計に力を割くべしということかな
コードレイアウトの重要性
- 💬「目立たない部分」はメソッドに分割してあげたほうがいいんじゃないかという気もする
コードレビュー
- レビューの瓦解を防ぐ
- レビュアーをランダムで割り当てる
- 複数のレビュアーを割り当て、見る部分の担当を分ける
- ドキュメント担当、例外担当、機能担当
- 💬 えーなるほどすごい、やってみたい
コードの論理的検証
コメントについてのコメント
https://twitter.com/t_wada/status/904916106153828352
コードには How テストコードには What コミットログには Why コードコメントには Why not
💬 コメントからAPIを自動生成するツールを始めから入れておくの良さそう
コードに書けないことのみをコメントにする
- 💬 保守されていない嘘コメント、よく見かけた 😢
- ノイズのように見える(なぜあるのかわからない)コメント、読んでもよくわからないので書き換えてよいものか迷わしくて保守されにくいイメージ
学び続ける姿勢
- 自分で学び続ける方法を身につける
- 💬 「達人プログラマ」読むべきなのか……
- 💬 「1週間に1回1時間でも、やらないより良い」そうなんだよな
- 今なら働きながら勉強できる気がする
誰にとっての「利便性」か
- コードを書く側ではなくAPIを使う側にとっての利便性を考える
- 似たようなコードが重なる、みたいなのは書く側の事情
- 「冗長性」の反対は「利便性」ではない
💬 たしかに
walk(true)というようなコードを書かされるよりは、単にrunと書ける方が間違いなく使いやすい
- 分岐に使うような引数が多いと少し疑ったほうがいいのかも
すばやくデプロイ、こまめにデプロイ
- 開発初期からデプロイフローを作っておく
💬 耳が痛い
「開発者のコンピュータで一応動作する」という状態から、「デモが可能である」という状態にするまでには、相当な作業が必要になるのです。
技術的例外とビジネス例外を明確に区別する
- 技術的例外 → トップレベルまで例外を渡す
- 💬 予測不可能
- ビジネス例外 → クライアントだけで処理する
- 💬 予測可能
- あらかじめ対応を組み込んでおく
1万時間の訓練
- 能力を高めるために1万時間つかえ
💬 目標が巨大すぎるのでまず1年で1000時間とか……?
ドメイン特化言語
変更を恐れない
- 💬 冷静に思い返したら昔やってた開発けっこう変更怖かった
- 1つのクラスに大人数で手を入れてたら怪しいと思え、というやつか
- こういうのを「怪しいという説もある」だけじゃなくて本気で「怪しい」と思わねばならんのだな
💬 やるぞの気持ち……
「病気の」システムを治すことがプロジェクトのメンバーにとって経験になるということです。その経験によって、システムは本来どうあるべきかを全員が理解するようになり、システムについてのエキスパートになる
見られて恥ずかしいデータは使わないこと
- テストデータ・サンプルデータとしても駄目
💬 語呂が良いw
TERRIBlE HORRIBLE NO GOOD VERY BAD HACK
言語だけでなく文化も学ぶ
- 💬 つかってる言語はAなのに書き方がどことなく別の言語Bっぽい、というのは自分でも経験ある気がする
死ぬはずのプログラムを無理に生かしておいてはいけない
- 💬 ウッ頭が
- 💬 クラッシュしたときにユーザーに次に取ってほしい行動を明示できるのが良いエラー画面だと思っているけど、それとこのコラムは矛盾しない
「魔法」に頼りすぎてはいけない
- つまり魔法は無い
- 💬 本当に不要かどうか、不可逆的に外す前に1週間くらい落としてみるといいのかも
DRY原則
- 作業の重複:自動化する
- ロジックの重複:クラスに切り出す(デザインパターン)
「こういう問題が起きそうだから原則をあらかじめ破っておこう」ということをしてはいけない
- 💬 「DRYやりすぎ問題」もよく聞くけど送り仮名みたいなものなのかもしれない
- 活用する部分を送って、そうでない語幹部分を漢字で読む
- 漢字部分がDRY
- 活用されうる部分まで無理やり漢字に含めると変更できなくなる
そのコードに触れてはならない!
- 💬 すごい細かく担当がわかれててびっくりした。リリースマネージャって誰……?
- しかしステージングにあがったものに直接手を加えるのは言語道断であることには同意