プログラマが知るべき97のこと/偶然の仕様ではなく本物の仕様のためのテストを書く

プログラマが知るべき97のこと/偶然の仕様ではなく本物の仕様のためのテストを書く - Wikisource

1ヶ月に一回読みたい

簡単に書いてるけど実践は難しい。
必ずメソッドの構造を見てテストを書いてしまうから。
テストファーストを実践すればいけそう。
ただテストファーストが辛い。

[S] 単体テストでよくあるJSONXML、HTMLの比較だけでも実践(属性順に依存しないとか)のくせつけたいな。 単純に文字列化比較しちゃうとライブラリのアップデートとかで簡単にこけるテストになるからね。

[A] コードレビューはユニットテストレビューのつもりでやるといくらか解決されるかもね。

[M] 最近本当にそう思う。コードレビューで重要なのはテストコードなのではないか?という1つの結論。

[M] そこからTDD思想に則り、コードが最適化されていくという流れが一番自然なのではないか。と

[M] スレッドの問題とかユニットテストで保管できないコード的な問題はやっぱりコード本体をレビューする必要があると思うが、そこまで重要なコードって全体の5%もあれば多い方だと思うので考えなくても良いレベルかとも思う。

[S] ケント・ベックの書籍読み直すか。

プログラマが知るべき97のこと/車輪の再発明の効用

プログラマが知るべき97のこと/車輪の再発明の効用 - Wikisource

よく出てくる単語がまた出てきた。
この車輪の再発明の使い方はポジティブで良い

[S] 非常に頷ける。 問題解決能力のほか、自分でフレームワークとかライブラリを作る場合も土台になるよね。

[A] モノによるw

[A] 「自分の手でゼロからコードを書き、あれこれと試行錯誤をすることを通して学ぶ」のと「**を自分で作り直して組み込む」ってのは大きく違う。

[A] それと、荷馬車の車輪があるからと言って、自動車向けに車輪を再発明するのも違うし。

[A] 再発明や応用をする必要があるなら、その原理を学んでないと苦しいかもね…って事に還元されてしまう気がするわ。

[S] そんなもんすかね。

[S] ただ、

自分の手でゼロからコードを書き、あれこれと試行錯誤をすることを通して学ぶ これは、ハイコストハイリターンなのは違いない。

ワープロWYSIWYGをゼロから作ったことあるけど、掛かる時間やばい。得たものも相応に大きかったけど。

[A] 再発明は必要なときもある(特に新しいもの、新しい時代に)。

[A] 再発明すれば、勉強になる。

[A] どっちも間違ってないけど、作ってるモノによって、選ぶ方法は変わる。=モノによるw

[S] それは確かにそうですね。

[A] 「教育」というのは、「ひっくり返った亀がもがく」が必要。「生産」は「ひっくり返らない事」が必要。

[S] 面白いw

[A] 自社で後輩の面倒を見るときに、ここのジレンマが大変。教師はいいなーっていつも思う。

[M]

「教育」というのは、「ひっくり返った亀がもがく」が必要。「生産」は「ひっくり返らない事」が必要。

これいいね

[A] 教育現場の人はよく口にする話かな。

[S] 職場の教育でもがきをやらせるのは厳しい。

[S] というか、それは学ぶ側が自分で時間とって個人でやるべきだわな。

[A] 僕が、「教育」というのは「ひっくり返った亀がもがく」が本旨、と聞いたのは、道徳哲学の大学教員だったけど、

[S] なんで俺的には、良い技術者は勝手に育つから、人を育てるよりは育った人を離さないようにする職場が理想だと思ってる。

[A] 人格の形成とは「自己陶冶」という点に、とても共感している。

[A] 技術者の形成とは、技術者が自ら「自己陶冶」できるように育てることが、おそらくいちばん大事なんだよね。

[A] 「勝手に育つ」ように仕向ける。

[A] 「育った人を離さないようにする職場が理想」ってのもそうだけど、

[A] googleだっけか、コピーを作る人っていう話がどっかで出てたかな。

[A] 「面白いと思ってやってることが金になる」なら技術者は自ら学ぶし、いなくならないよね。

[S] そうですね。

[A] 「いまさらだけど*****の面白い仕組み」とかの勉強会とかみんなでやれるとそういう職場になると期待するしかないのかもしれない。

[M]

人を育てるよりは育った人を離さないようにする職場が理想だと思ってる。

僕にはこれは不可能に見える。 だって育ったら自分でやってみたくなるじゃん。 お金あったら、そのお金で時間買って作りたくなるじゃん。 組織の仕事できないじゃん。 組織にとって、よっぽどのことがないと引き止める理由ないじゃん。 辞めるよね。

