ソフトウェア開発に「ちょっと変えるだけ」などない

「SMSを使う場面があるからレビューの長さを140文字以内に制限したいんだ。ちょっと変えるだけだよね？」，ソフトウェア開発の
現場でこんな要望を受けることはよくあります。

カスタマーサポート向けのSaaS（Software as a Service）を提供するIntercomのブログにて，「高品質のソフトウェアを提供しよう
思うのなら，ちょっと変えるだけなんてことはありえない」という主張とともに機能の全体像をしっかり検討し，その価値と見積りの
バランスを熟考することの重要性が説かれていました。

冒頭のような場合，経験の浅いプログラマは熟慮することなくif文を追加して数分で対応してしまうかもしれませんが，ソフトウェアや
サービスの質を高めることを目指すのであれば，考えることは山ほどあります。
・レビューが140文字を超えたらどうなる？
・エラーはどこにどんな文言で表示する？
・文字数制限の理由をユーザにどう説明する？
・エラーの見た目は誰がどのようにデザインする？
・クライアントサイドでもエラーチェックをするべきでは？
・JavaScriptが使えない場合はどんな動作になる？
・ユーザ視点だと，現在の文字数が確認できるカウンタがあったほうがよいのでは？
・実装後にはテストをしなくては
・最後はデプロイもしなくては

こういった判断は，経験豊富なプログラマであればその場で行えるものがほとんどですが，すべてのプログラマがそうとは限りません。
機能の全体像がよく検討されていない場合，2分で終わりそうに思える作業が2時間の作業になってしまうことはよくあります。
そして，2分の見積りであれば「良い価値」があると思えた機能も，2時間の見積りになるのであればスコープから外すことが
妥当なこともよくあります。

新しい機能に賛成するのは簡単です。コーディングはたいてい簡単にはいきません。そして，メンテナンスは悪夢になります。
高い品質のために努力しようとするのなら，「ちょっと変えるだけ」などあり得ないのです。
http://gihyo.jp/dev/clip/01/tech_information/vol76/0003

×ネトウヨ
○ネット・ウヨク

これは何にでも言える

デファインかコンストの140をかえるだけだろ
どんだけぼったくってんだよ

何文字入れようが１４０文字以上はバッファに格納されない
↓
１０分で仕様変更完了

久しぶりのWEB屋ホイホイか

最初から項目長全部無制限にしとけ

＞・レビューが140文字を超えたらどうなる？
＞・エラーはどこにどんな文言で表示する？
＞・文字数制限の理由をユーザにどう説明する？
＞・エラーの見た目は誰がどのようにデザインする？
＞・クライアントサイドでもエラーチェックをするべきでは？
＞・JavaScriptが使えない場合はどんな動作になる？
＞・ユーザ視点だと，現在の文字数が確認できるカウンタがあったほうがよいのでは？
＞・実装後にはテストをしなくては
＞・最後はデプロイもしなくては
ちょっとじゃんｗ
これが山ほどとか、どんだけゆるい仕事かと小一時間・・・・

てか、そもそも上限を一発で変更できないっておかしくないか？
と、プログラムの設計を疑うべき。

どんな仕事だってそうだろう
形になっているものを崩すと必ずどこかに歪みが生じる

確かに
＞・入力文字数が最大文字を超えたらどうなる？
これは最初の設計時点で決まってる。
そして、これが決まっていればあとの問題はすべて解決している。
そうなってないとかありえないわな。

>>8
同意
つかこの内容って
関係者のコミュ力不足や無能ＳＥの所業もあるな

>>9
現状は無限に書き込める仕様になってますｗｗｗ

>>10
時代を重ねるにつれて、徐々にその意味も忘れていくからな。
マーで考えるとよく分かるね。何でこんな風になったのかを知ってる人は少ない。

プログラマーなら是非読んでおくべき本いくつか教えてよ

int unko(int a){ return a; }
short tinko(int a){ return (short)a; }
…

int main()
{
　int (*manko[])(int) = {unko,tinko};
　
　…
}


In function main:
　warning : initialization from incompatible pointer type

