あるかな？ないかな？
プログラマの世界はとっても奇妙な世界です。
あれ？あれれ？と思う事に満ちあふれています。
今日はそんなプログラマの不思議な世界の片鱗を紹介したいと思います。
さて、皆さんはあるある！と思うか。
ねーよ！と思うか。
ではいきます。
- 概算見積もりが詳細見積もりに化ける
- 逆に言うと
- ◯日までというのはその日の23:59:59までである
- 使い分け方が不明なコード・区分・種別
- createrとcreator
- 2択にならないフラグ
- 画面仕様書と詳細設計書の区別がつかない
- ifとforで山ができる
- i j k
- 短かすぎるメソッド名
- 俺の環境だとエラーになるんだよ
- 嘘つきなDB設計書
- ぶっつけ本番
- 隣の人とメッセで話す
- コミットメッセージが願望
- 厳しすぎるバリデーション
- 雑感
概算見積もりが詳細見積もりに化ける
やるお、これざっくり見積もって
これならざっくり2人月くらいですね
・・・1ヶ月後・・・
あれ！？この前の超概算見積もり、いつの間にか詳細見積もりになってる！！オワタ・・・
この業界で「超概算」という言葉を信じてはいけません。
逆に言うと
やるお、このタスクは明後日が期限ね
了解です。逆に言うと、明後日までにできてないと◯◯さんの進捗に影響するんですね！！
やるお、ここからここまではログインチェックされないから、状態気にしなくていいよ。
了解です。逆に言うと、ログインチェックするテストは必要無いって事ですね！！
プログラマの世界では「逆に」という言葉で溢れています。
他にも
if (!isNotEmpty(hoge)) { return !isEmpty(hoge) ? true : false; }
というような、逆説を否定するという捻くれたコードもみかけます。
捻くれたプログラマが多いので、逆説の逆説の逆説に出くわしても取り乱してはいけません。
◯日までというのはその日の23:59:59までである
やるお、◯◯さんがあのタスク明日までにできるって言ってたよ。
了解です。そこだけ作業止めてるんだよなあ。明日の昼くらいから実装すればオンスケでいけるな！
・・・明日の昼くらい・・・
やらないおさん、昨日の件、進捗どうなってますか？そのタスクの完了待ちで実装進まないんですが。
ん？ああその件ね。◯◯さん今日の22時くらいにできるって言ってたよ
プログラマの世界は時間の概念がとても曖昧です。
日付だけでなく、時間もちゃんと確認しましょう。
使い分け方が不明なコード・区分・種別
商品コード、商品区分、商品種別・・・・
多分大項目・中項目・小項目的な分け方だと思うけど・・・使い分けのルールが全く分からん・・・
データベースの設計をする時によく見る現象です。
大・中・小項目の分け方等はその会社によって妙なルールがあったりするので注意しましょう。
createrとcreator
あれ？やらないおさんは「ゲットクリエーター」っていうメソッド使えばOKって言ってたな。getCreater()とgetCreator()があるな・・・
この世界は英語が大変曖昧な世界です。
名詞・動詞・助動詞、大変曖昧です。
2択にならないフラグ
あれ？なんでisEnable()メソッドでヌルポになるんだ？んんん？？
SQLで一応データ見てみるか。
| 有効フラグ |
|---|
| true |
| true |
| false |
| null |
| null |
フラグなのに3択になってるのかよ！！
だからisEnable()の返り値がbooleanじゃなくてBooleanになってるのかよ！！
true/false/nullの3択はまだマシです。
プログラム上true=1、false=0、という値に変換されるのですが、後から状態が増えて以下のようになる事があります。
| 有効フラグカラムのコード値 | 内容 |
|---|---|
| null | 未処理である。 |
| 0 | 無効である。 |
| 1 | 有効である。 |
| 2 | 未処理だが画面に表示する。 |
このように、後から状態を追加してしまい、フラグがフラグで無くなる現象があります。
画面仕様書と詳細設計書の区別がつかない
やらないおさん、画面仕様書できましたよ。レビューお願いします。
ん？全然処理内容書けてないよこれ。処理の詳細書いてよ。
・・・俺は一体なんのドキュメントを書いてるのだろうか。
プログラマの世界ではしばしば画面仕様書がそのまま詳細設計書に変貌する事があります。
ifとforで山ができる
よし、次はこのタスクだな。コードはどんな感じかなっと。
if(isHoge()) { if(isHoge2()) { if(isHoge3()) { if(isHoge4()) { for(int i=0; i<hogeList.size(); i++) { if(isHoge3()) { ・・・・・・・・・・・・・・略・・・・・・・・・・・・・・ } else { setHoge(null); } } else { setHoge(null); } } else { setHoge(null); } } else { setHoge(null); } } else { setHoge(null); } } else { setHoge(null); }
・・・・・・・・・・・・・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・
すみませんやらないおさん。ちょっと外の空気吸ってきます！！
プログラマの世界ではしばしばネストの山を見かけます。
ネストの山製造職人を生み出さないように注意しましょう。
i j k
ふむふむ、ここは商品データを取得してループしてるのか。このメソッドの中はどうなってるのかな。
↓
for (int i=0; i<10; i++) { for (int j=0; j<10; j++) { for (int k=0; k<10; k++) { if (0 < i && (j == 10 || 2 < k)) { i += (j + k) * 1.08 } } } }
これ書いた奴の頭の中、スパゲッティがビッシリ詰まってるんじゃねーかこれ・・・
プログラマの世界でループ変数「i」は定番です。
しかしiだけでは足りず、j、k、・・・と付け足され、しまいには「ii」等が現れる事もあります。
極力「i」は使わない方がいいでしょう。
短かすぎるメソッド名
昨日やるおから依頼されたコードのレビューすっか。
public String getPc() { ・・・・略・・・・ return pc; }
getPc()ってなんだ？パソコンの略か？
おいやるお、getPc()って何？
あ、それは商品コードの略っす。
略さないと「getProductCd()」っすね。長いメソッド名嫌いなんですよ。
プログラマの世界では短い事を良しとする習慣があったりします。
しかしあまりにも短くなりすぎて何の略なのか解らないものが沢山あったりします。
俺の環境だとエラーになるんだよ
やらないおさんから起票されたバグチケット、再現しないなあ・・・
やらないおさん、これどうやって再現させるんですか？
ああそれ？ちょっと俺のとこでやってみてよ。
ほら！エラーでるっしょ！？
macでやってるんすか・・・
っていうかこのフォルダのパーミッションおかしいじゃないですか！！
オレオレ環境でテストしてバグチケット起票するのやめて貰えますか！？
プログラマの世界では「俺の環境でしか起きないエラー」が山のようにあります。
大抵環境設定がおかしい事に起因するエラーであり、不毛な調査時間を費やす結果になります。
嘘つきなDB設計書
お客さんから貰ったテーブル定義書を元に実装するか。
ふむふむ、PrimaryKeyはこれか。特に問題なさそうだな。これなら余裕のオンスケだな。
・・・商品データcsvを取り込んでみる・・・
Duplicate entry '1' for key 'PRIMARY'
ん？PKのカラム指定ミスってたかなあ。
一応テーブル定義書もう一回見とくか。
そういえば何故か別紙も添付されたたな。
これは商品の一意キーとなるコードです。 しかしこれは自社製品に限って一意になり、 他社製品と同一になる場合があるので、 ◯◯種別コードと合わせて参照すること。
テメーらPrimary Keyって意味解ってんのか！！？？
ITリテラシー低いなら無理して専門用語使うなよ！！！！
プログラマの世界では定義書は嘘つきな場合があります。
「ただし◯◯な場合に限る」というトラップが仕掛けられている場合があるので、注意は怠らずに。
ぶっつけ本番
今回のアプリはセッション使うのか。本番環境は複数台あるから、セッションレプリケーションしないとな。
ぶっつけ本番は避けたいな。
やらないおさん、テストできないんでec2のインスタンス作っていいっすか？
ん？無理無理。
このPJはこれ以上金出せないよ。
あ、社内の規定で個人のPCにvagrantとかで仮想OS起動するの禁止だから。
プログラマの世界ではサーバが複数台無いとできない事が沢山あります。
しかし諸事情で複数台用意できず、ぶっつけ本番な状況が発生する事があります。
隣の人とメッセで話す
「やらないおさん、このチケットの進捗どうですか？」（←チャットで発言してる）
やるおよ・・・・隣に俺いるからさ、直接話しかけてよ・・・
（やるお、俺の事嫌いなのかな・・・）
チャットだとログが残るんで後で楽なんすよ。
プログラマの世界では、隣の人とチャットルーム等で会話をする事があります。
IT以外の世界からこの光景を見ると、異様なコミュ症集団に見えて怖くなります。
ログが残って後から検索できるのは便利ですが、ログを残しつつ直接会話しましょう。
コミットメッセージが願望
よし、これをコミットして、プッシュ！
これで後はデプロイされてバグ修正完了だな！！
・・・jenknsでエラーとなる・・・
ん、やるおのコミットでユニットテスト失敗してるな。
コミットメッセージ見てみるか。
refs #1234 これでヌルポは起きない筈！直ってくれ！
なんだこのコミットメッセージは！！
プログラマの世界では、svnやgitのコミットメッセージに願望を書く人がいます。
プログラムは書いた通りにしか動かないので、願望を書くのはやめましょう。
厳しすぎるバリデーション
お問い合わせフォームのテストするか。
お、文字数制限チェック走ったな。
文字数を正しく直して再チャレンジっと。
お、全角チェック走ったな。
全角を半角に直して再チャレンジっと。
・・・ん？なんで「不正な文字が入力されました」が出るんだ？
やらないおさん、なんでこれバリデーションエラーなんですか？
ん？あーそれね。それ横棒が「ー」じゃないとエラーなんだよねー
「−」じゃダメだったか。よし「ー」に直して今度こそ・・・くそ、まだエラーか・・・・
しかしソース見ると凄い数のチェックだな・・突破できる人いるのかこれ・・
プログラマの世界では入力チェック（バリデーション）は非常に重要です。
しかしあまりに厳しい入力チェックのため、ユーザ入力完了できずに諦めてしまう事があります。
入力チェックを緩くするとコンバージョンアップするので、厳しいのも考えものです。
雑感
やらないおさん、この業界なんでこうなんですかね・・・
日本語より機械語の方が好きな奴が多いからじゃないかな・・・