組織にいながら頭を抑え付けられず自分のやりたいことができる組織って、それ組織として崩壊してる気もするので、なんか矛盾していて不可能に思えた。

[A] 絵描きは絵描くのが好きだし、音作りやる人は音作るの好きだから、そこら辺組み合わせるコーディネーターがいるかどうかも大事だと思ってる。

S さっきでたけど、内的報酬、外的報酬の話だと思う。

[A] アメフトの司令塔はQBだけど、実際はオフェンシブコーディネーターとQBは試合中インカムで会話しながらやってる。WRやHBは走るの好きだし、TEはぶちかましが好きだし、Sは人の妨害するのが好きなので、それでいいと思うよ。

[M] まだ読めてない。探して読んでくる

[A] キーは前に出た人は24時間しかないって事じゃないかな。全部出来ないし、得手不得手はあるから得意な事で進めたいし、得意を伸ばしたい。

[A] 管理に行きたいか、技術に行きたいか、業務を抱えたいか。

[A] 一応は本人の希望を考慮する。適正ないと可哀想な扱いになるけど。

[M]

さっきでたけど、内的報酬、外的報酬の話だと思う

読んだけど、やっぱり 内的報酬 を100%満たすことはできずに結局独り立ちすることになりそう。 なので、どれだけ組織が 内的報酬 外的報酬 を用意しても実現は難しそう。

googleとかの超大手は最前線でこれ意識してそうだけど、結局優秀な人って独立してない?

[S] それ、「正解はひとつ」になってなければ良いのだけどね。 高給取が「管理」に集中してるようだと良くなさそう。

[A] 管理者は高給取だけど、技術選んでも業務選んでも割と食っていけるだけの年収はあるらしい。ベーシックインカムみたいなもんやね。

[A] だから辞める人は、自分の内的理由で辞める人が殆ど。

[A] お金ではやめない。

[A] 独立はしてもいいやん。

[A] 会社にとっての人的資産流出は、仲違いなのだから。

[A] 昔で言うアスキースクエニなんかも、辞めて独立しても出入りして仕事してる人多いし、会社もそれなら全然オーケーだと思う。

[S]

会社にとっての人的資産流出は、仲違いなのだから。

うまい。確かにそうだな。

今日のポエム

githubコードレビューはエゴの塊だ。

そのコードが良くなるというより、俺が読みづらいから直せの雰囲気を感じる。

これではダメだ。

ほんの少しでも良くなる指摘をするべきだ。

それは命名による読みづらさではない。
実行時パフォーマンスという点でだ。

A ソフトウェア品質 - Wikipedia

S

コードレビューの内容実際見ないと感想は言えんな。
前もなんか同じ話題した気がするけど、コーディング規約じみたチェックはするけど、コードの中身はあまり読んでもらえないんだっけか。

命名規則云々はコーディング規則で規定するべきで、それに則ってなければただの誤字脱字みたいなもんで、指摘は有りだけど、議論するところではない。
さっと流して中身を議論するべきで、そこ出来てないなら本末転倒ではあるかもですね。

M

今の僕の印象だと、命名指摘:8割、パフォ指摘:2割ってイメージ。

致命的でない限り命名指摘の費用対効果って、薄いと思うのでそれに対してかけている時間(チェック・変更修正・確認)が無駄にしか思えない。

S

言いたいことはまた違うんだろうけども。
コードの見やすさ自体は最終的な工数にも響くんでかなり重要だと思ってる。

まあ、コードの見易さは最終的に宗教問題だから、合わないと最悪

見やすいコード とは => 一貫性のあるコード => コーディング規約を規定
コーディング規約に規定しない一貫性 => プロジェクトの王様の思想に合わせる

最終的には郷に従わないといけない部分が出てくる。

ただのローカルログ

プログラマが知るべき97のこと/いったんコンピュータから離れてみる

プログラマが知るべき97のこと/いったんコンピュータから離れてみる - Wikisource

 

煮詰まった時に読みたい

プログラマが知るべき97のこと/プロのプログラマとは?

プログラマが知るべき97のこと/プロのプログラマとは? - Wikisource

 

1ヶ月に一回読みたい

プログラマが知るべき97のこと/ユーザの操作ミスを防止する

プログラマが知るべき97のこと/ユーザの操作ミスを防止する - Wikisource

 

>「入力して欲しいのはあくまで情報であり、データではない」ということを考慮すべきでしょう。

 

超重要

プログラマが知るべき97のこと/プリミティブ型よりドメイン固有の型を

プログラマが知るべき97のこと/プリミティブ型よりドメイン固有の型を - Wikisource

 

型違いだけで300億吹っ飛んだ話が強烈だった