Magnolia Tech

いつもコードのことばかり考えている人のために。

『Learning Go』を読んで、Goに入門している

Learning Go: An Idiomatic Approach to Real-World Go Programming (English Edition)

Learning Go: An Idiomatic Approach to Real-World Go Programming (English Edition)

Amazon

A Tour of Goにチャレンジしたことがあるくらいで、Goをちゃんと勉強してこなかった。

さすがに、ISUCONの問題がGoが最初に作られている時代に、やっぱりちゃんと学んだ方がいいかなと思って、買ったまま積んであった『Learning Go』を読んでいる。

Go固有の、キャッチーな所を先に説明するようなことはなく、淡々とリテラルから始まり、制御構造や、struct、goroutineなどの解説に進んでいくので、あまりつまみ食いしながら読む感じでもなくて、１週間くらいかけて最初から最後まで読む、みたいなスタイルの読み方の方が良いかも。

随所に機能の経緯や、背景、他の機能との関連が差し込まれていて、単に機能解説書になっていない点もよかったです。

”プログラミング自体”への入門本ではないので、最低限一つは他の言語で一通り書けるくらいのスキルはないと読みこなすのは難しいのと、演習問題が無いので、学んだことの確認がしづらい、みたいなところはありますが、他にGoで書かれたコードの事例を見ながら一緒に見ていくとか工夫が有れば、このくらいの記述量で十分ですね。

設計ナイト 2022 「トランザクションスクリプト」を開催し、登壇しました

年に一度のお楽しみ、設計ナイトを6/14に開催しました(去年はお休みしてしまったので、2年ぶりの開催でしたが)。

kichijojipm.connpass.com

今回のテーマは「トランザクションスクリプト」...マーチン・ファウラーさんの「エンタープライズアプリケーションアーキテクチャパターン(PoEAA)」で紹介されたアプリケーション構造に関するパターンの一つです。

当日の資料もアップされています。

kichijojipm.connpass.com

今回珍しく(?)、『トランザクションスクリプト起点の開発は、“なぜ”生まれるのか？』というタイトルで、登壇もしました。

スライドはちょっと当日のコンテキスト次第なところもあって、そのままアップしてもアレなので、割愛しますが、要はトランザクションスクリプトって”分かり易い”んですよね、という話をしました。

ユーザーからヒアリングしたユースケースをそのまま機能に写像し、機能単位に実装する要員をアサインできると、”分かり易い”ですね（誰にとって？） しかも、よりたくさんの人を同時並行でアサインできる

ドメインモデルや、共通設計を最初に作り込めば作り込むほど、コミュニケーションパスが増加し、相互の影響によるアジリティの低下が有るよね、という流れで話をしました。

それが良いか、悪いか、現代に合うか否かは別として、現実そこに存在する「価値観」は否定しすぎてはいけないのではないかな、と。

何かの意思決定は、何らかの価値判断に基づいて行われるものなので、それが何なのかは常に考えておくといいですね

トレードオフの判断ポイントは変わっていくよね、という話

ということを、しんぺいさんのツイートを読みながら考えた。

『達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践』を買った！

達人が教えるWebパフォーマンスチューニング　〜ISUCONから学ぶ高速化の実践

達人が教えるWebパフォーマンスチューニング　〜ISUCONから学ぶ高速化の実践

Amazon

すいません買ってきたばかりで、まだ全然読んでないんですけど、これが言いたかったので、エントリを作りました。

あと、冒頭の第1章のメッセージがめちゃめちゃ良かったので、引用しておきます。

あと、何と言っても、Webサービスを高速化できるエンジニアはかっこいいと思いませんか。高速なWebサービスを実現する、パフォーマンス問題をバシバシ解決する、パフォーマンス問題を起こさないシステムを実現できるエンジニアに筆者は憧れますし、尊敬します。

「こんな小さな売り場の本屋だと無いかも...」と思いながら、ぱっと入った本屋にも置いてあったので、けっこう幅広く配本されているようです。とにかく近くの本屋へ行って買いましょう。

この手の本は、読み終わったら誰かに貸したくなったり、あげたくなったりするタイプの本なので、紙の本で買った方がいいんじゃないかと思います。

今年参加登録できなかった人も、来年に向けて買っておいて１年間素振りして、臨んでいきましょう。

今年参加登録できた人は、もう１ヶ月後なので、さっさと素振りしましょう。

データとコードと運用のそれぞれの時間軸を総合して初めてビジネスドメインが完成すると思っている

ドメインに関するコードのテクニックの話の時に、同時に運用やデータの話がセットで語られないのはいつも違和感が有る...実際の開発だと常にセットで語ってない？

プログラミングのプラクティスへの向き合い方

結局これ

『良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』は、駆け出しからマネージャ、経営層までコードに関わる人、コードからの恩恵を得る人、みんなが読むと良い一冊ではないでしょうか

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

Amazon

面白かったので土曜日の午後に一気に読み切ってしまった。今年は、ソフトウェアやシステムに関する技術書が豊作な年ですね。10年後でも十分に通用する本ばかり出版されていますね。

本書『良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』もそんな1冊です。

