【感想】Kanasan.JS prototype.js CodeReading#4
Kanasan.JS prototype.js CodeReading#4へ行ってきた。
今日はわずか13人だけ。
歩く仕様書のnanto_vi先生もおらず、正直物足りない面もあったけれど、ソース解読そのものは結構面白かった。
今日コードリーディングしたprototype.jsのL1652~L2472 は、ブラウザ依存やCSS依存の部分を汎用的に使えるように苦労している所。
IEはバグそのものが多いのか、ラップしたり、苦労している部分が多い。
FireFoxもVer1.8.0のみ特別な処理がある。
Safariは、バグFixしたプログラマが丁寧なのか、コメントしてくれて親切。
それらのソースは、正直綺麗じゃない。
たくさんの人の手が入ったのだろう、コーディングルールが徹底されておらず、インデントや変数名に統一性がない。
okkezさん曰く「バグレポート駆動」なのでしょう、と。
つまり、 バグレポートが上がるたびに、各人が勝手にバグFixして積み重ねたソースなのだ、と。
この状態は、システム開発の結合テスト以降のフェーズに似ている。
仕様書に従ってプログラミングしても、結合テストやシステムテストで、たくさんのバグ修正や仕様変更に伴って、プログラムは本来のあるべき綺麗な構造から少しずつズレていく。
一度、バグ修正したソースへ再び手を入れるのは、誰もが嫌がる。
今日コードリーディングしたprototype.jsも同じように思える。
実際のソースはそんなに綺麗じゃない。
でも、ブラウザやCSSにも依存しないように汎用的なライブラリにしてくれているので、AjaxのようなリッチUIを実装できる。
以前、lapis25さんが、フレームワークの内部のプログラムは、どう書いてもやっぱり汚い部分が残るんですよ、と言っていたのを思い出す。
汎用的で使いやすいライブラリを作るための泥臭いプログラミング。
それも、プログラミングの一側面。
| 固定リンク
「プログラミング」カテゴリの記事
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- 値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口(2021.07.23)
「コミュニティ」カテゴリの記事
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 『ものづくりの数学』の感想 #もの数(2022.04.10)
- RedmineJapan vol.2が開催されました #RedmineJapan(2022.02.25)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
- なぜソフトウエア後進国の日本でRubyは成功したのか?~ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある(2021.11.09)
コメント