Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

プログラミング

ioctl のつくり方

Linux ドライバで、ioctl をつくっている。ハマったところ。・コマンドは _IO、_IOW、_IOR、_IOWR の用意されたマクロを使ってつくる。 単なるユニーク値でいいんだろー、と思ってやってたら、思わぬところでつまづいた。 前述のマクロを使わないでいたら、 …

デバッグではコードを読みすぎてはいけない

結果を見よ。特にレジスタの中身は。 セットしたからといって、セットされてるとは限らない。 セットする手順が決まっていたり。プロテクトがかかっていたり。 コントロールレジスタにセットしたことがステータスレジスタにちゃんと反映されているか、とか。…

An interview with Uncle Bob on "Clean Agile"

www.youtube.com 私の頭の中でずっとここ数年炎上している課題は、 ソフトウェアのプロフェッショナリズム(職業感)についてだ。 (中略) だって、この社会はソフトウェアなしにはもはや成り立たない。 (中略) でも、ソフトウェアはきれいに書かれてはい…

「質v.s.スピード」という概念は根本的に間違っている

"「質v.s.スピード」という概念は根本的に間違っている" "質v.s.スピードという二律背反の関係は、局所的なものでしかない。大域的には、片方を犠牲にした場合、知らぬうちにもう一つも犠牲にしている" https://t.co/jfZK5juCU6— Takuto Wada (@t_wada) Febr…

やっぱりコードにふれてないと

以前にも書いたと思うけど。 やっぱりコードにふれていないと。情報量が違う。 どんなふうなつくりになってて、品質がどの程度で(ざくっと傾向でいいので)、 どんな感じで動いてて、ここまでは大丈夫で、など。 状況がある程度わかっていたら、 お客さんと…

コメントも「抽象度」なのだ

qiita.com例年この時期には、新入社員が入ってきて 「コメント書きなさいよー」って話をするわけですが、でも そのうちなれてきたら、 「コメントなくても読めるコードを書けよー」と言いたいです! 最初のうちは "コードを説明するためのコメント" を書いて…

プログラム設計は「名前」と「場所」

うまく名前をつけることは、「究極の設計」ではある(と私は思う)けれど。 ここではもっとカンタンなお話として。 (上位の)設計書からそのまま名前を引用しようとすると、 コードにうまくマッチしないときがある。 なぜならば、設計書に書かれるものは「…

そうだ、写経を始めよう!

新しい言語をおぼえるときの、参考書の選び方がいつも難しい。 もう長いこと、この業界で仕事してるわけだし、 いまさら、クラスがどうだ、データ型がどうだ、ってところから書いてあっても 読まないムダなページなわけである。 そのために分厚いごっつい本…

あらためてモブプログラミング

takaking22.com 基調講演の話の内容が詳しく書いてある。サンキュー! モブプログラミングはどうすれば一つのチームが一緒に効率よく働くことができるかということを探求する過程で発展してきました。一旦始めてみると、我々はモブプログラミングが次のよう…

コピペやめようよ ~ちゃんとしたコードを書く文化とは~

「ちゃんと」という言葉をよく使う。 今回も、「美しく」とか「きれいな」とか使ってみようかと思ったけども やっぱりしっくりこなかったので。 さて。 ちゃんとしたコード書きたいと思うし、ちゃんとしたコードで書いてほしいと思う。 でも、もしかしたら、…

コメントがいるってことは、プログラムが文章になりきっていない、ということだ

なんでもかんでもコメント書けばいいわけじゃない。 見ればわかるじゃん、ていうことまで書く必要はない。 でもそのさじ加減は、少し経験を積まないと、わからない。 それは言葉にしてもなかなか伝わらない、・・・ように思える。 コメントがいるってことは…

プログラマには想像力が必要だ(仮)

まだうまく「キーワード」化できていないのだけど、 消える前に書き残しておく。 そのうち整理して、ちゃんと言語化したい。ノウハウや観点にしたい。 デバッグのコツ。というか「やり方」。 もっと言えば「プログラミングという行為」について。 推察せよ、…

「なぜそうなのか」が答えられるか

設計とは、 「なぜそうなのか」の理由付け・意味付けになるもの、だと思う。だから、自分のコードに対して 「なぜそうなのか」が答えられないようでは、プログラマとは言えないと思う。 そこに意思はあるのか?と思う。ただ単に動くものが作れるだけで、それ…

いつものことだけど

ひさしぶりにコードを書いている。 当初思ってたより時間がかかってて。思うようにいかないなーと思うと、そこばっかりを一生懸命やってしまう。 なんどもなんども試してみて、うまくいったりいかなかったりを繰り返している。手を休めて「さぁどうしようか…

ペアプロは劇薬

codezine.jp ちょー良記事です! 単にペアプロの導入事例というだけでなく、 品質と開発手法のこと等、いろいろ考えさせてくれます。それから、何かを変えていくのには、たいへんはパワーがいることだと改めて思いました。 でもそのくらいでやらないと、何も…

メロンパンと五拾の手習とナットクできないこと

www.facebook.com メロンパンにはメロンクリームが入っている、と叫びたい! 私は通称メロンパンを「コッペパン」と呼ぶ文化圏で育ちました。 こっちきて、関西だから言い方違うのかなー、くらいにしか思ってなかったんだけど。さて、組込みのお仕事が長く続…

書こうとしなければわからない ~プログラミングとは何か~

設計時は、システムを俯瞰的に見ており、 大きなふるまいのほうに目が行きがちである。 そして、コードになるときの姿を思い描きながら設計するのは、 かなり粒度が小さくなってからだ。しかしそれでも、実際にプログラムに落とし込むのとは違うのだ。コード…

関数のつくりかた

関数をつくるということは、 システムの中の/世の中の「こと」「もの」をどう捉えてどう表すか、ということだ。処理の複雑さ・煩雑さや、量の多少ではなくて、 抽象度のレベルや粒度を変えながらものごとをとらえて考えよう、ということだ。大きくとらえて…

分岐を減らそう!

ときどき、すごくややこしい if 文に出会うときがある。 たくさん if があるんだけど、よく見ると、else 側の処理は同じようなことばかり書いてあったりして、「これ、ちゃんと整理してまとめれば、すっきりするんじゃない?」みたいなの。 確かに間違いでは…

仕様書とコードの大事な関係

仕様書に書いてあることは、そのままコードに落としたい。そのためにも、仕様書とコードを1対1で対応させたい、と思う。つまりは、「仕様書のここは、このクラス/モジュールに書いてあります」としておきたい。そして、その中身は、 「2-3章の機能は、こ…

コードを減らそう!

「似たような処理だから」とコピペするのではなく、 同じところはどこなのか、違うとこはどこなのかよく見て、 それから、データとロジックを分けて見る見方ができれば、 コードの共通化と、差分の持たせる方法が見つかるはずだ。 そしてこれはオブジェクト…

共同所有とコーディング規約

さて。先日のアジャイルラジオの感想です。まずは共同所有のこと。正直、ひとのコードを積極的に「さわる」ことはないです。 コードが見れる環境にあるし、コードレビューもするけど、 「直す」「変える」のは抵抗あるな、と思う。こういうことをすることに…