仮に、この本を駆け出しエンジニアの時に買っても、その後のキャリア......シニアエンジニア、マネージャー、人事や経営と、色々な立場の時に「使える本」になります。それは、この本が技術を理解するだけでなく、「エンジニアの価値観を理解するための本」と言ってもいいからでしょう。

  • 駆け出しの人は、「良いコード」と、「悪いコード」の区別の仕方、というより、そもそもそういう区別があること自体を理解するのに読むと良いです
  • 駆け出しを過ぎたくらいの、目的のコードがとりあえず書けるようになった人は、自分の中の成功パターン以外にも色々なプラクティスを網羅的に学ぶのに読むと良いです
  • ソフトウェア開発を指導する立場の人は、良いコードと、悪いコードの区別を教える際の語彙や概念を、オレオレ理論ではなく汎用的なプラクティスとして伝えるための教材として読むと良いです
  • 人事や、組織をマネジメントする層の人は、ソフトウェアを取り巻くエンジニアが何を重要視していて、そしてそれはなぜなのか？という価値観と、その背景をを理解するために読むと良いです
  • ソフトウェアの出来映えや、開発スピードがビジネスに大きく直結する組織の経営層は、コードにはさまざまな書き方が有って、それがビジネスのスピードに影響するを理解するために読むと良いです

ソフトウェアのプラクティス、全部一人でやっていれば導入するのもしないのも一人の判断でできるけど、組織で、事業としてやっている場合はそうはいかず、いくつかの階層に別れてきます。

それぞれの層がお互いにコミュニケーションを取るためには共通の理解・語彙が必要で、この本にはそのために必要なことがたくさん詰まっている、詰まり過ぎている。

とはいえ、実際のプロジェクトでは、そのレイヤーにおける責任を持つ人が適切な判断をして、意思決定をしないといけないです。で、その時に、そこに悪気が有る人は居ないし、みんなそれぞれがやるべきだと思っていることを一生懸命やっているはずなんですけど、上手く行かない時がある。

で、そこに無いのは、共通の語彙であり、立場が異なる／階層が異なる人同士のコミュニケーションだったりします。

そんな時に、真ん中にこの本が有ると、少し世界は分かり合えるのかもって思いました。

この本で触れられている実態を表していない命名、複雑すぎる条件分岐、重複するコード...どれも現実のコードに出てくるけど、誰も悪いコードを書きたいと思って書いている人は居ないはずなんです。目の前の課題を解決するために一生懸命やっているはずなんです。でも、悪いコードが誕生してしまう、放置されてしまう、それが後世の人を苦しめてしまう。

駆け出し以外の人は、「なぜそれが起きてしまうのだろう」という視点で読むと良いと思いますし、それを考えなければ結局変わらないですよね。闇雲にこの本を渡して、「さぁ、ここに書かれているのは悪いコードの例だから、そんなコードは書いてはいけません」なんていう”指示”を経営層や、マネージャーが言い出しても、何も良くならなくて、「なぜ？」をちゃんと考えていかないといけないし、そこにある別の価値観の存在を理解しないといけないんです。

で、ようやく本書の内容に触れると......とにかく第1章がめちゃめちゃ良い。

扱っているのが、「命名」、「条件分岐」、「データクラス」の三つのテーマ、順番で簡潔に悪いコードの例を示していて、まず最初が命名の問題を扱っているのが良くて、それは命名の不味さは誰に説明してもその問題が分かり易いけど、条件分岐や、データクラスは、コードの構造の問題は概念的な話なので少し考えないと納得感につながりづらいから。

命名は「実際のコードと照らし合わせて明らかにおかしい」と言いづらいので、まず命名の話が来ているのが具体的で入り易い。

で、次に複雑すぎる条件分岐の問題が出てくる...たぶん、プロダクションコードで経験する様々な「困る」のうち、この2つでかなりの割合を占めていると思われるので、その実感と合っているし、その背景としてデータクラスのような「構造の不味さ」が有ったりする。コードを読み始めて、命名のおかしさに気づき、構造のおかしさに戸惑った次に来るのは、データクラスのような「そもそもの構造、ソフトウェアアーキテクチャ設計」に起因していたりするから、この3つ、この順番で説明しているのが凄く納得感がある。そりゃほかのも大事だけど、この3つ、この順番に意味がある。

非常に内容が多岐に渡るので、個人的には読む順番としては第1章→第2章→第10章→第6章あたりをみっちり読み込むといいかなと感じました。すぐに改善できるところと、チームとして、組織としてどう変えていくのか、コンセンサスを得なければ進められないところが有ると思うので（チームで一人だけ勝手にオレオレルールを持ち込んではいけないので）、手をつけ易いかなと。

という訳で全編、学びしかない良書なので、とにかくいますぐ本屋に買いにいきましょう。

それに、なんか最近こんなに技術書がバーンと話題になることも少ないし、みんな本屋行って、積まれているところを見て、買うといいじゃないですか、お祭り感有って。

今年の技術書の豊作っぷりはすごいですね。どれも10年は内容が持つ、お買い得な本だな、という印象です。

blog.magnolia.tech

blog.magnolia.tech

blog.magnolia.tech

良い技術書は、書いてある内容をそのまま理解して実践する以上に、共通の語彙として同じ価値観／目線で会話をするために利用するものなので、1回読んで終わり、じゃないんですよね。