はじめに

この記事はプログラマが知るべき97のことの感想文です。
97と言いつつ、日本人の方々の寄稿も含めて107まであります。
どうせ読むなら、それぞれの記事に対しての自分の感想も書き留めておこうと思い、ここに投稿します。
無料で読めますし様々なプラクティスが紹介されているので、私のようなエンジニア歴がまだ短い人や新人などが読むのに最適なものだと思います。
読んだことがない人は、是非1度目を通してみてはいかがでしょうか。

お前は誰だ？

経験浅のJavaエンジニアです。
詳細な境遇についてはこの感想文を読めばなんとなく察しがつくかと思いますので、あえて書かないことにします。

この記事について

• 基本的には1記事に対して3行の感想を書くようにしています。今北産業とも言いますしおすし。

• あくまで私の感想なので、間違っていることを言っていることもあると思いますのであしからず。

  「それあなたの感想ですよね？」

• 意図的に言葉の強さを使い分けています。

• 今後考え方が変わっていったら、追記していこうと思います。

以下、感想文

1.分別のある行動

• 技術的負債はできるだけ早く返済する->完全に同意。ジェンガが積み上がってしまってからでは遅い。
• コードにおいての技術的負債＝コードを書いた人の秘伝のタレ。
• 技術的負債の存在が忘れられないようにしておくべき->最低限メモ程度の内容をテキストでまとめるとか。一番いいのはそれ専用のWebシステムみたいなものがあること。

2.関数型プログラミングを学ぶことの重要性

• TDDをやる上で必須。
• FPもOOPも違いはないのか。
• FPをやらなくても学ぶ意義はあるから学ぼう。OOPへの理解にも繋がる。

3.ユーザが何をするかを観察する（あなたはユーザではない）

• ユーザは基本的にだいたい同じようなことをする->確かに。
• 往々にして、ユーザが言うやりたいことと実際に求めていることには差異があるよね。
• コンサルの基本は人間観察ってことか。

4.コーディング規約を自動化する

• どんだけ口で言っても、ドキュメントを用意してもコーディング規約は破られる可能性がある。
  • だから強制的にフォーマットしよう。
• コードフォーマット、テスト、デプロイまで自動でできるようにできればいいね。
• それをやるためには根本的に開発プロセスを考え直したほうがいい。TDDを試そう。
• 試すことによってかかるコストは投資として考えろ。

5.美はシンプルさに宿る

• そのシンプルにするっていうのが難しいんだよ。
• FPを学べば、もうちょっとはシンプルにする方法論が身につくのだろうか。
• 複雑なビジネスロジックをいかに分解できるかは、その人の経験値によると思う。

6.リファクタリングの際に注意すべきこと

• どんなにうんコードでも、それが実際に動いていれば正しいものだということ、破棄するな。
• 少しずつの変更(インクリメンタルな変更)を数多くするべき->もうアジャイルやれって言ってるようなものじゃん。やっぱウォータフォールは今の時代きついってことか。
• 人間は必ずミスをする->特に自分自身に対してこの意識を強く持て。そしてチーム全員にこの意識を浸透させよう。

7.共有は慎重に

• コードの再利用≠絶対的正義。
• 背景をコードのコメントに書こう。
• 影響箇所が膨大になる危険性もあるから、コードレビューはやろう。

8.ボーイスカウト・ルール

• 分別のある行動とほぼ同じ。
• 少量の変更を加えるたび、技術的負債の返済を少しずつでもいいからしていく姿勢はいいことだと思う。
• 一気に返済するか、少しずつ返済するかはそのチームの方針次第かもしれないが、一気に返済の場合、破産する可能性があることも考慮しよう。

9.他人よりまず自分を疑う

• これは仕事をする上ので鉄則。何か問題が起きたときはまず自分を疑え。
• まず他人を疑う人はチームの人間関係を徐々に悪くしていく。結果的に他人が悪かった場合でも、そういうスタンスの人はチーム形成の面で害悪。
• 他人が悪かった場合でも、それを非難、叱責するコミュニケーション方法は心理的安全性を欠如させてしまう。そういったときのコミュニケーションの仕方は超重要。

10.ツールの選択は慎重に

• ツールはあくまで手段、そのツールを使ってみたいといったような、ツールを使うことを目的としないようにしろ。
• ツールを自作することはしないほうがいいと思う。属人化の温床だから。
• 適切なツールを検討して導入しろ。長期的に見たコストを計算しろ。今忙しいから既存のツールで…ではなく、未来を考えて投資しろ。

11.ドメインの言葉を使ったコード

