ていうか、その時点で対策すべき事象(＝旅客への案内上必要な情報)としては、単に人身事故であって、自殺であろうが極端に言うと突き落とし殺人事件であろうが、それを検証等をするのは別レイヤの話であって、あくまでその時点で対策すべき事象(＝旅客への案内上必要な情報)としては、単に人身事故かも＞＜(冗長な文章＞＜；)
orange
さんがブースト
「人身事故」って言った場合、単に人と列車とがぶつかった（あるいはぶつかりそうになった）ってだけなので、必ずしも自殺とは。
酔っ払いが線路に落ちたとか、ベビーカーとかを挟んだまま発車してしまったとかも人身事故のはず。
この前の「プログラミングができるとは＞＜」の話の時も、最初に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_in_space
2017年 4月に登録
