  |
はてなキーワード: ユニットテストとは
○朝食：なし
○昼食：ぶたのごはん
○間食：柿の種
○調子
今日は、真面目に受け止めきれないことがあった。
まずはもうすでに書いていた仕事の話を切りのいいところまで書いてから、それの話を書く。
ただ、自分の中でそれを受け止めきれていないので、まずはいつかこの日記を読み返した時に振り返られるよう、書くだけ。
今日はそれだけ。
仕事で「ユニットテストコードを書くことの是非」みたいな、よくある議論になった。
議論相手の「俺は今までそんなことしているプロジェクトを見たことないし、これからもそれが多勢派になるとは思わないから、やらなくていい」という論に、割と真面目にぐうの音が出なかった。
いやこれって、もうこの論で話されると返しようがない。
これがはてなブックマークの世界だったら歴戦の先輩方からのブコメの数で圧をかけられるのだけど、現実ではどうしょうもなかった。
倒れて病院に運ばれたらしい。
生きるか死ぬかの話題ではないものの、緊急治療室に入って大変なことになっているそうだ。
お見舞いというか、面会に行った方いいのだろうけど
○ポケダン青
とはいってもこれ、レベル上げが不要なポケモンを進化の手続きしただけで、プレイ時間は五分ほど。
●iOS
○グラブル
日課をこなしただけ。
トラバでアドバイスをもらったので、このコーナーは楽しいことだけを書くことにします。
なので、仕事にちゃんと行く、みたいな自分の中で重いことは今後やめておき、コーナー名も「明日やりたいこと」から「明日やりたい楽しいこと」とします。
OK・2.グラブル：島H、マグナ（火、闇、光）、討滅戦マニアック二週、共闘デイリー、イベントデイリーをこなす
上の事情があるので、さすがに仕方ない
正直、ちょっとそういう気分じゃないわ
ユニットテスト書きすぎじゃない？って話です
http://kenn.hatenablog.com/entry/2014/01/03/095026
今はこのブログで言ってることがその通りだと感じる場面が多い
スマホアプリの開発現場では、MVVMやクリーンアーキテクチャと言った手法を用いて
Viewのロジックに近い部分までユニットテストしようというのが主流になっている
この空気感では最早テストを書くのはやめよう！という人は居ない
テストを書いたほうがいいか、書かなくてもいいか、迷うくらいなら書けという感じ
その結果、仮にバグが有ったところで大して痛くもないところまで緻密なテストが書かれ
コード量は爆増し、開発速度ははっきりと低下している
テストを書いておいたほうが結果的にリリースまで早くなる箇所もあると思うが
テスト礼賛の現状、よっぽど強い意志を持っていたり強い権限を持っていないと
そうでないところまでテストを緻密に書く流れにどうしてもなってしまう
もうAppleの審査も昔のように一週間もかかったりしないんだから
ツイッターやブログは仕事関係の人も読んでいるので、ここで書く。ちょっとした事情でUターンして、とある地方のしがないWEB屋で働き始めたのだけれど、半年経って、もうこれは限界かもな、と思っている。
社員が少ないし時間がないのもわかるのだが、コードレビューがあることによって、バグやコード書いた人の目に届かない部分の影響への指摘などができると思うのだ。
フロントは状態管理が大変なので、限界があると思うんだけど、バックエンドはテストコード書いて、ユニットテストくらいはやろうぜ、と思っている。まあ、自分も以前まではやっていなかったので人のこと言えないのだけれど。
何をやっているのかわからん上にダマで変更加えてmasterにマージしちゃう。しかも変更しているのはモデル。もちろんテストはしないぜ。masterからブランチ切って自分の作業に取り掛かってみると、知らない変更が加えられている。影響範囲なにそれ美味しいの？状態なため、変更に伴って他の部分/モジュールにはバグ出まくり。テストコードはコケまくり、エラーでまくり。
これを誰がやっているかと言うと、上司にあたる人間がやっている。ちゃんと技術的な知識も持っているしコードもちゃんと書ける。自分よりも。なので余計にタチが悪い。一人で開発するんならそれでいいのかもしれないけど。ちなみにバックエンドのエンジニアはその上司と自分だけ。
働き始めて2年も経たないペーペーだし、年も離れているし、どういうアプローチをすればいいかわからないんだよね。職場の文化(?)を変えるのはそれなりの労力がいるし、とっとと転職して自分の環境を変えた方がいいかもな、と思っているけど、如何せん地方なので、あんまり職がない。
ってやっぱり『価値のあるものを作りやすい』ところにあると思うんだよね
システム開発会社で働いているとシステム開発って本当に金がかかると感じる。
市のHPにあるクソみたいな検索システムとかでも云千万単位の金がかかってることなんてザラにあって、
なんでそんなにお金がかかるかっていうとプログラミング作業以外のコストがでかいからなんだよね。
システム会社がシステムを作りたい人からどんなシステムを作りたいのか聞き出すのにもかなりの予算がかかるし
それを資料として落とすのにも、それが全体に共有されるのにだって予算がかかる。
設計が終わっても自分用の便利アプリを作るのとはわけが違って品質を保証するために
テスト仕様書を書いて、ユニットテストを書いて、他機能に変な影響を及ぼさないか調査して、
コード書いてる時間よりその周辺の作業の方が時間がかかったりする。
会議なんて始めてしまえばもう最悪で、給料×参加人数×時間分の予算がかかるし、
勿論それらには僕達労働者の有給休暇分や社会保障費分も含まれてしまう。
最終的な見積もりを出す頃には「なんでこんなしょぼいシステム作るのにこんだけ金がかかるんだよ」
例えばJaneStyleや2chMateを代表とする２ちゃんねるブラウザ、
アレなんか長年に渡り積み重なったユーザーの要望が集約されてるから機能数はかなり膨大で、
これをそこらのシステム会社に作ってくれとお願いすると恐らく数億どころじゃ済まなくなるはずだ。
でも、これらは実際に数億円かけて開発されたわけではない。
規模は個人か多くても数人で、予算だって開発者のモチベーションが予算という感じで
数億円どころかむしろ0円に近いはずだ。
例えばこれを建設業界に例えてみよう。数億といったらもう豪邸だ。
「そこらの会社にお願いしたら数億円かかる豪邸を大学の友達3人で集まって作りたい。
僕達バイトしてないから予算は1万円。お金はないけどやる気だけはあります。」
なんて言ったら「アホか」で一蹴されるだけだし、どう考えても現実的じゃない。
でも、IT業界に限ってはこれは十分現実的に考えられる話だし、そういう例は実際に何個もある。
まず企画設計開発全部自分な個人開発ならコミュニケーションコストが0に等しいし、
技術力がある人だけで集まれば一番開発効率の良い技術を好きなように採用できる。
『数億円の価値があるものを自分で生み出せる』なんかロマンがあるじゃない。
数億円の価値があるものを生み出せるスキルがあれば、アイディアさえ良ければ一攫千金も狙えるかもしれない。
なんか夢がある。
第一に、それは、ストリーム（FRPの値の定義）の問題であって、ユニットテストすれば良い。もしくは単にFRPのログを取れば良い。
グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリも特にそうだけど、基本的にミュータブルな値同士が関数でリアクティブに連携されて常に整合性を保っているのだから、グローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという（テスト自体困難な）問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。
使用する関数の問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数の問題と一緒というのはまったく違う。
いや、それがそもそもの発端であるとブログの経緯には書かれている。説明されている方式でGUIアプリまで書けるのか？と疑念が呈されたことがきっかけ。
この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
原理的に可能かという議論ではなく、実用的な範疇か？という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRPと状態渡しは同じ複雑さだという主張も崩されている。そこが重要。
段階を踏んだ上で、非FRPのHaskellのIOモナドのコードを誰かが書いたらいんじゃない？当面、最初はOCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたから制限されたんでしょ。実際には、OCamlの関数型では冗長でしか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。
関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、
俗にいう「使えないシステム」ってやつをつかまされたのかもしれない。
今、オブジェクト指向言語みたいので、業務ツール作っているんだけど設計が見えてきた段階で実は環境がボロボロなことに気が付いてきた。たとえばpushとかpullみたいなレポジトリと挨拶するコマンドが何種類かあるんだけど、なんかhageっていうコマンド打たなきゃいけなくて憎い。TortoiseHgでpushしようとするとhage hair pushみたいなエラーが出て全然pushできないし、そもそもcommitとpullの違いがよくわからない。社内のSEに聞いても、commitは個人レポジトリに反映するだけで、pushしないとマスターレポジトリには反映されない、あとmergeが必要って言っている。TortoiseHgにMergeしてっていったら「それは無理」の一点張り。そうする間に新しい変更が反映されていたりして、もうぐっちゃぐちゃ。CVSだけじゃなくてほかにも必要な自動ビルド環境の画面が執事だったり、そもそもユニットテストのAssertionが欠落しててすべてSuccessになってたりとかしてどうにもならない。
このまま実装がすすんでテストフェーズになったら大変なことになるって言っても「CVSくらい使えるのが当然だし、ブランチとかなにそれ美味しの」とかサラッというし。40代のクソガキが！つうかpush/pullがよくわかんねぇのは俺のせいだけどいくら何でも今の時代CVSはねーよ！っていうかCVNじゃねーかよ！まぎらわしいなって、ベテランに文句言ったところでツールを変えたがるとは思えない。だからといってPerforceのライセンス買う金もない。push and pullしてgitgitする時間も金もない。死にそうです。
つかれた。p4mergeが使いたい。
普通の人からすると大したことじゃないと思うけど、もう会社の中に貢献しようと思う気が失せたので、その実態を書いておく。
ソフトウェアを自社開発していて、顧客自身がWebアプリケーションを作れるようなマルチテナントサービスを提供しています。
とある機能設計でCTOが「コレ出来るよね？」ってすごい適当な図((丸と線をつないだだけ))を書いて説明してて、
別の部署の部下がちゃんと理由((CTOには言葉の意味すらわかってなかったらしい))を説明して何度も断ってたのに、
無関係なうちの部長が呼び出されて「出来るよね？」って詰め寄られて「簡単にできますよ」ってさらっと援護してた。
彼自身はその機能に関して別に作業も具体的な設計をするわけでもないので、頭を悩ませるのは援護射撃をもらった担当の開発者たち。
社歴が長い分既存製品に関する知識があり度々オブザーバーとして呼ばれるが、今はその製品を開発している部署に所属しているわけでもなく、
最近の方向性や技術動向に関しては全然理解していないにも関わらず。
普段は雑談しながら笑ってることも多くて人柄は悪く無いと思ってるけど、仕事に関しては全部CTOの発言を決定事項として下ろしてくる。
自分が板挟みになりそうなら部下を責める。あなたの意図はどこ？
思考停止と思えるほどに「今までもこうやって来たんだし」がバンバン口から出てくる。
それを変えるやり方や新しい概念の導入に戸惑うとイライラして険しい顔でとにかく前例に合わせるようにする。
そうやって前例にこだわってきたからなのか、ちょっとしたエピソードがある。
たった４人の小さい部署だから毎週のMTGの余った時間で持ち回りの勉強会を提案して実施してたけど、
彼以外の３人がミドルウェアやフレームワークや新製品の説明をしているのに対し、彼は割とすぐネタが無くなったのか既存製品の話とか会社の規則に関する話が出てくるようになって、
最終的に「忙しいから」というよくわからない理由で勉強会が消えた。
３人共「楽しかったのになぁ」って口を揃えたんだけどね。
部長がいる僕の部署は新製品と銘打って開発を進めてるけど、例によってCTOの発言によって既に現行製品をなぞる方向でただの焼き直しを進める形になっている。
僕とサシで話した時は「現行製品と同じ機能を作っていくんだったら新製品を作る意味ってなんだろうねぇ(´Д｀)ﾊｧ…」とか言ってたくせにCTOの前ではハハハと笑っている。
以前指摘したけど、彼は新製品に関するプロダクトマネジメントやステークホルダーの立場ではなく、あくまで開発者らしい。
じゃあ誰が責任者でステークホルダーなんだよと思ったけど、そんなものは既存製品にもいなかった。
おかげさまで「あの時はこんな事情があって…」ばかりで迷走しまくってるんだけど、そういう反省は生かさないんだな。
基本的に技術に疎い。もともと企画をやってた人らしいけど、アイデアマン((その場の勝手な思いつきは多い))ではないなぁ。
バズワードは大好きだけど肝心の内容は何も知らないし間違いを指摘しても「そんな解釈もあるよね」ってごまかす。
でもそれでCTOっぽく技術をリードしていると思っているらしい。
その他にもいろいろ。「ifとforが使えれば何でもできるだろ」だの暴言も多い。
社長は彼がCTOとして問題があることに気づいているらしいが、役員だしなぁ。
来期は彼を開発部署の上から外してくれるといいな。でもその頃には僕はいない。
目の前の利益にはすぐ食いつく。
「こんな案件の依頼が来ていてお金はいいんですが、確実に専用のカスタマイズが必要なんですが…」というのに開発陣にヒアリングなしに受注を確定させる。
サーバだってもともと予算はないけどサクッと購入する。開発者たちにサーバを買う予算はないって渋りまくってるのに。
うまく行けば自分の実績として社内で大々的にアピールしまくるが、火消しに走るときは営業に文句行ったり開発者に文句行ったり。
そして保守のことは全然考えてないので、積み残されたカスタマイズサービス群が開発者や運用者、更には顧客への次の担当者を苦しめる。
現行製品の仕様を切り替えた時にカスタマイズで問題が起こったおかげで製品の仕様にカスタマイズを考慮したあれやこれやを要求されてがんじがらめ。
ちなみに、コレよりひどい自称元SIerの営業が居るが、とにかくカスタマイズ案件を取って受注しておいてPMをしないもんだから、
突然「お客さんが明日欲しいっていうんだけど」って焦って飛んでくる事態を連発する。
もちろんそんなことを連発してても「大型案件」を受注するから営業成績はMVPとりまくり。そこからずっと続く保守・運用は彼の仕事じゃないしね。
CTOの話に戻ると、僕らが作っている新製品(?)に関してもとにかく自分の理解の範囲内に収めるべく発言しまくるし、
新しい概念を持ちだされて意味がわからない時は「それって現行製品のコレはできるの？」で畳み掛けてくる。
もちろんそれを聞いた部長は「そうですよね。それも必要ですよね！」って援護してきて考えてきた設計がことごとく旧製品になっていく。
どうやらCTOの中では既存ユーザが内容を移行できる新製品にする予定で、機能まで全て踏襲するらしい。
そんなもん誰が使うんだろうねぇ。
「新製品を世に出していくには実案件で実績を作っていかなければ」って話をして、案件を持ってきた。
最初は短期間で終了する案件だったけど、運用期限の決まっていない案件が発生している。
そのために製品名もリリース時期も何も決めてないけど、メインから分離した保守ブランチができ、APIv1は提供済みだから今後はv2にならざるを得なくなり、
それすら新しい案件で潰されていくことだろう。
当初は「お客さんにはあくまで実験的なものと説明し、お金は取らない」((そんな話を受けるお客さんはたぶんいないって指摘したけど聞いてくれない))とか言ってたのに、
今は「売り上げあげなきゃこれまでの開発費がリカバリできない」とか言ってる。
まともなデバッグシステムやエディタを使わずに果たしてユーザはPHPコードを書いて開発をするだろうか？もちろん、否。
お客さんから依頼を受けたら営業担当者が四苦八苦しながら開発代行を行い納品する。
それでも難しい場合、パートナー企業に依頼をして開発をしてもらい、納品する。
そもそもPHP以外の機能自体も複雑になってて、開発者自身が「ここに機能追加しろって言われたけど、そもそもこの機能どうやって使えばいいの？」と迷うレベルだし、
想定してた使い方を超えてバグを付く動きを相談なしでお客さんに提供しちゃってるもんだから、
どれが正しい仕様なのかすら不明瞭になっている。
Javaってオブジェクト指向のプログラミングが出来るはずの言語なんだけど、オブジェクトなにそれ美味しいの？って状態。
クラスがただの関数置き場になっててメンバー変数をいじるもんだから、副作用のせいで同じオブジェクトを使う処理がことごとく影響を受ける。
それを避けるにはどうするか？もちろん似たような機能を持つ別オブジェクトを作ったり、別関数で違うメンバーを使うようにしたりする。
とにかく既存の流れを邪魔しないように新しいコードを作ればいい。おっと既存機能と同じ処理をする部分があるな。コピペコピペっと。
もうリファクタをしようと思う開発者はいないし、単体テストもないからできない。いや、無いんじゃなくて単体テストを作れない。
あちこちにDBコネクションとか埋め込んであって都度データ取得するから小さなコードでも動作するにはDBコネクションが必要なんだ。
僕は新卒メンバーには「会社内の書き方は（どの会社でもそうだけど、ここは特に）独自のやり方だから、コレが正しいと思わないように。
今後も開発者であるためにはxUnitとかバグの少ないコードの書き方とか自分自身で勉強するんだよ。」と言っておいた。
Conwayの法則とはよく言ったもので、まさしくリファクタできない密結合で暗黙のパラメータの多い組織。
自分の部署の立場を守る発言は多いけど、１年後２年後３年後どんなふうに仕事を進めていきたいからみんなでこうしていきましょう、って意思決定していくことは無い。
未来像を描いて推し進めようとする人とよく飲みに行くけど、その人もCTOからとにかく押さえつけられてたりする。
製品の結合度や他社サービスとの連携を図っていく基盤となる部分を提案しているのに、内容も全然理解してなくて「話が大きすぎて工数かかりすぎ」と言われ、
役員会でCTOが勝手に「仕様検討にかかった時間が負債になった」と報告したらしい。
「なにより、こんなことで諦める俺が憎い！」じゃないけど、そんな中途半端に辞めようと思う僕も駄目なやつだとは思う。
誰にも頼まれないまま開発インフラを変える動きを有志で立ち上げて色々やってCI((例によってユニットテストできない))が回るようになり始めたけど、それも中途半端。
運用インフラを変える部分もやっと使える状態になったけど、まだまだ中途半端。
そういった点は大変に申し訳ない。
でも、今のまま居たって僕に未来はない。
こんなところでこんなグチグチ言ってちゃダメなんだ。
だから、ゴメン！
諸事情で眠れない。
「仕様が曖昧だからこうしておくね、よろしく」という一方的な通知をメールでぶん投げて終わり。
曖昧な箇所とは、どうでもいいと思われている箇所なので、たいていの場合実際にどうでもいい。
「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」お前は小姑か。どうでもいいに決まってんだろそんなもん。
コメントを書けよ糞馬鹿野郎。見られたくないならコミットコメントやチケットにひっそり隠すという裏技もある。
進捗などというものは存在しない。0%か100%かだ。中間報告が必要なタスクは粒度が荒すぎる。
こんなもんは21世紀のITエンジニアにとって基礎スキルすぎるので割愛する。
その程度の事もできない低脳だから、周りに迷惑をかけないように刺身タンポポワークに回されているのだろうが。次は机の上に内線電話しかない部屋で一日中座ってる仕事かな。
担当者を探すことすら放棄する。直らなくても気にしない。それらはリーダーか担当者自身の仕事であり、俺の仕事じゃない。
無視してもいいが、指摘と無視では、大体無視の方が総コストが高く付く。
越権行為をする、つまり自分のキャリアを危険に晒してまで修正するほど仕事熱心な奴は勝手にやればいいが、俺は死んでもやらない。
「ここにこういう不具合が残っている、どうしよう」とリーダーに丸投げするだけでいい。システムを止めて入れ替えとかそういう事はリーダーが勝手に考える。勿論「軽微な不具合なので放置する」という判断もあり得る（大規模なシステムには大抵「既知の不具合」リストがある物だ）。「面倒なので客には黙っておこう」というのも、夜中にコッソリ修正するのと同じく、ハイリスクな判断であり、そんなもんは自分でやらずにリーダーに丸投げすべきだ。
ユニットテストを書けよ糞が。こんなもんは21世紀のITエンジニアにとって基礎スキルすぎるので以下略。
人間は、能力の限界まで能力を行使していないと劣化する。優秀な人間はそれを知っているので、「自分の仕事を減らすための嘘」は、自分を守るために必要最小限しかつかない。糞みたいな仕事で一杯になったら？黙って転職するんだよ。
あるいは、時間を仕事の精度を上げる方に費やす。テストの充実、ドキュメントの充実、開発用ツールの整備、リファクタリング。時間の都合でオミットされがちな要素などいくらでもあるし、優秀な人間ほどそうした要素が沢山見えている。
一部で話題になってるこれだけど、投稿件数100越えてる割には、他のネット論争と比べて比較的コメントが読みやすい。これについては、投稿してくる人も d:id:perlcodesample も余計なノイズや一言を入れずに投稿してくれているからだと思う。見習いたい。
にもかかわらず、ここを読まないでトラバ突っ込みを入れてくる奴は馬鹿ばっかりだから話は全然収束しないし。トラバ投げる奴は、ただ自分が気持ち良いエントリを書きました、って話しかしてない。
d:id:perlcodesample は「perlだとスカラーも各種リファレンスも全部 my $var って書くだけで受けることができる！ 楽！」って話しかしてない。（そこから派生する色んな"利点"については「お前がそう思うんならそうなんだろう、お前ん中ではな」レベルの主観だらけなので"インデントをスペースにするかタブにするか論争"のように対話しても万人に納得のいく結論は出ない）
そう言う話に「そんなことをしてると(あらかじめコンパイル時にチェックが入らないから)後から大変なことになるぞ！」ってツッコミが入り、それに対して「後から大変ってどういうことですか？ どうせ全部テストするんですから(コンパイルを行った時点である)最初から大変なのも、(プログラムをテスト実行した)後から大変なのも、大変度合いの総和は大して変わらないでしょう？」というあたりで止まっている。
この d:id:perlcodesample の主張は、(本人にとっては)暗黙の以下の前提がある。
この前提のどれかに無理があることを直感的に示さない限り、この対話は終わらない。
Webゲームっていうか、ブラウザ上で動くような奴。PHP(5.3)で突貫工事したので、ペラペラな感じだけど、なんとか公開できて、たまに遊びに来てくれる人がいて(一時はVIPに募集スレも立ったらしい)、何戦かして帰っていくので、とりあえずサーバー代を払った価値くらいはあったかなーという感じ。
で、どういうゲームかっていえば、人狼みたいに「陣営に別れて、決められた目標をクリアするゲーム」です。
『レジスタンス』っていう卓上ゲームというのかな？それを参考にして作りました。
ちょうど開発してから、一ヶ月程度になったので、宣伝をかねて、現状みたいなのをメモ。
一応、前提としては、Pythonだったら、何かしらのシェルプログラムを書いてcronしてるけど、それ以上のことはしていない程度の、技術ワナビー。
ほぼ業務経験なし。継続してスクリプトを開発したのは、今回が始めてという感じ。
単純にPHPで何か作りたいなーと思ったから。一度はPHPを書くべきだなあと思ったりした。それで、何かいい題材ないかなーと思って探してた。
「昔、人狼BBSで遊んだことあるなー、でも同じ人狼のゲームを作っても芸が無いしなー」と考えていたところ、知人と遊んだ『レジスタンス』ってゲームにピンと来て、「こういうゲームをWeb上で遊べたらいいかな。調べたところ、Web上でも人狼っぽいって言われるし、上手くそういう層にアピールできそう」ということで作り始めたのでした。
とはいえ、最初は勢いで書き散らしたので、本当にClassとかまったくなかった。それを徐々に整え直して、なんとかファイル分割できるようになった。それでも、全く足りない。具体的には下のような部分が汚い。
本当はCakePHPとかそういったフレームワークを使えば良かったんだろうけど、「重いんだったら仕方ないしなー」というわけで、フレームワーク無しで使ってみたんだけど、結果として表示部分にやたらと処理が入って醜いったらありゃしない。
表示部分と、実際のシステム部分はわけられるべきだし、フレームワークを使わないまでも、そういう風な機能分割は必要。
で、そういうコードを書いたせいで、下のようなことが起きる。
PHPUnit使ってユニットテストは書いているんだけど、まったく足りない。
全部グリーンにはなるんだけど、実際に動かしてみるとバンバンエラーが出る。
幾つかの関数はテストを先に書いたりしたんだけど、表示部分とかは「ここテスト書きにくいから誤魔化しちゃえー」といって書いたりした。
で、何が起きるかっつーと、リファクタリングするときにガンガン機能が落ちる。そして死ぬ。
さすがに一つのClassが1000行くらいになってきたので「うっわー、これは駄目だわ。分割するべき」って、ゴミみたいなコードに手を入れ始めるんだけど、全く歯が立たない。
とりあえず、既存のテストはグリーンになるけど、どこかで処理がつまづいているという状態でこれは駄目。
「うわ、この部分、テスト書きにくい！」って思った時点で、何かを嗅ぎつけてちゃんとテストに落としておけばよかった、と反省することしきり。
結果として手作業で複数ブラウザ起動して……みたいなことになっちゃう。バグの温存。
CSSとか勉強のために、自分で1から書いているけれども、これは本当にだるい。
知人から、綺麗にコードが書けるから、と薦めてもらったSaSSを使っているけれども、なかなか綺麗にできない。
一応、Twitter BootStrapは知っていたけれども、それに頼るよりは一から書こうと決心して書いたためか、ようわからないし、デザインとしてもこなれていないために気持ち悪いことになっている。
上記のフレームワークについてもそうだけど、流行っているものには、それなりの理由があって、それをわざわざ避けても、結果として、それ以上のものは（素人に毛が生えているくらいでしかない以上）ならないような気がする。
ならばとっととそういうものを使って、さっさと済ませてしまえばよかったなーと思ったりした。
ゲームという性質である以上、どんどん情報量が増えていくために、そういうのを表示しまくっていると、本当に画面がぐちゃぐちゃになる。
セキュリティーには本当手をつけられていない。(徳丸本読めという話になると思う)
（略）
で、本当にボロボロになりながら作ってみて良かったことをメモしておく。
自分は割と現実逃避の為に何かに没頭することがあって、その逃げ先としてプログラミングっていいなあと思ったりした。
あと、自分が書いたコードがヒョコヒョコ頑張っている姿をみていると、すごくかわいくなる。形にもなるし、「こういうものを作ったよ」とも言える。それは単純に楽しい経験。
元々、自分が好きそうなものから題材をピックアップしただけあって、自分が作っているものが、自分が一番愛用しているというのは幸せなことだなと思う。
自分が楽しむためのものだから、自分が一番のユーザーであるし、自分が快適に使いつづけるために改良を続けてる。
人から「こうしたらいいんじゃないの？」というのも勉強になるし、自分がちゃんと＆楽に機能を拡張できるように、ちゃんと勉強しようとも思う。そういうのは本当にいい循環。
大抵は、自分が使うから自分だけのものだったので、あまり他の人が使ってくれることを期待していなかったんだけど、今回のは、ときどき遊びに来てくれる人が居る。
例えば、VIPでスレが立ってたり、あるいはニコニコ生放送でプレイ実況を配信してくれたり。
割と「くっだらねー」と思うけど、一人で細々と開発していると、そういう些細なことが嬉しかったりする。
なので、ついついみてしまったり、場合によっては、プレイしているところをいつまでも一緒に徹夜して観戦していたりする。人のプレイしている姿が楽しいというのも、自分が作って良かったなあと思う。
逆に言えば、使ってくれる人がいるからこそ、一ヶ月間開発が続いているようなもので、「ああ、自分のプログラムで楽しんでくれる人が居るんだな」という手応えみたいなものが、モチベーションになっている。
遊んでくれる人が見えるというのは、自分にとっては、モチベーション維持に大切になってる。
だいたい三日坊主で終わっている自分としては、開発が長く続いているほうだと思う。
目指すところは、もっと綺麗なソースコードにして、Githubで公開すること（いや、もうアカウントは既に持っているんだけど、公開するのは凄く恥ずかしい）。
「人材の流動化か囲い込みか（http://remote.seesaa.net/article/147006872.html）」で示される問題は、SIerの案件であれば１つや2つはよく起こっている。ここまで問題が積み重なっててひどいのはあまりない（...と思いたい）以下は実際にみてきた現場の惨状。
excel方眼紙はよく見かけます。修正にやたらと手間がかかるので苦痛です。継続的にメンテナンスする必要があるドキュメントには向いてません。あと、ソースコードを日本語訳したようなひどい設計書が多いです。そんなもんソースコードで十分だろって思います。
本番環境でコンパイルしたりとか、恐ろしい事をしている現場がありました。それでソースコードレポジトリとの同期が取れてなくてどのファイルが実際に稼働しているコードなのか分からなくなったりもしていました。
ユニットテストがないのはデフォルトです。テスト仕様書が残っていればまあいい方ですが、テスト項目に「正常に動くこと」としか書かれてない場合もあって信用できません。
5.GUIがひどすぎる
RDBMSをつかったシステムで、会社の休業日を管理するテーブルの編集画面にレコード番号が必要かどうかで議論が始まり一時間くらいぐだぐだと会議をしたりします。そんなもん年月日でユニークキーにしておけば十分。いちいちユーザに番号を振らせるという手間をとらせたいんだろうか。
自社で一貫して設計から実装まで担当しているSIerは別として、そうでないSIerには実際にモノを作っている人間は居ない。仕様の検討段階での資料作成から、アーキテクチャ設計、設計、テスト、運用までほとんど外注にたよりきっており、ざっくりなマネジメントをしているだけだったりする。
設計から外注に丸投げしているSIerでは、日本式のやりかたとか言う以前に、そもそもSIerの社内にシステム開発を行ったオリジナルメンバーが存在すること自体少ない。
すでにSIerでは内製することすら出来ない状態まで空洞化している。
元記事のコメントより
コストダウンの名の下に人減らしだけは進みましたが、そのことがどれくらい破壊的な影響をもたらしているかを、上の人が全く理解できていません。上の人ほど開発経験に乏しく、細部を理解できていないのです。
『鉄筋減らしてコストダウン』して住めないマンションを大量生産したマンション販売会社がありましたが、IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。
IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。
ってのは言い得て妙だ。
「SIerはモノを作るのが仕事ではありません、マネジメントするのが仕事です」ｷﾘｯ!
ってよく言うけど、マネジメントに関しても、技術的な問題が起こっても解決するだけの力がないので、下請けに残業してくれという根性マネジメントしか出来てない。顧客から仕様変更の要求があった場合でも、どういう影響があるかも理解できてないので、全部請けてきて下請けに丸投げとか。
たちが悪いのは見当違いなルールを課して管理したつもりになっている事。
外注に頼り切っているSIerでは、アーキテクチャ設計、ドキュメント整備、ソースコード管理、テストの自働化、GUIデザインは社外の他人まかせになってしまっており、現状の開発方法でどのような問題があるのか気づくことができない。そういった現場から遠い場所にいる連中が現場をうまく回すためのルールを作れるとは思えない。
いまさらだがFizzBuzz。
1から100まで、3の倍数5の倍数云々って、全部定数の計算じゃね？
というところに気付き、自称メタプログラマー（略してメタグラマー）俺の血が騒いだ。
定数計算なら、それは実行時ではなくコンパイル時に行なわれるべきだ……。
#include <iostream> const int FIZZ_NUM = 3; const int BUZZ_NUM = 5; const int BEGIN_NUM = 1; const int END_NUM = 101; template<int N> struct Fizz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N> struct Buzz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N, bool ForB> struct Number {static void print() {std::cout << N;}}; template<> struct Fizz<FIZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Fizz";} }; template<> struct Buzz<BUZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Buzz";} }; template<int N> struct Number<N, true> {static void print() {}}; template<int N, int F, int B> struct FizzBuzz { static void print() { typedef ::Fizz<F> Fizz; typedef ::Buzz<B> Buzz; Fizz::print(); Buzz::print(); Number<N, Fizz::PRINT || Buzz::PRINT>::print(); std::cout << std::endl; FizzBuzz<N + 1, Fizz::NEXT, Buzz::NEXT>::print(); } }; template<int F, int B> struct FizzBuzz<END_NUM, F, B> {static void print() {}}; int main(int argc, char **argv) { FizzBuzz<BEGIN_NUM, 1, 1>::print(); return 0; }
ifなし%なしループ系なし、しかも実行時オーバーヘッドなし！（多分）
ああ、久しぶりにC++を触ったけど、やっぱC++のテンプレートってダメダメだな。20世紀の遺物といわざるを得ない。
君がもし21世紀のモテ系イケメンメタグラマーなら、21世紀のプログラミング言語、D言語を使うべきだ！
驚くべきことに、D言語はコンパイル時に関数が実行でき、その結果をソースコードとして取り込める！
ただし実行できるのは簡単な関数だけだけど……。
import std.stdio; // これでFizzBuzzを全部出力するコードを作るぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "writefln(\"FizzBuzz\");\n"; } else if(i % 3 == 0) { code ~= "writefln(\"Fizz\");\n"; } else if(i % 5 == 0) { code ~= "writefln(\"Buzz\");\n"; } else { code ~= "writefln(" ~ static_itoa(i) ~ ");\n"; } } return code; } int main(string[] args) { // おまけで生成されたコードも見せるよ。 pragma(msg, makeFizzBuzzCode()); // 生成したコードを埋め込む。コピペみたいな感覚。 mixin(makeFizzBuzzCode); return 0; } // 以下ユーティリティ。このぐらい標準で欲しいな……。 /// 整数→文字列変換（コンパイル時） string static_itoa(int n) { if(n == 0) { return "0"; } // 10で割りながら余りを文字にして追加。桁が逆転した文字列になる。 string s; for(; n; n /= 10) { s ~= ("0123456789")[n % 10]; } // 桁位置を正常にする。相変わらず効率無視。 return static_reverse(s); } /// 配列リバース（コンパイル時） /// 実行時ならarray.reverseが使えるんだけどね……。 T[] static_reverse(T)(T[] s) { T[] result; foreach_reverse(c; s) { result ~= c; } return result; } // 心配なので静的ユニットテスト（笑） unittest { static assert(static_itoa(0) == "0"); static assert(static_itoa(10) == "10"); static assert(static_itoa(999) == "999"); static assert(static_itoa(9999) == "9999"); static assert(static_itoa(12345) == "12345"); static assert(static_itoa(314159265) == "314159265"); }
コンパイル結果
$ dmd -unittest fizz_buzz.d writefln(1); writefln(2); writefln("Fizz"); writefln(4); writefln("Buzz"); writefln("Fizz"); writefln(7); writefln(8); writefln("Fizz"); writefln("Buzz"); writefln(11); writefln("Fizz"); writefln(13); writefln(14); writefln("FizzBu(ry
出力結果は略。
さすがD言語！C++やJavaやC#にできない事を平然とやってのけるッ
そこにシビれる！あこがれるゥ！
というか、
writefln(1);
writefln(2);
writefln("Fizz");
writefln(4);
もうwritefln（出力関数）要らなくね？
修正。
// これでFizzBuzzを全部出力するぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "FizzBuzz\n"; } else if(i % 3 == 0) { code ~= "Fizz\n"; } else if(i % 5 == 0) { code ~= "Buzz\n"; } else { code ~= static_itoa(i) ~ "\n"; } } return code; } int main(string[] args) { // もうコンパイル時のメッセージしか出さない。（笑） pragma(msg, makeFizzBuzzCode()); return 0; }
コンパイル結果。
$ dmd -unittest fizz_buzz.d 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBu(ry
実行するまでもなく結果が出力された。つまり実行時間ゼロ、ということは……
世 界 最 速
みんな使おうD言語！
http://www.kmonos.net/alang/d/1.0/index.html(1.0。こっちの方が安定してる？)
http://www.kmonos.net/alang/d/2.0/index.html(もっと凄い2.0)