• とりあえずリーダブルコードは読め。できれば業務時間を使って仕事として読ませてほしい。
• ロジックで悩むより変数名とか関数名とかで悩む時間のほうが長くない？
• 何ヶ月か時間が経ってからコードを見たプログラマは、きっと最初にコードを書いた人に感謝するでしょう。そしてそのプログラマは、最初にコードを書いた本人かもしれないのです->あるある。「過去の自分ナイスゥ！」って思えるコードを書こう。

12.コードは設計である

• 設計と実装は一体って何回言えばわかるんだ。設計書ぽんって渡してコーダーにそれを書かせるっていうやり方には限界がある(それができるのはつよつよエンジニアが設計を行ったときだけ)。設計と実装は同一人物が行い、2つをサイクルしていくっていうやり方にならざるを得ない。
• やっぱTDD推奨じゃん。
• 設計が不十分なまま製品が作られることがどうしても多くなる->あるある。必要なのは実装者とユーザ、あるいはプロダクトオーナーによる話し合いを実装中に複数回行うこと。

13.コードレイアウトの重要性

• やっぱりリーダブルコードは読め。
• 目立たない部分を作る->目から鱗。重要じゃない部分はあえて違いを作らないというコーディング技法、ありだと思います。
• 以上のことから、エンジニアもデザイン知識が必要だという(極大)解釈。すべての知識はどこかで繋がっていると思っているので、1つのことだけ学ばせ続けるより幅広くやらせたほうがいいと思う。

14.コードレビュー

• コードレビューの共通目的の1つとして、チーム全員が同じ知識を共有するということを明確に意識しろ。全員で他のビジネスロジックを学ぼう。
• そうすれば人がシステムに紐づく問題がある程度は解消される。パートナーを雇ってコード書かせるなら、なおのことコードレビューをやらなければならない。やれ。
• コードレビューを行う上ので絶対的条件は心理的安全性が確保されていること。
• お菓子を食べながらのレビュー->レビューを楽しませるための1つの方法として有効。
  • それお前がお菓子食べたいだけだろ。

15.コードの論理的検証

• リーダブルコードの内容とほぼ同義。やっぱりプログラミング一通り学んだあとに必ず最初に読め。
• java beansNG説。OOPにおいては間違いではない。ただコーディングはむずくなる。

16.コメントについてのコメント

• これもリーダブルコードに書いてあるじゃん。
• ただ私はコメントはできるだけ書いとけ派。ちゃんとした設計と英語ができるやつが少ないので、英語のように読めるコードを書けないから。あるいは読めないから。
• つまりは設計と英語を勉強すれば必要最低限のコメントでいい。

17.コードに書けないことのみをコメントにする

• 16.と同じ。

18.学び続ける姿勢

• 1日1つ新しいことを学べ。
• 社員のトレーニングのために時間やお金を割かない会社は多分衰退すると思う。理由はそういう環境の中、自分で学ぼうと思う人間は一握りであり、その一握りはもっといい環境に行こうと会社を変えるから。また、自学習は自己申告にしかならず、他人に見えない。誰がどれくらい頑張っているかが見えない環境では、みんな今の仕事をこなして生きているように見えてしまう。とりあえず今の仕事がこなせていればいい、必要になったタイミングで知識を学べばいいぐらいの熱量になり、結果的に現状維持=緩やかな衰退へと繋がっていくから。
  • 自学習の成果を労働の成果として出力すればいいじゃん。
    • その成果が自学習の結果であることをどうやって計測するんだよ。
      • 労働時間？バク発生率？どちらもより少なければ、質良く短い時間で作ることができているということになるから。
  • 会社って人の集合体なわけだし、個人が成長しなければ会社も成長しないから、社員への投資＝会社の成長になると思う。
    • 個人が成長しないと会社も成長しないっていうデータあるのかよ。
• せめて複数人で同じものを学ぶシステムを作れ。勉強会がいい例。共通の技術書を共通の範囲まで各自読み、週1回15分でもいいので読んできた箇所に対する感想意見を述べる場を作るなど。それぐらいの投資はしろ。

19.誰にとっての「利便性」か

• リーダブル。
• APIは特に気をつけようって話。呼び出す側のことを最大限思いやろう。
• APIに変更を加えることはもっと難しい。まるで子育てのような難しさ->それならさしずめ開発は子作りってところか。

1つミスを犯してしまったら、人生を捧げてサポートしなければならない

20.すばやくデプロイ、こまめにデプロイ

• 兎にも角にも動くこと。そのために環境を整えておくことを優先するのは当たり前。画面を開発するならユーザに見てもらうためになおさら必要。
• CIツールとかコンテナ環境の検討をしたほうがいいと思う。
• コードのテストとリファクタの感覚でデプロイをしろ。

21.技術的例外とビジネス例外を明確に区別する

