Continuous Modeling - Fly me to the Luna
みなさまご無沙汰しております。僕はここの所、残業はしないまでも毎日クタクタになるほど忙しい毎日を過ごしています。どんな仕事か一言でいうと、あるプロダクトのアーキテクチャを刷新するお仕事です。今までできなかったあれやこれやを実現するために、既存のアーキテクチャを改善したり、作りなおすお仕事です。今はまだ始まったばかりで、方針を決めるために、既存のアーキテクチャ上に機能拡張してみて問題点を調査したり、どう改善するのか方針案を考えたり、実際に改善案を少しずつやってみたりしています。 このプロジェクトは、それほど大所帯ではないですが、他の会社のエンジニアさんも加わるなど、結構スキルセットがバラバラです。そのため、久しぶりにペアプロで作業を回しています。1日じゅうペアプロすると、一日の終わりの頃には頭がクタクタです。久しぶりです、この感覚。楽しい。 さて、既存のアーキテクチャを見ていくと、10年以上
普通のアプリケーションのコードに関数定義と関数適用とリテラル以外を書いてはいけない - 標高+1m
underscore-fix とか Pastaとかを仕事で使ってみていたら、前から薄々感じていた事に確信を持った。 ライブラリが十分に強力なら、プログラム中に関数定義、関数適用とリテラル以外は出てこない。そして逆に、forやifやswitchやnewが必要になったら、その関数は一般化してライブラリに押しやらなくてはいけない。 On Lispだかなんだかのボトムアップデザインの説明で、「アプリケーションを書くための言語を作って、その言語でアプリケーションを書く」みたいな文章を読んだ記憶があるけど、この「言語」っていうのは、別にDSLである必要もLispマクロである必要もなくて、「ライブラリ」って意味と取って問題なくて、それならLisp以外の言語でもこの考え方は重要になる。自分のライブラリが十分に成熟するまでは、なにかアプリケーションを作る度にライブラリ関数を増やすつもりでやらなくちゃいけない
プログラミング原則一覧 - Strategic Choice
見つけた時に逐次エントリしている「プログラミング原則」カテゴリの一覧です。不定期に追加しています。プログラミング一般デメテルの法則DRY原則YAGNIKISS原則OAOOUNIX哲学可逆性曳光弾直交性契約による設計 DbCプログラマの三大美徳PIEの原則SLAPパフォーマンスチューニングの格言驚き最小の原則オブジェクト指向プログラミングパルナスの規則抽象データ型サブタイプ求めるな、命じよコマンドとクエリ分離原則オブジェクト指向設計パターン言語生成・使用分離の原則パターンの定義IOP
設計書論争での独り言 - うさぎ組
重要な事 これは僕の経験に基づくものであり、世の一般的な皆々様にはあてはまるかどうかは存じ上げません。 僕がマイノリティかマジョリティかどうかはよくって、こういう状況もあるというだけです。ツッコミは大歓迎ですが「それはコーナーケース過ぎる」というご意見には「そうかもしれませんね。」としか答えようがありません。 あと、基本的に@otfに向けた記事なので、言葉足りていない部分が多いと思いますが、彼とは職場が一緒でいろいろ共有できるので気にしていません。皆さんには言葉足りていなくってすいません。という謝りはすれども、反省はしない程度の感じ。 追記>> 言いたい事書いてなかった。 ただし、 設計書否定するなら、ここにある事くらい論破するくらいの人じゃないと一緒に仕事したくない。逆に、ここに同意するくらいなら設計書否定すんなよ。自分の仕事を呪え。 と思ってる。 <<追記 ではちょいちょいカテゴリ分け
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計の話
