記事一覧
コードの共通化、再利用という言葉の捉え方
久しぶりにnoteに書きます
・想像の共通化
共通なコードが一つにまとまる
二つのコードが有れば、共通化で総量は半分になる
・実際の共通化
共通なコードと、それぞれの個別機能が渾然一体となる
二つのコードが有れば、共通化で総量は2割くらい減って、密結合により複雑度は5割増しになる
また、未来の機能追加で個別コードが増え続ける
・想像の再利用
元の品質が担保されたコードをそのまま使うので、工数
技術書だけを読んでも何も分からない
一人で技術書を読むときに陥りがちなんだけど、そのソフトウェアの持つ独特の箱庭感みたいなのが有ると思っていて、技術書に書かれていることは（前提のバージョンとかが変わっていない限り）、まぁ動いてしまう。
そして、動いて、「やったー」と思った先に、「で、次に何をやるの？やりたいことってあるの？こんな面倒くさいをことを続けるの？」というフェーズがやってきて、なかなか先に進まない、ということが有って。
技術書は寝かせてから、また読むとよい
特に設計思想的な話は、自分の経験によってどんどん見え方が変わるから同じ本でも何度も読み直した方がいい。
本を理解するのではなく、本をきっかけに自分の考えを整理するのが目的だからね。
ドメイン知識は、容易に失われる
コードがドメイン知識を表現するように書かれるべき、という話と、全体を疎結合にして拡張性や保守性を担保しましょう、という話、完全には両立はしないと思っていて、だってビジネス側の人はそんな拡張性とか保守性の話していなくね？
で、実際のコードを見たら、考えたこともない保守性や拡張性のための抽象化が行われていて、上から読んでもよく分からん、みたいなこと、発生していない？
そうでなくても冒頭の、ちょっと
コードと、業務のレア度
コードに色は無いけど、人間はそこにレア度による優先順位を見出していて、「そこはめったに通らないルート」「ここはめったに通らないけど、バグが有ると死ぬルート」「ここが通るかはDBの調査が必要」「これが発生したら100年に一度の事件」みたいな層別を行っている。
ただ、それは後世の人は容易に区別することはできないので、全部同じ粒度、同じ優先度で必要！と思ってしまうんだけど、案外「一回も使われていない」
設計がいつも可視化されているとは、限らない
意識的に意思決定されたことでなくても、そこに設計が有るんだ、暗黙知として。
設計書になにはなにが書かれているべきか？
設計書になにが書かれているべきか、コードの世界と違ってあまりコンセンサスが得られた回答を見たことが無い気がする。
かなり大きめの書店に行っても、「リーダブルコード」に代表される”良いコードの書き方”はかなりプラクティスとしてまとまってきている一方で、”良い設計書の書き方”みたいな本はほとんど見かけない(ごくたまに見かけるけど…それほど印象に残るものは…無かった気がする)。
なぜだろう…と思った
コードとビジネスの距離は近いのか、遠いのか
「コードとビジネスの距離」というテーマで焼肉5回食べれるくらい語るためには、どんなことが話せそうか考えてみた。
・コードはビジネスの写像であるか？または、そうあるべきか？
・コードとビジネスは相互に影響を及ぼす、という現象
・エンドユーザーコンピューティングについて
・コードからビジネスに近づくアプローチと、ビジネスからコードへ近づくアプローチ
・コードと、データと、運用と
お腹いっぱいになれ
ビジネスとコードの関心の非対称性
コードの8割は例外への対応だったりする一方で、ビジネス側の人は実現したい業務の主たる内容に関心がある。
一方でコード自体に、王道ルートも例外ルートの色分けは無く(ユースケース図で言うところの基本ルートと、代替ルートは有るけど)、等しくロジックとして実装しなければいけない。テストの密度を変える、みたいな話はあるかもしれないけど、王道ルートだろうが例外ルートだろうが、必要なロジックに合わせてコードを
コードの意味、意図を読み取る
シンタックスハイライトは、コードに対して文法に応じた色づけをしてくれる点で画期的な発明なのだけど、残念ながらコードの“意味”や、”意図”までは表示してくれない。
ロジックの順序や、スコープの切り方で意味や意図を見いだしやすくすることはできるし、コメントや変数名、メソッド名に直接的にそれを込めることは、できる。
だけど、最終的には意図を見いだすのは人間側だし、その時点で読み取りたい内容は異なって
知りたいことが有れば、勉強会を開いてみるといい…いや知らないから開いてみるといい
吉祥寺.pmという勉強会をここ6年ほど運営している。
「地域名」＋「pm」という形式の勉強会は、昔はたくさん開催されていて、主にPerlの話題を扱う勉強会、という意味になる。つまり、吉祥寺.pmは、吉祥寺で開催されるPerlの勉強会、という意味になる、本来は。
トーク15分、LT5分で、だいたい10件ほどの登壇枠を用意しているけど、最近はPerlの話題は1件〜2件になっていて（まだ有るのか
プログラミングが上達するコツ
最後も、独習する上では、割とシリアスな問題ですが…とりあえず本だけ読んでいても全然上達しないですよね。
最初は写経でもいいと思うんですけど、写経する時に絶対にタイプミスとかでエラーメッセージが出ると思います。その時に、エラーメッセージをちゃんと読んで、意味を調べて…っていう行為を最初の時点でしっかりやると、その後の上達が全然違うんじゃないかなって思います。
本当に全然意味不明なエラーメッセージ
技術書の読み方も、難しい
市販の技術書、薄めの本でも少なくとも200ページくらいは有って、「これを全部読むのか？」という気になる。分厚いと、1000ページ超え、上下巻で2000ページ超え…みたいなものも有って、これを頭から読み続けるのは容易なことではないです。
独学で技術を学ぶ時に、まずこの厚さの心理的な壁って有りますよね？
最近は技術書典などの技術同人誌の盛り上がりで、所謂「薄い本」もたくさんけど、一般の人がいきなり
プログラミングを難しくする要素って何だろう
プログラミングは難しい…たぶん。
オブジェクト指向プログラミング、関数型プログラミング、アジャイル開発手法、各種設計原則や、テスティングフレームワークを使ったTDD等々…色々なプログラミングを支える要素技術はここ10年で爆発的に進化して、「とりあえず動くものを作る」という段階から、「先を見据えて、ずっと維持できるものを作る」という段階に変わってきたように思える。
きっとそれはシステムが動く環境
もう「自動化」って言わなくてよくないですか
なんとなく、「自動化」って言葉のニュアンス、“今の状態にわざわざ苦労して付け加えてやること”みたいな、特別感出していませんか。
それより、わざわざ”手作業”でやる方を「手動化」って言った方が、よくないですか？
「え？それ手動化でやるんですか、まだまだ人間じゃないと判断できない価値が有る作業なんですねー」みたいに。
どっちを特別視するか？って時に、より「当たり前の方」にはわざわざ名前つけないで
誰かが一歩を踏み出すきっかけを作る
吉祥寺.pmというイベントを運営しています、Magnoliaと言います。先日、2019/1/26にYAPC::Tokyoというイベントに出て、色んな話を聞いてふと思い出したこと、思ったことを書きます。Twitterに書くには長すぎたので、初めてnoteに書いてみました。
振り返ってみると、Perlを書いたり、IT勉強会に出席したり、OSSにコミットしたり、自分で勉強会を開催したり、雑誌の記事を執