• 例外を区別して意図的に処理するか、セーフティネットで受け止めるかっていう構造の話。
• Webアプリ開発の知見ってだけ。

22.1万時間の訓練

• エキスパートになるための時間＝1万時間というマジックナンバーって何基準？
• 業務時間1日8時間で考えれば3～4年ぐらい？
• すべてはあなたの意志次第->間違いない。学んだ先にどうありたいかという意志を持て。

23.ドメイン特化言語

• 業務専用言語ってこと？
• 業務専用言語はわかりやすいようにまとめておいてほしい。
• できれば社内wikiがほしい。

24.変更を恐れない

• ジェンガをやっているようなもの->間違いない。
• 将来のコスト削減につなげるために、今投資しろ。
• 塔が築き上げられてしまってからでは、様々なことにコストがかかってしまう。

25.見られて恥ずかしいデータは使わないこと

• ただの笑い話で草。知るべきことでもなんでもない。
• テストデータとはいえ、仕事なんだから公を気にしろってこと。
• そんぐらいの分別はついてるでしょ。
  • それバイアス。

26.言語だけでなく文化も学ぶ

• 他の言語を学ぶことによって母国語のことをより深く知ることができる。プログラミング言語もまた然り。
• 比較対象を得ることで学びが増える。
• どんな物事にも背景は存在し、そこを理解することが本質を知るということ。

27.死ぬはずのプログラムを無理に生かしておいてはいけない

• 最初の風刺が面白い。
• 「例外を握りつぶせばい」に対する返しが素晴らしい。私も使いたい。
• 例外はきっちり処理しよう。当たり前。

28.「魔法」に頼りすぎてはいけない

• 魔法＝白鳥のバタ足。
• たいがいのものは簡単そうに見えて簡単ではないということを意識しろ。
• だからこそ幅広い知見が必要。プログラマはマネージメントを、マネージャーはプログラミングのことを一定水準は学んでおこう。

29.DRY原則

• DRYに書けるような設計をしたい。
• チームで開発する際にこの原則を守らせることってかなり難しいのでは？
• 技術レベルの底上げをするにはどうしたらよいか。

30.そのコードに触れてはならない！

• 役割を分けるという点では正しい。
• 本番環境、ステージング環境で直接コード修正することとかありえないだろ。
• DevOpsの文化の興隆という観点からみて、一部話の内容が古いと感じた。
  • DevOpsをしっかり理解しているわけでもないのに、それっぽいこと言うな。

31.状態だけでなく「ふるまい」もカプセル化する

• プリミテイブ型のsetメソッドとgetメソッドだけから成るようなクラスは決して珍しくありません。そういうコードを見れば、関わっている人間がオブジェクト指向を十分に理解していないことがすぐにわかります->胸が痛い。そんな時期が私にもありました。JavaBeansアンチパターン説。
• 責務の委譲->研修では教えてくれないOOPの最重要内容。あるいは教えているが簡単には理解できない。
• 「ふるまいのカプセル化」= 委譲。

32.浮動小数点数は実数ではない

• float型,double型を使うことがないので全然ピンとこなかった。

33.オープンソースプロジェクトで夢を実現する

• 自己実現したいならOSSに参加しようってことか。
  • どんだけ意識高いんだ。
    • バカにしているわけではないです。
• 自分が何をしたいのかを知るきっかけにもなる。
  • 自分探しの旅みたいだな。
• 私はプログラミングで自己実現しようとは思わないけどね。プログラミングはあくまで仕事。

34.API設計の黄金律

• APIの開発ってむずいよねっていうだけの話。
• テストもむずいよね。
• 使用されることを考えていろいろ気を遣おうね。

35.超人の神話

• 超人=つよつよエンジニアを超えた何か。0.1を聞いて10を解答できる人間などいない。
• 差はあれどできる人間は勉強しているということ。
• 謙虚でいろ。情報を収集し、分析し、最適解を答えられるようになろう。何でも知っていかのるように振る舞うな。

36.ハードワークは報われない

• いい意味でめんどくさがりであれ。
• 効率よく働く->空いた時間で勉強する->勉強した知識で新しい価値を生み出す/さらに効率よく働く->以下正のループ。
• 仕事量が膨大->効率を考えても時間がかかる->勉強する時間が取れない->モチベーションも上がらず効率も悪くなる->勉強する時間が・・・の負のループに入ってしまっていた場合、どうしたら脱出できるのか。
  • いったん全部放り投げてリセット。
  • 雑すぎる。

37.バグレポートの使い方

• 本来の仕様がわからないってことが往々にしてあるんですが…。
• バグレポートもコミュニケーションツールの一種であるから、ちゃんと相手のことを考えよう。
• バグ数はなにかの単位、基準ではない->じゃあなんの単位なんだよ。

