はてなブックマーク

学力喪失──認知科学による回復への道筋（今井むつみ著）という本を読んで、いくつか私にとっての重要な課題が整理されたので、それを記します。『学力喪失』の本の内容も含まれますが、それ以上に私自身の考えていること・課題の方に焦点があり、単なる感想記事ではないのでご注意ください。 ※この本は非常に良い本なので、ぜひ買って読みましょう。 ※noteの同名記事からの移植です。 学ぶ力が失われるメカニズム 『学力喪失』では、いわゆるテストの点数・偏差値で定まる学力ではなく、人間が「生きた知識」を自分の中に蓄積していく力＝学ぶ力、およびその知識が実際に蓄積されているかという事を重要な関心事としており、以下のような話題を展開しています。 乳幼児には学ぶ力があるのに、大人になるにつれて学ぶ力が失われているのではないか？（例えば、学習性無気力を引き起こしているのではないか？）という問題提起 例えば点数に対する過

あらすじ 徹夜明けの深夜テンションで書いた怪文書が思いの外多くの人の目に止まったようなので、実際にどういうコードが汚くて、どう改善できるのか、みたいな事を簡単にまとめてみる。 モジュール・クラス・変数の名前がおかしい 名前から全く想定できない作用がある、名前が嘘 例えば、validateForm()という名前のメソッドを実行すると、決済処理が完了してレシートが印字されるとケース。おまえはvalidationではない。でもvalidationなので、DBには保存しない。 （何を言っているんだ？？？ちなみに、外部APIやデバイスのコールはこのメソッドの中でできてしまうが、フレームワーク制約でDB更新はここではできない、みたいな状況でそういう事が起こる） const blue = "#ff0000"、おまえは青色ではない。真っ赤なウソだ。 これは、しばしば致命的なバグにつながる。既存のblueを

汚いコードはよくない （2024.9.22 追記：続編を具体的にかきました！） コードを書くと、コードは増える プログラムは、ソースコードと呼ばれる文字列を記述する事で作成されます。このことを、単にプログラムを書く、コードを書く、などと言ったりします。 ほとんどの場合、プログラムを書くときには、その目的があります。 なにかの目的を達成するために、ソースコードと呼ばれる文字列を記述します。 この記述方法にはいろいろなものがあり、同じ目的を達成するにも無数の方法が存在します。 どの方法を選ぶかは作者に任されている、という言い方もできます。 ところで、ソースコードを記述していき、プログラムで実現できる事が細かくなるにつれて、文字の数はだんだんと増えていきます。 コードの増え方にもいろいろある この文字が増えていく様子を比喩的に表現することを考えます。例えば書類を積み上げることや、積み木を積み上げ

あるサービスがローンチから5年経過し、10万行のソースコード、開発メンバー50名の体制でメンテする、という話をツイッターで見かけました。ソースコードには、神クラスが含まれるとか、含まれないとか。 ソースコードの桁を間違えちゃったのかな、と思うのですが、10万行・100万行の場合について、それぞれ私だったらどういう戦略で修正するか、を考えてみます。この戦略は、自分がメンバークラスでもリーダークラスでも有効です。 前提：恵まれたビジネス このサービスには、50名でメンテする価値があるという事になります。一般論として、5年経過したサービスを50名体制で開発をするとしたら、それは損切りをクリアして50名でペイすると判断をされて開発しているということなので、そのサービスが生み出す売上はそこそこの額であると考えられます。 世の中には開発だけで成立するサービスもあると思いますが、神クラスが出来ているとか

私が個人的に0→1や1→10のフェーズで知っていて得をした（と感じた）ことをまとめます。 なんかひたすらMPと連呼する変なおじさんになってしまった 精神的・感情的な疲弊をさける、MPを大事にする 0→1や1→10で結果に大きく影響する支配的な要素として、"体力"ないし"スタミナ"と呼ばれるような、行動力的な要素があります。しかし、この行動力の本質というのは、私が思うには、筋力とか身体的な体力(?)というよりは、精神力的なものです。つまり、主観的に楽しければ/充実していれば（そして若ければ？）、まあ体力の限界が来ても寝たら復活できるのですが、主観的に悩み事が多かったり、ハードな判断あるいはハードでないけど微妙に難しい判断みたいなものを大量にやっていると、精神力みたいなものが枯渇してすぐに動けなくなります。 組織が整っていない場合、言い換えると定型業務が決まりきっていない場合、あらゆる物事につ

この記事は、↓の記事の続きです。 前の記事では、個人差に基づいて給与を支払うべきなのかという事にフォーカスを当てていたのですが、この記事では、開発チームがどのようなメカニズムで効果的に機能するかという事を考えていきます。 要約をすると...作業の速さと知の2つの概念を分離した上で、チームにおいては必ずしも個人の作業量だけが貢献ではないことを示し、知がどのように蓄えられるものか、どういった性質を持つかという仮説について述べます。そのような知の蓄積については、個人に還元して考えることにはあまり本質がなく、チームとして機能する状態を作るのが重要で、その意味で作業量（だけ）を全てとする"成果主義"では部分最適になってしまう、という事が一つの結論です。この知の蓄積は「森」のメンタルモデルで表現でき、事業やチームを拡大していく場合はどこかで「森」を作るという戦略に切り替えていく必要があります。 という