>>15
かにチャーハン

>>15
人月の神話―狼人間を撃つ銀の弾はない

>>1
昔プログラマやってたけど当たり前のことをおおげさに書いてるだけじゃねえかバカかよ。これ含めてちょっと変えるだけじゃん
ちょっと卵焼き作るのだって大げさにいえば、
フライパンどうする？
どんな卵使おう
料理の仕方は？
味付けどうしよう
洗うのめんどくさ
とか色々あるのに。

>>7
可変長カラムのDBがどれほどの殺傷能力を持った飛び道具か知らないだろ

お前ら技術に対してあーだこーだと言ってるが
まず第一として

＞・文字数制限の理由をユーザにどう説明する？

これは「プログラマーの仕事」じゃないだろと突っ込めよ

>>15 アートオブなんとか

>>15
アートオブリーダブルコード
SQLアンチパターン

>>15
まつもとゆきひろ コードの世界〜スーパー・プログラマになる14の思考法

ベースがあるんだから結局ちょっとだろ
元が200ならそれを140にするだけ。エラー等の文面も流用
簡単に出来る事をさも難しそうに言ってるだけで単なる無能だろ

>>8
これはちょっとじゃねえわな

そもそも上限が無いとしたらやばい

記載されてる、
山ほどある考えることは、
プログラマーの仕事じゃない

プロマネやコーディネーター調整し、
その結果をプログラマーに発注しろ

>>19
料理は鮮度勝負なので短期案件。
中長期で考えたらありえない。

>>28
プログラマ以外はみんなピンハネしかしてないから

たかし「母ちゃん、ちょっとおにぎり二つ作ってよ」