38.余分なコードは決して書かない

• 引き算の美学。
• プログラマは身勝手になってはならない。
• 極めてシンプルに、要件を満たすようにしよう。

39.最初が肝心

• いかにして最初に人を引きつけるかが肝心。
• これはソフトウェアだけに言えることではない。
  • 小説も最初の数行が素敵だったり、映画も最初の数分が魅力的だったりしていると、気合入っているなって思うよね。

40.プロセス間通信とアプリケーションの応答時間の関係

• PC.スマホの性能がどんどん向上しているから、どんどん複雑なアプリケーションが増えている。だからこそ、どこまでのレベルならユーザが不快に思わない速度なのかを考慮する必要がある。
• 最低スペックを高めに設定しておいて、遅いのはその基準を満たしていないからです、みたいな言い訳をするのもありか？
• やはり阿部寛のホームページ最強といったところか。

41.無駄な警告を排除する

• ちりつも。
• 警告もできる限り潰しておいたほうがコードの可読性も向上する。
• これもできるだけ自動化したい。

42.コマンドラインツールを使う

• IDEはプログラムがどう動くかっていうところを隠す。プログラムはどうやって動くのかを理解しておこう。
• ツールはプロセスを便利にする。ただそのプロセスを知らなくてもいいということにはならない。
• 本質を知っていればツールにこだわる必要もない。応用が効くようになる。

43.プログラミング言語は複数習得すべき

• 1つの言語しか知らないプログラマは、その言語の枠の中でしかものを考えられなくなってしまいます->間違いない。
• Javaの他にはC系、LL言語の何か、Haskell、Scara等の関数型言語を覚えるのがbestか。

44.IDEを知る

• 昔はただのテキストエディタでプログラミングしてたってまじかよ。
• IDEに限らず新しいPCツールを使うときはショートカットを覚えて効率よく動かしていこう。

45.限界を知る

• 記事がからっぽだった。

46.すべきことは常に明確に

• プロジェクトの目標を理解した上で、その日する作業の目標まで細分化して計画しよう。
• 大事なのは「いつの間にか手探り状態になっていた」ということを絶対に避けるということ->「よくわからないけど動いているからヨシ！」はだめってこと。
• たとえば2時間で完了させる予定だった作業にそれ以上の時間がかかりそうだと途中でわかってしまったらどうするでしょうか。その場合、彼らはまず、その作業で書いたコード、加えた変更をすべて破棄するでしょう->いや流石に厳しすぎない？

47.大量のデータはデータベースで

• もはや当たり前の話。
• NoSQLについても学ぼう。

48.いろいろな言葉を学ぶ

• ここでいう言葉はいろいろなドメインの言葉を学ぶということ。
• エンジニアの仕事の半分はコーディング、もう半分はコミュニケーション。
  • いうほど半々か？むしろコミュニケーションのほうが割合多くない？
• いろいろな知識を持って入れば、相手に伝わる言葉を選ぶことができる。時としてエンジニアは翻訳家になるということ。

49.見積りとは何か

• 事実をもとに見積もりしろ。過去のデータは嘘をつかない。
• コミットメント≠見積もり、コミットメントに基づく見積もりをするのではなく、ターゲットに基づく見積もり、見積もりに基づくコミットメントをしろ。
• プロジェクト初期時点での見積もりは不確実性を多く含んでいる。だから基本的に初期時点の見積もり通りには行かない。

50.Hello, Worldから始めよう

• 初心忘るべからず。

51.プロジェクト自身にしゃべらせる

• XFD初めて聞いた。これあったら面白い。
• マスコットが動くとか凝ったことしないまでも、ランプの点灯ぐらいはあってもいいと思う。

52.「その場しのぎ」が長生きしてしまう

• あるあるすぎる。確かに暫定的ではあれ、それが正常に動いている以上、別に急いで正当なものに変える必要はなくね？って思っちゃう。優先度も下がっちゃう。
• 暫定ソリューションは一旦放置。その内容も含んだよりよいもので上書きして、そっと閉じることが解決法。
• 問題が解決できれば手段なんてある程度はどうでもいいから、イレギュラーなものを作ってもいいと思う。その時に作られるイレギュラーなものはいつでも取り外し可能にさえしておけばいいと思う。

53.正しい使い方を簡単に、誤った使い方を困難に

• これもAPIの設計手法についてのお話。
• APIに限らず、使用する側が誤った使い方をすることを想定して、制限をかけるような作りになっているようにしよう。

後編へ続く

デス・ストランディングとゲームの王国読み終わったら書きます。
読み終わったので書きました↓
https://qiita.com/kei3524848/items/1e100269fb8952fe6dd1