この前の「プログラミングができるとは＞＜」の話の時も、最初にisanaさんのツイートの引用してたら逆に簡潔で済んだのかも＞＜；
オレンジが説明下手すぎるパターンで、その部分は当たり前だよね＞＜とかよく知られてるよね＞＜って思いこんでて、オレンジの標準的には短く書いた部分が、「それちがくない？」ってなって、その部分説明するのに数時間かかる現象、どうしたらいいのかわからない＞＜
(結果的にそういう部分も根拠込みで全部説明した時の方が一回で済んで短いことがわりと・・・＞＜)
どんどん視力落ちてて、誤変換とかtypoにどんどん気づけなくなっててつらい＞＜
<オレンジが開発中で一部公開してる感じの音解析アプリのスペアナ部分、まだ試作品なので、"書き方はどう見ても手続き型"で、245行のひとつの巨大メソッドとして書かれてます＞＜；（本番コードじゃなくデザインの検討用のモックアップ（？＞＜；）だからだけど＞＜；）
orange
さんがブースト
手続き型からオブジェクト指向型に強引に移植されて、書き方はどう見ても手続き型で、1万行を超えるゴッドクラスや1000行を超えるモンスターメソッドなどを見たら自然と口から出ますよ。>BT
（ていうかオレンジ的には「それはそうだよね」になって「でも、某ボブ氏は・・・＞＜；」「うん（汗」みたいな会話を想定してた・・・＞＜）
ノーマンかニールセンが書いたものを引用すると意味が強く伝わるパターン・・・？＞＜；
（これ＞＜；
https://mstdn.nere9.help/@orange_in_space/100000112255200864
https://mstdn.nere9.help/@orange_in_space/100000117427431230
(x度も oでも)）
基本的に手っ取り早さ的にはそうかも＞＜；
一方で、わかんなかった側もどうしてわかんなかったのかわかんないくらいのある意味小さな問題って、だからこそ自分でも発見しづらくてその時に検証しないとわかんなかったりする・・・と言う意味では貴重ではあるかも＞＜
orange
さんがブースト
それは間違いなくそうなんですが、その「ここがわからなかった」をはっきり説明できる人と説明できない人とで、どちらが問題解決が迅速かつ効率的かといえば、おそらく前者なので
本の予算の都合でオレンジはまだ読んでない本だけど、よく名前を聞く本で言うと、
O'Reilly Japan - リーダブルコード https://www.oreilly.co.jp/books/9784873115658/
みたいな感じでちゃんと書けているか？＞＜を検証するのに、自分だけで考えるよりも、「あなたが書いたもの作ったものでここがわけわからなかったです・・・」って人をサポートすると、より手っ取り速いですよって言いたい・・・＞＜
そうじゃなく自分のコードを読んだ人が🤔ってなってるのをサポートするとどうマズく書いたのかに気づけるよ的な事が言いたい・・・＞＜
orange
さんがブースト
クソコードを読んだところで書かないように改善されるかというとうーんですよ
ものすごくものすごく雑に言うと、不親切なコード＝スパゲティコード だよって言いたい・・・＞＜
orange
さんがブースト
まあ命名がロクでもないものも沢山見たことがあるけど、「ロクでもないと思うならパッチを投げてみろ」とかそういう世界だよなぁという感想しかないので、あくまでユーザはオマケでしかなくて(←言葉が悪い)、対等に意見を言いたいならあなたも開発者ステージに来てください、という気持ち
そういうことじゃなく、書く側のスキルが上がるよみたいな事が言いたい・・・＞＜
（言い方を変えると、読めないような酷いコードを書かないようになるスキル（の一部）かもみたいな＞＜）
orange
さんがブースト
結局この「自分でやれよ」を連結させて自分を最優先で世界を良くしていこうというのも OSS のひとつの姿だと思うので(そうでないプロジェクトが多いのもわかっているし、特に大規模なものは社会的な意義を重視しているように思うけど、それはそれ)
orange
さんがブースト
まあ不満なら「オレが使いづらいから使いやすくしてやったぜ感謝しろよ」みたいなパッチを投げてもらえれば、私がそれを良くないと判断しない限りにおいて受け入れますし(ただしそれは私が負いたいコストではないのであなたが実装してね、という)
orange
さんがブースト
結局、他人のプロジェクトを良くするのも自分のプロジェクトを書くのも、大抵は自分のためなんですよね。他人に公開するのは“おこぼれ”で世界が豊かになればいいと思っているからなので、他人に使ってもらうことは重要な目的とは捉えていない
- ＠orange_in_space
2017年 4月に登録