J( 'ｰ`)し「・おにぎりが３つ出来たらどうなる？
　　　　　　・どこのどんな皿に乗せる？
　　　　　　・おにぎり作った理由を父ちゃんにどう説明する？
　　　　　　・おにぎりの見た目は誰がどのようにデザインする？
　　　　　　・私自身で味のチェックをするべきでは？
　　　　　　・２つ食べきれない時はどんな処理をする？
　　　　　　・たかし視点だとタクアンもあった方がいいのでは？
　　　　　　・おにぎりを作るには塩と具を用意しなければ
　　　　　　・最後は海苔を巻かなくては
　　　　　　こういった判断が必要だからおにぎりを作るのにちょっとなんｔ・・・」

たかし「うぜぇババア、死ね」



そんな母が去年の暮れに亡くなった。
死ぬ前に１度だけ目を覚まし思い出したように
「おにぎり、ごめんね」　と言った。

　　　　　　　　　　　　　　　　　('A` )
　　　　　　　　　J('A`)し　　　　(　 )
　　　　　　／⌒⌒⌒⌒⌒ヽ　　｜|
　　　　 ／／￣￣￣フ　／
　　　／　（＿＿＿／ ／
　　　（＿＿＿＿＿_ノ

ちょっと変えるだけでリリースしてバグだらけってのも、結構あんだろ

>>30
設計エンジニアと基盤も頑張ってるよ
特にリミットの引き上げは基盤泣かせ
よほどの引き上げ幅じゃない限りSLAは変えてもらえない
プログラマもできるだけ修正箇所を減らそうとしてトンチキな実装するし

入力データの正当性をチェックする処理系に条件を追加するだけ
ないなら基礎設計の時点で失敗してるから諦めろ

結局本文中にあるコレが全て

＞こういった判断は，経験豊富なプログラマであればその場で行えるものがほとんどです


要するに経験も技術も無いバカSEが勝手に切れてるだけですよ、という記事

すぐだけど、金をもらわんとやってられん

ん〜ｗ。ちょっと変えるだけ〜が何を指すのか？１４０字に拡大？したいなら、それ以前の数値を大きく取るだけで？Error処理も全部同じじゃね？

一番考えなくちゃいけないのは既に140文字超えてるのをどう扱うかだろ

>>1
何年やってんだ。
クライアントの空気読めよ。

フリーソフトを削除したらサラダボールのドレシッグに例えていた

>>25
これ

最初にこの辺が考慮されてないなら要望要求に応えられないのはただの機能不備

やっぱりちょっと変えるだけじゃねぇか

10分でてきる仕事をどうしたら1時間にするかということ。

一方ロシアはSMSを140文字以上使えるようにした

>>43
保守契約してりゃ無料だが、単発仕事なら1時間どころか0.5人日くらいで見積もりしないと

考えてなおかつ2分でやればええやん。

５分で終わるとしても最低半日分は請求するわな

この程度の仕様変更で右往左往するなんて
ぬるい規約の元で開発やってんだなぁ

あるだろ

一つ直したら次の不具合でるからな

>>8
ちょっとすぎて噴いたわｗ

ゲームの下請けとかしてみろよ
発注元の勝手な仕様変更で1から作り直しなんてざらにある上に納期変わらないんだぜｗ

>>43
これに尽きる

考えることは山ほどありますって言うが、考えるだけでほとんど何もやらないんだろ結局

まああくまでも>>1は例えだから。
こんな簡単な変更でもよく考えてやらないといけないという一例。

実際の変更はもっと複雑だから、変更が及ぼす影響を
１ヶ月単位で検討することもある。

誰が責任者となってどれだけのコスト（スケジュール含む）をかけて担当するのか。
クライアントの要請だとしてもその変更は本当に必要なのか。
変更点のロジックに矛盾はないのか（変更によるエンバグ対策）。
後任に受け継ぐための資料作り...などなど。

>>1を読んで当たり前だろwwwと笑うひとはエンジニアには向かない。

どんだけ屁理屈捏ねて無駄に時間を引き延ばせるか、という、その才能が無い人間はエンジニアにはなれないと言う事

最近日本でもソフトウェア開発者の待遇よくなってきてるはずなんだが
スレ見てるとけっこう底辺で働いてきた奴が多いんだな

当たり前の事を当たり前としてやる仕事を底辺（）とか思ってるから所詮三流SE止まりなんだよ

仕様書作った奴が自分でやれよ

>>43
早くやる癖つけると
無理難題すら早くやれってなるからしょうがないよ
エラーチェックとかも入れて無駄に長めに見積もるしかない

なんか見た目が悪いなあ、ホイールベースを1cmだけ伸ばしてみようか

>今回のリコールでは、エンジン制御ユニット（ECU）、トランスミッション
>ドライバーユニット（TDU）、ハイドロスタティッククラッチアクチュエー
>ター（HCA）のそれぞれを制御しているプログラムが不適切で、エンジン回
>転が不安定になってエンストする、駐車状態から起動しなくなる、発進や後
>退ができなくなるといった不具合が発生するおそれがあるとしている。

さっさと直しちゃってよ、こんなのすぐ出来るでしょ？
デグレ試験？そんな工数認めないからね

例が悪い

>>4
これがアマチュア

ウチの会社なら上司に通さずコッソリ直して、シレっとリリースしてるわ・・・

>>3
社内の申し送りなんかでも、サラッと流した軽い内容がキモだったりして、後でだいたい後悔することになる。
申し送った方は、ワザワザ申し送りで伝えなきゃいけない程度に重要なことだと認識して伝えてるのにね

先っちょだけだから、すぐすむから

最初から全部自分が作ったものならいいんだけど、たいていは他人が
急ぎで作ったうえに仕様書も不十分な状態で引き継がれてきたものを
書き換えることになるからつらいよね

少しの変更で多く見積もる
まじで日本てこんなのばっかでいつか崩壊すると思う

こんとんじょのいかとクイックハックすると思わぬトラブルでてんてこまいする、かもしれないという話だろ。
ちょっとの変更のためにアルゴリズム見直しで大変更ってのもよくある話だし。

減らすのはいろいろ面倒だけど拡大なら別に文句いうやつってそんなに居なくね？

>>38
そもそもSMSで使うから140文字というのが意味不明で、レビューが長いなら表示できない箇所は〈続きを表示〉で表示させたら良い

//#define BUF_SIZE 1024
#define BUF_SIZE 140

buf[BUF_SIZE+1]

ITだけは辞めておいたのがいい

人売りITなんてもってのほか

※人売りIT
ITエンジニアを雇い、顧客にエンジニアを売り込む。
エンジニア派遣専業の会社のこと。

自社に社員がいないのが特徴。特定派遣。

元々字数制限を設けてないって、セキュリティ上問題のある設計じゃないか。

詳細は割愛するが、C言語特有の脆弱性として一世を風靡した時代もあって
MSはC言語の仕様をわざわざ変更してまで対応したんだぞ。

C言語を前提で話す老人達

おおげさなｗ実際は文字数の制限が小さくなるだけだろうが
そりゃ一箇所変えるだけじゃすまないが、めんどうだから仕事になるんだろ
その分の金は貰うんだからむしろラクな金稼ぎだ、もっと良い例えもってこいアホが

一から自分のとこで書いたソースならいいんだけど、他所のを引き継いだとなると話は別。
なんでこんなマジキチコードになってんの！？と驚くこともしばしば。

>>77
ちょっと変えるだけなんだからお金いらない(orちょっとだけでいい)って話だろこれ
一番ありがたくない仕事

>>79
いや、多分ホントに「ちょっと変えるだけ」だ。
Windows8.1で、例えばデスクトップ、壁紙の空いてる所をダブルクリック（２回たたく）と、
スタートメニューに飛ぶ、とか・・・その位の話。この変更を入れるとマウスが少し、便利になる。
ただ、逆に言えば「マウスでも良くなる」んで、タッチパネルに拘るなら、その変更は苦い。
"だから"嫌だ、って話。そこに屁理屈乗っけてるだけなんだよね・・・

あっ、楽勝っすよ、といって安請け合いをすると
とんでもないトラップがあったりする

下っ端は安請け合いしたがる

「自分が全責任を負って絶対です」って言い切るのならともかく
「多分」で安請け合いする奴は、やっぱ馬鹿な訳で

一回作ったものは、どんな糞仕様でも変更するのに大変な労力がかかるのですよ。

>>84
それは設計がダメだ

>>80
その例え全然的外れなんだけど…

おかしな例だなあ
じゃあ元々は一体何文字制限だったんだ?
元々ちゃんと字数のバリデーションが実装してあれば、考える必要のない項目がほとんどじゃん?
それこそ2分で終わる仕事のはずじゃん?

高品質のソフトウェアがー
なんて内容の割りには、現状がずさんすぎね?

だいたいエラーが起きる可能性、ってのが多すぎるんだ
ほぼ何でもエラーを返したり、例外を投げやがる

メモリが足りないからｗとか言われても、それ俺のせいじゃないし、
ふつうnewがbad_allocとか投げることは無いはずだ
脅しても無駄ですよ？

これはLHCで圧縮するしかねーな(｀･ω･´)。

＞エラーはどこにどんな文言で表示する？
＞文字数制限の理由をユーザにどう説明する？
＞エラーの見た目は誰がどのようにデザインする？

そんなもんプログラマの仕事じゃないだろ

レングスが１４０以上ならエラーを返せば良いだけだろ

>>90
日本人だなあw 死ねよw

>>64
それを繰り返すとクライアントが図に乗って後々悪影響を及ぼす事が有る

>>92
なんで？

外国のプログラマーって基盤も自分で用意すんだよな

ネットワークもサーバーも。まじすげーわ・・・

Unicodeの場合「1文字とはなんぞや」という話にもなってくる。
そういった全てのことが事前にわかるのはプログラマだけ。

Unicodeなのか、マルチバイトなのか…？

本当はそのほうが良いけど他の画面と合わせてこの処理で。。

>>96
それを人間に分かるように伝える能力が欠如してるんじゃねえの？
人間力ゼロの奴隷グラマどもは。

>>99
伝える相手が人間以下なんだよ。
昔上司がSjis環境からSjis環境へ文字列引き渡すのにアホみたいなテストケース全部通せって駄々捏ねたの思い出したわ。
曰く作ってる奴が信用できないから、だそうだ。
そういう根性論で結果を求める奴にunicodeがどうの2バイト文字がどうの、なんて説明しても無理。

設計がヘボだと本当にこまる
今やってる仕事がまさにそれ
とにかく開発やったことない奴が設計とかするなと強く言いたい
まあ設計やってるのが客だから強く言えないんだが

「ごちゃごちゃうるせえ　やれ」って言えばいいだけじゃないの？

>>99
たいていのプログラマは説明以前に自分でも理解すらしてない。
だから奴隷みたいな労働に甘んじなきゃいけなくなる。

>>1にあるような話なら、3GPPと3GP2の規格書読んで
メジャーな端末での実装でテストしてサロゲートペアは何文字扱いなのか、
バリアント指定は、など調べなきゃならないわけだけど、
そういうことする奴ホント居ない。

調べ物ってネットサーフィンみたいで面白いのに。

実際はすぐ終わる簡単な作業でも、「いやぁ、それ、改造ボリュームおおきいわ」とか言っておけば、「じゃあ、やらなくてもいいや」となることがほとんど

とりあえず言っとけてきな宣言みたいなもん

>>104
逆に言うとそこで引くような要件なら「本当に必要なもの」じゃないってことなんだよね。
ただ残念なことにそういう流れがデススパイラルのもとにもなってる。
客は「金額みてから要件を引いていけばいい」と思ってRFP段階で要件の重要度を精査しない。
見積出てからじゃ要件の重要性より「予算内におさめる」が主眼になって要件の重要度を見誤る。
ベンダはベンダでバッファ積むのに慣れちゃってるから見積もり段階で保守運用の考慮はバッファ分でカバーできると思って軽く見る。
出精お値引で妥結した金額になったとき、初めてあれ？運用構築分がえらい少なくね？ってザマになる。
アジャイルだのスクラムだのが流行ってるのはWFがダメだったんじゃなくて客もベンダもWFに真摯にならなかったせいでWFがダメにされたせいだと思うよ。
もちろんアジャイルも同じ道を辿りつつあるんだけどな。
結局は一人一人が「ITって動いてる時は便利だけど動くものを作って動く状態をキープするのはとても大変なんだ」ということをきちんと理解してないことが一番の問題なんだよな。

建築物でたとえると
建築中の建物で窓をでかくしてくれと言えば柱減らしたりずらしたり
それに伴って構造計算やり直したり別の柱や梁を補強したりと
そういう風に連鎖的に修正箇所が出てくるようなもの

>>106
そうならない設計にしなければならないんだけど
動けばいいやの奴が多すぎて話にならん

内容的に文字数チェックの仕様漏れを底辺プログラマがゴネて修正を渋ってるだけの気がするが…

>SMSを使う場面があるからレビューの長さを140文字以内に制限したい

意味が分からない

場面って？
レビューって仕様書レビューやコードレビューの「レビュー」じゃないですよね

元が文字数無制限ってこと？
ありえないｗ

エクセプションまじめんどい
トライとかキャッチとかみにくいんだが

面倒だからこんな感じで済ます
if (Text.Length > Review.MaxLength)
　 　 Text = Text.Substring(0, Review.MaxLength) + "...";

車載組込み制御屋だけど、納期（出荷）まで遠い時は簡単。
でも、納期が近いと1ステップ直すだけで2週間はかかるw

修正５分、テスト１０分、報告書各種山盛り、影響調査山盛り、
レビューレビュー承認承認、もう嫌。

ソシャゲー業界入ったら仕様書というものが無いのでワロタ

でもDB側をいじらなくていいなら、ちょっとの改変だよね。
上司に言うと金とれって言われるから、勝手にソース直して仕様書も直してロハでやるわ

>>3
これ

発注する側はちょちょいと出来るでしょって考えなんだけど、作る側はあれを変えたら
ここもいじらなきゃいけないってのが色々とあったりするわけ。
ところが大抵職人なんてのは口下手が多いから、わからない奴に説明するなら
手を動かした方が早いと思って無駄な作業をやったりするんだわ。
これでお金になるんなら問題は無いんだけど・・・

ＩＴは鉄ｫﾀじゃないと勤まらないな；

>>115
試験結果もちゃんと残しておけよ

化学多いけどな

ちょっとじゃん

>>113
車載、懐かしいなぁ、
思い出すと憂鬱になるｗ

同僚がレクサス仕様やってたけど書類の量が凄かったな
でもレクサスは仕様変更の追加見積もり通りやすく、金払いよさそうだった
もちろん納得してもらえるだけの説明しないかんけど

> 250 名前：仕様書無しさん[sage] 投稿日：2013/12/26(木) 15:12:37.94
> 　報道を受けて弊社で調査させていただいた結果、SimejiについてログセッションがOFFの場合でも一部のログデータが送信されていた事実を確認しました。
> 　このデータは、変換精度をあげるためのデータとして活用しているものですが、 バージョンアップ時に起こった実装バグということが判明しました。
> 　こちらは今年3月にリリースしたバージョン5.6から発生していたことが判明しました。
> 　本日中に改善した最新バージョンを緊急リリース予定です。リリース情報は、準備ができ次第別途ご案内予定です。
> 　ttp://www.baidu.jp/info/press/jp/131226.html
> 　
> 251 名前：仕様書無しさん[] 投稿日：2013/12/26(木) 15:47:47.78
> 　> バージョンアップ時に起こった実装バグ
> 　> 今年3月にリリースしたバージョン5.6から発生していた
> 　
> 　Simeji - ウィキペディア
> 　最新版 v3.F.6
> 　A　B　C　D　E　F　
> 　1　2　 3　4　 5　6　
> 　
> 　バイドゥ、Android向け日本語入力アプリ「Simeji」を6.0にバージョン ...
> 　2013/05/09 -
> 　
> 　> 2011年12月13日にバイドゥ株式会社が事業取得を発表した[2]。
> 　> これに伴い開発者であった2名（adamrocker、矢野りん）はバイドゥに入社し、引き続き開発を担当する。
> 　
> 　完全に仕様変更です。どうもありがとうございました。
> 　バレちゃったので暗号化して送信だな。
> 　
> 252 名前：仕様書無しさん[] 投稿日：2013/12/26(木) 15:52:14.01
> 　今年３月と言えば、ソフトバンクが優良顧客のカードをブラックリストに登録したのが発覚した時期で
> 　２ちゃんねるのＩＰアドレスが記録、送信されるようになったのが今年はじめ〜６月ごろ。
> 　
> 　日本は全体的にほとんどすべての情報を外国に握られて金も奪われてるなあ。

Baidu(バイデュ)「設定オフでもデータ送信してたのはバグだったわスマソｗ」
ttp://engawa.2ch.net/test/read.cgi/poverty/1388037246/

>>103
サロゲートペアで済むうちはまだ平和だぜい。
ナンボでも重なれる結合文字が来た日にはもうね…

>>121
トヨタは何の仕事でも金払いいよ〜
ちょっとしたツール納品しただけだけどスゲー額貰えて腰抜けたことある

結合文字は難しいよね。

でも結合文字が欠けても文字化けで済むけど、
サロゲートペアをぶった切ると db の text フィードに
入らなくなる等のクリティカルな問題が発生するんだよね。

>>112 みたいなのがいると簡単にそういう障害が起きる。
テストベクターもどうせいい加減な簡単な文字列だろうし。

各社のIMEはJIS 第三水準なんか対応しなきゃよかったのに。

>>115
ﾄｸﾝﾄｸﾝ...

作るだけなら即効終わるけど金がカラムとうざい。
でもこの>>1はズレている

if(CheckStringsSize(&strings))
{
DelateRemainingStrings(&strings);
}
// なにか？

>>129
メソッドの頭は小文字にしろカス
{前で改行すんなカス

まあ経験則で変えてくれと後で言われそうなとこは仕様になくても
予め変更しやすい様には作っておいて
しれっとリリースするがな

>>129
最近はif 〜 endif;使うようにしてるな。

length($review) <= 140 or die('レビューの長さを140文字以内に制限したいと言われたのでちょっと変えた。');