まえおき（本題と関係ありません） 最近、エンジニアとビジネスという謎の話題が流行っています。 エンジニアとビジネスということについては、私は次のように思っています。 仕事には役割分担があるので、エンジニアの人は必ずしも利益最適化を考えなくてもよい 下手の考え休むに似たり、餅は餅屋 ただし、自分で考えないとすればそれは委任であって、結論に従う義務がある もし自分で考えたとしても、チームや会社の結論は個人の意見と関係なく是とすべき 法律や道徳的信念に反する場合は別 また、ゼロベースで考えることはしなくても、出た結論について誰かがエンジニアリング観点で再設計・最適化することは実装上必要 ただし、私個人に関しては、プログラムを書くにあたって利益構造を理解しないという事は考えられない 例えば、サービスとしてある機能を作るべきか否かの判断の大きな部分は本質的な利益構造に基づく 技術的負債を返済すべきか

「プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ」という本がとても売れているようです。タイトルが若干引っかかりつつ、各所で褒める言葉を見かけたので私も購入して一通り読んでみました。 プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ(amazon) これはめちゃくちゃいい。 私が考えてきた事との類似性、新しい考え方、チーム戦略、全てにおいて示唆がありました。プログラミングに関する書籍としては、これまで読んだ本の中で一番ためになったように感じていて、実際にすぐに行動に反映されるような内容も多々ありました。 そこで、この本から特に感銘を受けた内容と、一部はそこから発展させた私の考えについて述べます。 （ちなみになぜ自分の考えを述べるのかという事については、この本に紹介されている意味波の考え方でその意義を説明できるので、後述します。） この本は

恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま

概要 みなさんは「フロー効率」や「リソース効率」という言葉を聞いたことはありますか？ 最近、アジャイル開発やソフトウェア開発の文脈において、「リソース効率よりもフロー効率を重視すべき」といったニュアンスのコメントを見かける場合があります。このコメント自体は必ずしも間違いではないのですが、このコメントをふわっと解釈して、実態と異なる理解や説明が為されているのを見かけます。 そこで、この記事ではそうした誤解がなくなるようにフロー効率について説明をしていきます。 結局何をすればいいのか、端的に言うと フロー効率の概念を踏まえて結局どうすればよいのか？という事ですが、簡単にまとめると以下のようになります。 ソフトウェアはデプロイされた時点から顧客に価値を提供するようになるので、他にしがらみが無ければフロー効率を上げた方がよい アジャイル開発の文脈で、フロー効率とリソース効率は多くの場合トレードオフ

先日、 という記事を書いたところ、思ったよりも反響がありました。その影響があったかは不明ですが、また値オブジェクトについての話題がちょびちょびと発生していました。 そのやり取りの中で、私は未読だった論文が紹介されていて、その論文を読んだことで「このようにすると値オブジェクトに誤解が生じる」という一つのストーリーを認知できたため、どのようにこの論文を読むと誤解が発生するか、という事について説明します。 なお、前回書いた記事も、この記事も、誤りを糾弾したいとか、誤ったから著者が悪であるといった事を主張しているわけではありませんので、改めて記しておきます。この記事では、単純に事実の指摘と修正の提案、およびなぜ文脈や定義を大事にする必要があるのかという事について述べます。 いい加減、値オブジェクトの話題はしつこすぎるのでは？非生産的なのでは？そんな事よりもっと生産的な事をしたら？というご意見もある

「良いコード／悪いコードで学ぶ設計入門」という本がとても売れているようです。私の所属している開発チームでも、何人か購入した人がいたので、私も購入して一通り読んでみました。 結果として、いくつかの考えが整理され、私としてはこの本によって考えが深まり、本を読んで考えた事自体は有意義であったと思いました。ただし一方で、あまり知識がない状態で（自分の中での判断軸が無い状態で）この本を読むと、色々と誤解が生まれるのではないか？という事を感じました。 一つの技術書がこれだけ売れるという事はそんなに多くはない事だと思うので、つまり、 その内容が改善されるとその効果は相対的に大きい という事になります。そこで、私が本を読んでいて思ったことや、この本の内容で正しいこと、現在も賛否両論とされること、事実として認識が間違っているであろうこと、この本で触れられていないが設計において大事なこと、などについてまとめて

Twitterで適当に垂れ流した感想が、（私のTwitter力のなさにより）スレッド分断されて散り散りになっているので、一旦こちらにまとめる。おそらく最も重要なValue Object / Domain Primitiveの混乱については末尾に記載している。 このスクラップは、別途語尾を調整するなどして記事にする予定。その際のタイトルは良いコード／悪いコードで学ぶ設計入門の感想と改善点（仮） 最終的な記事はこちら↓ 良いコード／悪いコードで学ぶ設計入門の感想と注意点 命名スタイルについて いろんな命名が出てくるが、これがオリジナルなのか一般的なのかはもうちょっとあっても良い気がする。ただ、数学書も引用付きで示していなければオリジナルかどうかを厳密に判定する方法はない気がするので、めくじら立てなくても案件かもしれないが。 データクラスについて ストラクチャー（構造体）にやたら否定的な感じを受

※noteにも同じ記事がありますが、Zennの方がユーザ層とあっているかも？と思い書き直しています。 （2021/4の追記） 末尾に重要な追記があるので、追記をよんでください〜 （2022/8/11の追記） 実際に模擬面接活動を見て、対話して思ったことを追記しました はじめに 競技プログラミング界隈で、"怪文書"が流行っています。 この文書の誤読がリトマス試験紙になる... 正しいけど絶望的な状況について、なんだろう、感情を揺り動かされてしまい、その状況をもう少しお互いにわかるようにするための「解説」をするためのものです。とにかく"誤読"というか、相互で見えない立場が気になってしまった。それに尽きます。 はじめに、どういうスタンスで自分がこの記事を書いているか？という事を示しておきます。 chokudai氏は、頂上じゃないところにも価値があるという事をきちんと思っていて、「（当人を含めて）