211(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 22:17:53.79 ID:Eh77ZCvU0(12/15) AAS
>>205
ちなみに技術的な話をすると、
> gitのコードはしっかりしているということだろ
これは根本的に違ってて、要するに俺が楽したいだけなんだよ。

内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。(POSIX君はこの点を問題視してるわけ）
そして外部ソフト自体がバグってても勝手に直してもらえる。
寄っかかることに抵抗がなければ、寄っかかった方がユーザーにも制作側にもメリットがあるんだよ。
(勿論囲い込みは出来なくなるが、最初からそんなのする気ないし）

デメリットは、その外部ソフトのバグもユーザーには俺のバグにに見えるから、俺がバグ対応窓口にさせられる可能性があること。
俺のバグなら致し方ないが、外部ソフトのバグなんて対応してられない。だから安心出来る範囲でしか使わない、ということ。
要は全部楽する為の方策であって、お前らみたいにポリコレまみれではないんだよ。

177(3): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 06:55:24.88 ID:Eh77ZCvU0(2/15) AAS
俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。つまり、
仕様が簡単で直感的なら、ドキュメントを整備するまでもないし、
バグがなければ、後は「十分動く」程度のメンテで済む。だから最初から出来る限り品質の高いアプリを投入すべきだ。
ここら辺は「伽藍」では共通認識のはず。『コード/仕様さえよければ、全て何とかなるんだ！』的な思想だ。

ただここら辺を「バザール」でひっくり返したから話題になったわけだが、やっぱこれは違うよな～とは思うよ。
これって「善意のただ乗り」の仕方が世界一上手かっただけで、みんながこれをやり出したら回らないよ。

195(4): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/13(日) 19:35:13.58 ID:md3JoP5e0(3/8) AAS
>>191
その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
それをベースにするってことだろ
gitその他の開発方法にケチつけるならそれで開発されたものをベースにするなよ

始めてもいないうちから「第二弾」とかバカ過ぎる
大口叩いてないでさっさと作れ
検討したことや結果を公表する場所を決めて発表するくらいはすぐできるだろ
>>172 >>182

795(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil) [sage] 2023/08/19(土) 14:41:38.83 ID:Af/nXbF+0(3/10) AAS
>>789
プログラム書けないやつはこれだから……

・複数の実装を書いて比較してみたいことがある
・機能の組み合わせを複数パータンでテストしたいことがある
・新しい発想を他に影響を与えずに試したいことがある
・新規提案前に実物を作って見せたいことがある
・開発を複数並行で進めなくてはいけないこともある
・緊急の割り込みタスクが入ることがある
・自分の仕事の合間に他の人の仕事を助けてやることがある
・やっつけで書いたコードを他人に見せる前に綺麗に清書するのは当然、しないやつは○ね
・テストなどで出た問題は他人に見せる前に直すのが普通
・タイポとか恥ずかしい間違いは他人に見せれない。見せられた方も困る

まだまだ書けるけど？

797(1): デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l) [sage] 2023/08/19(土) 15:12:04.16 ID:vl4t9mIK0(2/7) AAS
>>793
おまえは勘違いしているというか、gitのブランチとリポジトリを理解できてない
「ローカルブランチをそのまんまメインリポジトリのブランチにワンタッチで昇格」これを禁止してるところはほとんど無い
プルリクエストで管理者がチェックしてメインブランチにマージする現場でも、まずはローカルブランチをメインのリポジトリにpushしてチェックしてもらうんだから

799(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil) [sage] 2023/08/19(土) 15:41:12.22 ID:Af/nXbF+0(4/10) AAS
>>793
ぜんぜん分かってないな。例を挙げると

A機能の追加
A機能のバグ修正
B機能の追加
A機能の変数名変更
B機能のスペルミス修正
C機能の追加
B機能のアルゴリズム変更
A機能のバグ修正
A機能とC機能の共通部分のくくり出し
共通部分を使うようA機能を変更
共通部分を使うようC機能を変更
C機能の拡張
C機能のコメントのタイポ修正
不要になったB機能の削除
A機能のコード整理

という作業を1日に手元でやって、15回のコミットがローカルブランチに入ってるとして、これを共有前に

共通部分の追加
A機能の追加
C機能の追加

という3回のコミットに直して、それぞれに丁寧なコミットログ書いて、こっちだけを共有するんだよ。他の人がレビューしたり再利用する時間が大幅短縮できる。
git ならコマンド1つでこの「直し」ができる。これをやらないのは、他人の時間を湯水のように使っても許されると思ってるバカだけ。
他でもやるべきだが、git みたいにコマンド一発とはいかないので超面倒。結局ぐちゃぐちゃなのが共有されたりする

883(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 0fe6-mbMR) [sage] 2023/09/21(木) 08:55:56.61 ID:PwcZbKtJ0(1) AAS
>>881-882
trunk/branches/tagsのパターンで運用していたもの向けのスクリプトとか、
git-svnで変換したものに対する手動移行の方法とか、どこかで紹介されていませんかね