アカウント名:
パスワード:
会社でもありそうだけど、合併や社名変更ではなく一部アプリ事業だけリリース元が変わるときってアップデートは追従してくれるのかな？
開発元が変わる場合はアプデはしばらくお預けになることが多いよ。開発者の引継ぎが難しいから。場合によってはソースコードのメンテナンスができなくなってずっとアプデなしになる。(今回の場合ではなく)今回のような場合は開発者ではなく管理者が変わるだけだからほぼ影響はない。
今回の場合は今までがずさんすぎたから厳しくチェックするようになるはずで、アプデには長時間かかるようになるはず
この手の突貫プロジェクトってたいてい頭数集めてなんとかするじゃん。集めた頭数は一段落すると不要だから方々に散るじゃん。だからそこ作ったチームのメンバーはよそ行くかやめました。よくわかりません。になるでしょ。そもそも突貫で作ったものってソフトウェアに限らず後から修正するのが大変だし。#俺達が作ったココアは信頼できるとか言ってCOVID-19に感染して死んだ愉快なやつはおるまいが。
それでもまともなソースコードとまともなドキュメントが残っていれば、それなりの技術者が揃えば十分メンテナンスできるんですよ。
残念ながらお役所や大手IT企業の開発プロジェクトって、「技術的な観点からのわかりやすさ」とか「情報の探しやすさ」は全く考慮されず、「文書のための文書」と「てにをはばかりが修正されたポエム仕様書」と「/*とりあえず動くから触らない*/」の山で、生み出されたものは例外なく膨大な粗大ゴミなんですよね・・・
COCOAはソースコード自体は可読性の面ではそれほど悪くないが問題はその周りの文書だな。
ソースコード自体は何をやっているかは判るが「本来何をやろうとしているのか」とか「目的は何か」「なぜそうなったのか」の部分を補完する文書が圧倒的に足りていない気がする。引き継ごうとしてトラブルのは大概ここ。
それ、必要になるのは初心者相手のときだけ、上級者へ引き継ぐなら必要ない文書。チェスや将棋、囲碁と同じで、定石通りのことをいちいち文書に書き記すなんてしないでしょ。書いた人の流派みたいなものだけ分かれば、分かる人にはわかるわけで。（ただ、１０年前のコードを保守する時、書かれた当時のＯＳバグ回避コードとか、当時は常識だが、１０年経てば知らない人も当然現れるという、環境変化問題がある。）
やっかいなのが、「少し考えればわかること」の量が多いことだろう。ひとつひとつは、２，３時間もあればわかることだろうが、１００や３００の数になれば、学習時間の負担が大きくなる。教える側も、教える時間の負担が大きくなる。寿司職人と同じで、技は見て盗むものなのだろう。教えるのは教える側の負担が大きい。かと言って教えないのは学ぶ側の負担が大きい。それでいて、「引き継ぎ学習のための費用は、誰も金を出さない」。引き継ぎが成功した後で、客が負担するかと言えば、彼らはケチである。
客は、「アプリ」には金を出すかもしれないが、「文書」には金を出さないものさ。かと言って「文書」が金になると、粗製乱造された文書があふれる大手ＩＴ化というね。
そのレベルのソフトならそもそも不具合なんてとっくに直ってるんでは？
チェスや将棋、囲碁と同じ？ 全然違いますよ。今年の春になって発表された新しいエクストリームスポーツですから。ゴールデンウィークに皆でルールブック読み合わせしながら開発してたの。この分野で先見の明を持つ上級者なんて市場に存在しないの。Xamarinの技術者ってだけでもどれだけいるかって話。
> 書いた人の流派みたいなものだけ分かれば、分かる人にはわかるわけで。いや、「「本来何をやろうとしているのか」とか「目的は何か」「なぜそうなったのか」の部分」ってそういう次元の話じゃないと思うんだけど。
みなあさんツリー型掲示板では返信したいコメントに返信するようにしましょう。このツリーもどの返信がどの返信に返信しているのか意味不明なツリーになってしまいましたよ。
チェスや将棋、囲碁とは全然違うね。追跡アプリは単純すぎて開発規模がまったく違う。チェスや囲碁で例えるなら人vs人用のゲームソフト作る用なもの。ゼロから開発でも1～2週間あれば誰でもできちゃう。
＃その誰でもがいない日本
うむ、君が接触追跡アプリを作るのに必要な知識を何も理解してないことを理解した
自嘲ですか？
うむ。というか付属文書自体が存在しないんじゃないか、アレ。まずXamarinでビルド環境整えるための文書とGoogleとAppleのEN APIの仕様を噛み砕いた文書が必要。そこの読み合わせで1か月くらい掛かってしまいそう。幾分かはボランティアデバッグの過程で整えられたらしいが。
本来何をやろうとしているのかとか目的はなにかとかに関して言えば誰でもわかるレベルの接近検知機能がテストされてない時点でそもそも文書化する前に考えてすらいないのでは？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
アプリ開発の主体変更 (スコア:0)
会社でもありそうだけど、合併や社名変更ではなく一部アプリ事業だけリリース元が変わるときってアップデートは追従してくれるのかな？
Re: (スコア:0)
開発元が変わる場合はアプデはしばらくお預けになることが多いよ。開発者の引継ぎが難しいから。場合によってはソースコードのメンテナンスができなくなってずっとアプデなしになる。
(今回の場合ではなく)今回のような場合は開発者ではなく管理者が変わるだけだからほぼ影響はない。
今回の場合は今までがずさんすぎたから厳しくチェックするようになるはずで、アプデには長時間かかるようになるはず
Re: (スコア:0)
この手の突貫プロジェクトってたいてい頭数集めてなんとかするじゃん。
集めた頭数は一段落すると不要だから方々に散るじゃん。
だからそこ作ったチームのメンバーはよそ行くかやめました。よくわかりません。になるでしょ。
そもそも突貫で作ったものってソフトウェアに限らず後から修正するのが大変だし。
#俺達が作ったココアは信頼できるとか言ってCOVID-19に感染して死んだ愉快なやつはおるまいが。
Re: (スコア:0)
それでもまともなソースコードとまともなドキュメントが残っていれば、
それなりの技術者が揃えば十分メンテナンスできるんですよ。
残念ながらお役所や大手IT企業の開発プロジェクトって、
「技術的な観点からのわかりやすさ」とか「情報の探しやすさ」は全く考慮されず、
「文書のための文書」と「てにをはばかりが修正されたポエム仕様書」と
「/*とりあえず動くから触らない*/」の山で、
生み出されたものは例外なく膨大な粗大ゴミなんですよね・・・
Re:アプリ開発の主体変更 (スコア:0)
COCOAはソースコード自体は可読性の面ではそれほど悪くないが
問題はその周りの文書だな。
ソースコード自体は何をやっているかは判るが
「本来何をやろうとしているのか」とか「目的は何か」「なぜそうなったのか」の部分を
補完する文書が圧倒的に足りていない気がする。
引き継ごうとしてトラブルのは大概ここ。
Re:アプリ開発の主体変更 (スコア:1)
それ、必要になるのは初心者相手のときだけ、上級者へ引き継ぐなら必要ない文書。
チェスや将棋、囲碁と同じで、定石通りのことをいちいち文書に書き記すなんてしないでしょ。
書いた人の流派みたいなものだけ分かれば、分かる人にはわかるわけで。
（ただ、１０年前のコードを保守する時、書かれた当時のＯＳバグ回避コードとか、当時は常識だが、１０年経てば知らない人も当然現れるという、環境変化問題がある。）
やっかいなのが、「少し考えればわかること」の量が多いことだろう。
ひとつひとつは、２，３時間もあればわかることだろうが、１００や３００の数になれば、学習時間の負担が大きくなる。教える側も、教える時間の負担が大きくなる。
寿司職人と同じで、技は見て盗むものなのだろう。教えるのは教える側の負担が大きい。かと言って教えないのは学ぶ側の負担が大きい。それでいて、「引き継ぎ学習のための費用は、誰も金を出さない」。引き継ぎが成功した後で、客が負担するかと言えば、彼らはケチである。
客は、「アプリ」には金を出すかもしれないが、「文書」には金を出さないものさ。かと言って「文書」が金になると、粗製乱造された文書があふれる大手ＩＴ化というね。
Re: (スコア:0)
そのレベルのソフトならそもそも不具合なんてとっくに直ってるんでは？
Re: (スコア:0)
チェスや将棋、囲碁と同じ？ 全然違いますよ。
今年の春になって発表された新しいエクストリームスポーツですから。
ゴールデンウィークに皆でルールブック読み合わせしながら開発してたの。
この分野で先見の明を持つ上級者なんて市場に存在しないの。
Xamarinの技術者ってだけでもどれだけいるかって話。
Re: (スコア:0)
> 書いた人の流派みたいなものだけ分かれば、分かる人にはわかるわけで。
いや、「「本来何をやろうとしているのか」とか「目的は何か」「なぜそうなったのか」の部分」ってそういう次元の話じゃないと思うんだけど。
Re: (スコア:0)
みなあさんツリー型掲示板では返信したいコメントに返信するようにしましょう。
このツリーもどの返信がどの返信に返信しているのか意味不明なツリーになってしまいましたよ。
Re: (スコア:0)
チェスや将棋、囲碁とは全然違うね。追跡アプリは単純すぎて開発規模がまったく違う。
チェスや囲碁で例えるなら人vs人用のゲームソフト作る用なもの。ゼロから開発でも1～2週間あれば誰でもできちゃう。
＃その誰でもがいない日本
Re: (スコア:0)
うむ、君が接触追跡アプリを作るのに必要な知識を何も理解してないことを理解した
Re: (スコア:0)
自嘲ですか？
Re: (スコア:0)
うむ。というか付属文書自体が存在しないんじゃないか、アレ。
まずXamarinでビルド環境整えるための文書とGoogleとAppleのEN APIの仕様を噛み砕いた文書が必要。
そこの読み合わせで1か月くらい掛かってしまいそう。
幾分かはボランティアデバッグの過程で整えられたらしいが。
Re: (スコア:0)
本来何をやろうとしているのかとか目的はなにかとかに関して言えば誰でもわかるレベルの接近検知機能がテストされてない時点でそもそも文書化する前に考えてすらいないのでは？