アカウント名:
パスワード:
理解できないソースコードの品質がわかるものなのだろうか?
ある一定レベルに達しているコードなら能力が不足しているから理解できなかった可能性もありそう。どんなコードなのか見てみたい。
こういう問いが出てくる時点で、ソフトウェア品質の内部品質の理解が元ネタの雑魚エンジニア氏に遠く及ばないのは確定だね。日本では珍しい事では無いが。
内品は日本では人気がないからねえ、このようにだからじゃないかな、日本の業界が遅れてると言われるとか雑魚扱いされているとかの理由は
品質が低いから理解できないというのも同感できない
俺に理解できないから品質の低いコードだと言ってるからなこのブログもちろん理解にしにくいコードだったんだろうが、それを「品質が低い」「こうしたほうがいい」とかいきなり先輩に言ってたらそりゃ顰蹙買うよねっていうそれでも先輩も「動き変わらないならやっていいよ」と言ってくれてんだけどな
でも、まあ、スラドのストーリーになるようなのにもあるでしょ。ループ使わずにコピペしてるやつとか。
例が悪いかも。リソースが無い中で高速転送なんかは同じ処理をコピペしてループチェックを少なくした方が高速化するよ。要は適材適所ってだけで、可読性重視とリソース重視で最善は異なるのでループ使わないから悪って事では無い。それこそタレコミの新人と同じ
まともなプログラマならそういう最適化をしたらコメントなりなんなりを残す気もする。
そのような最適化に関する情報はコメントではなくバージョン管理側に残してほしい
バージョン管理だけに実装に関するコメントを残すのはアンチパターンだよ。長く続いてるシステム見たことない人は知らないかもしれないけど、途中でバージョン管理が変わることだってあるんだよ。社内でSVN→Gitみたいなケースなら履歴も移行してもらえることも多いけど、特に会社間で担当が変わった場合とか、最終バージョンのソースだけが渡されて、履歴は失われることも多い。ソースの説明は、ソースに残さないとダメなんだ。
小さいプロジェクトならそれでいいかもしれないけど、多人数が関わってくると後から変数名だけ変えるみたいな変更で追うのが難しくなるから、ロジックに関することはちゃんとソースにコメントで残してもらわんと。
そのレベルの最適化なら今どきは普通にコンパイラに任せたほうが速くて安全。
品質が悪くて挙動を把握しきれない、という意味で言っているならそれはままあることですね。まあ当人が「雑魚」と免責して語ってる以上言語を操る能力は高くないのでしょう。
「我がコードは我流。我流は無形。故に誰にも読めぬ。」は誰の言葉だったっけ。#元ネタは雲のジュウザだが
ソースコードの品質は見ればわかるからな。
それこそ「作った本人にすら説明できない/挙動が把握できない」なんてのは典型的な糞コードの一つ。理解出来ないコードは改良もデバッグもできないし、最低なコードだよ。
そこかなぁ。
よくわかんないからリファクタリングしましょうとか初手で言われると、ヤバイ予感抱いてしまう。「機械学習や数理最適化のアルゴリズムに詳しいわけでもない」ならなおのこと。 コードの綺麗さってのはマンガで言えば絵の綺麗さで、それは成功の必要条件でもないしもちろん十分条件でもないからなぁ。いやもちろんきれいに越したことないけど。ベンチャーなんで保守性とかなおさら優先度低いし。
元の記事を読めば品質の意味はだいたいわかるだろ。機械学習ののコードは元のアルゴリズムや数式がわかってる必要があるし、メモリや速度の工夫、よくわからないがこれをやると精度があがったり安定したるするなんてのもあって、適当なドキュメントが無いと処理は終えても意味はまったく理解できんぞ。
今時はコードの品質を数値化してくれるツールがあるよ。見るだけで品質はわかる。
動かなくてもきれいに書いてありゃ品質高いからなそんな一部でだけ通じるような品質がすべてのように語るから受け入れられにくいんでしょコードには他にも作るのが早い、動作が早いなといろんな評価点があるんだからメンテナンス性とか言えばまだマシだったのにね
Pythonという言語はその性質としてコードが理解しやすくきれいになるものと聞いていたが。
Perlと比べればね。
読みやすいコードって品質が高いコードだよね。
でも、品質が高いコードだから読みやすいとも限らない。
読む人のスキルを大幅に越えていて読めないこともある。
C言語時代、Cで書いてあるのにCには見えない。と思ったら、Cのソースコードの中に機械語が書かれていた。ハードの性能をフルに引き出すために、コンパイラに任せずに機械語で書いた処理を直接メモリやレジスタにセットするコードにしてあった。(もちろん全体ではなく部分的にだが)
今はそんな限界に挑戦みたいなコーディングしなくてもハードの性能が余裕になった。
品質が悪くて読めないコードというのは、明らかに見てわかる。分かりにくくて読めないし、品質が低くて間違ってるから意味不明なコードになっていることもある。いわゆる「スパゲッティ」だ。
どんなコードがスパゲッティなんだよ?って聞かれて説明しようにも、スパゲッティだから説明も難しい。
ハードもなんだけど、実際としては計算機リソースが増大した結果コンパイル時の最適化に頼った方が早くなるので人間が頑張る必要がなくなったのよだから、素直に処理書けば大体コンパイラの最適化処理で早くなる
間違ってるのであれば仕様を満たしていないし、仕様を満たしているのであれば間違っていないので間違ってることをスパゲティの条件に入れることは間違っている
謎解きのようなコードならあり得るかも知れないかな?昔の特別な工夫したコードならないとも言えないけどそれを今風の大富豪が書いたコードになおしてめちゃくちゃ遅くなったことあったけどw
最近のトレンドのコードの書き方しか知らないと書き直そうとか簡単に言うんだよねそれしか知らないから仕方ないのかも知れないけど
この話、新人あるあるネタですね。
書籍のコードが最善であって、書籍のコードと違う実装がしてあると間違っていると言い出す。中には書籍が間違っていた事もあるのだけど、その可能性すら理解出来ずに「書籍に書いてあった」と強弁するだけの新人はよくいる。
最近の挫折未経験の若い衆が体験した初めての挫折・・・みたいなふうに読めた。自分が理解できない原因を外側に求めて自分は悪くない!と。そりゃ鬱にもなるだろうさ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
ソースコードの品質が低く理解できず (スコア:1)
理解できないソースコードの品質がわかるものなのだろうか?
ある一定レベルに達しているコードなら能力が不足しているから理解できなかった可能性もありそう。
どんなコードなのか見てみたい。
Re:ソースコードの品質が低く理解できず (スコア:1)
理解できないソースコードの品質がわかるものなのだろうか?
こういう問いが出てくる時点で、ソフトウェア品質の内部品質の理解が元ネタの雑魚エンジニア氏に遠く及ばないのは確定だね。
日本では珍しい事では無いが。
Re:ソースコードの品質が低く理解できず (スコア:1)
内品は日本では人気がないからねえ、このように
だからじゃないかな、日本の業界が遅れてると言われるとか
雑魚扱いされているとかの理由は
Re: (スコア:0)
品質が低いから理解できないというのも同感できない
Re:ソースコードの品質が低く理解できず (スコア:1)
俺に理解できないから品質の低いコードだと言ってるからなこのブログ
もちろん理解にしにくいコードだったんだろうが、
それを「品質が低い」「こうしたほうがいい」とかいきなり先輩に言ってたらそりゃ顰蹙買うよねっていう
それでも先輩も「動き変わらないならやっていいよ」と言ってくれてんだけどな
Re: (スコア:0)
でも、まあ、スラドのストーリーになるようなのにもあるでしょ。ループ使わずにコピペしてるやつとか。
Re: (スコア:0)
例が悪いかも。
リソースが無い中で高速転送なんかは同じ処理をコピペしてループチェックを少なくした方が高速化するよ。
要は適材適所ってだけで、可読性重視とリソース重視で最善は異なるのでループ使わないから悪って事では無い。
それこそタレコミの新人と同じ
Re: (スコア:0)
まともなプログラマならそういう最適化をしたらコメントなりなんなりを残す気もする。
Re: (スコア:0)
そのような最適化に関する情報はコメントではなくバージョン管理側に残してほしい
Re:ソースコードの品質が低く理解できず (スコア:2, 興味深い)
バージョン管理だけに実装に関するコメントを残すのはアンチパターンだよ。
長く続いてるシステム見たことない人は知らないかもしれないけど、途中でバージョン管理が変わることだってあるんだよ。
社内でSVN→Gitみたいなケースなら履歴も移行してもらえることも多いけど、特に会社間で担当が変わった場合とか、最終バージョンのソースだけが渡されて、履歴は失われることも多い。
ソースの説明は、ソースに残さないとダメなんだ。
Re: (スコア:0)
小さいプロジェクトならそれでいいかもしれないけど、多人数が関わってくると後から変数名だけ変えるみたいな変更で追うのが難しくなるから、ロジックに関することはちゃんとソースにコメントで残してもらわんと。
Re: (スコア:0)
そのレベルの最適化なら今どきは普通にコンパイラに任せたほうが速くて安全。
Re: (スコア:0)
品質が悪くて挙動を把握しきれない、
という意味で言っているならそれはままあることですね。
まあ当人が「雑魚」と免責して語ってる以上
言語を操る能力は高くないのでしょう。
我がコードは我流。我流は無形。故に誰にも読めぬ (スコア:0)
「我がコードは我流。我流は無形。故に誰にも読めぬ。」は誰の言葉だったっけ。
#元ネタは雲のジュウザだが
ソースコードの品質は見ればわかるからな。
それこそ「作った本人にすら説明できない/挙動が把握できない」
なんてのは典型的な糞コードの一つ。理解出来ないコードは改良も
デバッグもできないし、最低なコードだよ。
Re: (スコア:0)
そこかなぁ。
よくわかんないからリファクタリングしましょうとか初手で言われると、ヤバイ予感抱いてしまう。
「機械学習や数理最適化のアルゴリズムに詳しいわけでもない」ならなおのこと。
コードの綺麗さってのはマンガで言えば絵の綺麗さで、それは成功の必要条件でもないしもちろん十分条件でもないからなぁ。
いやもちろんきれいに越したことないけど。
ベンチャーなんで保守性とかなおさら優先度低いし。
Re: (スコア:0)
元の記事を読めば品質の意味はだいたいわかるだろ。
機械学習ののコードは元のアルゴリズムや数式がわかってる必要があるし、メモリや速度の工夫、よくわからないがこれをやると精度があがったり安定したるするなんてのもあって、適当なドキュメントが無いと処理は終えても意味はまったく理解できんぞ。
Re: (スコア:0)
今時はコードの品質を数値化してくれるツールがあるよ。
見るだけで品質はわかる。
Re: (スコア:0)
動かなくてもきれいに書いてありゃ品質高いからな
そんな一部でだけ通じるような品質がすべてのように語るから受け入れられにくいんでしょ
コードには他にも作るのが早い、動作が早いなといろんな評価点があるんだから
メンテナンス性とか言えばまだマシだったのにね
Re: (スコア:0)
Pythonという言語はその性質としてコードが理解しやすくきれいになるものと聞いていたが。
Re:ソースコードの品質が低く理解できず (スコア:1)
Perlと比べればね。
Re: (スコア:0)
読みやすいコードって品質が高いコードだよね。
でも、品質が高いコードだから読みやすいとも限らない。
読む人のスキルを大幅に越えていて読めないこともある。
C言語時代、Cで書いてあるのにCには見えない。と思ったら、Cのソースコードの中に機械語が書かれていた。
ハードの性能をフルに引き出すために、コンパイラに任せずに機械語で書いた処理を直接メモリやレジスタにセットするコードにしてあった。(もちろん全体ではなく部分的にだが)
今はそんな限界に挑戦みたいなコーディングしなくてもハードの性能が余裕になった。
品質が悪くて読めないコードというのは、明らかに見てわかる。
分かりにくくて読めないし、品質が低くて間違ってるから意味不明なコードになっていることもある。
いわゆる「スパゲッティ」だ。
どんなコードがスパゲッティなんだよ?って聞かれて説明しようにも、スパゲッティだから説明も難しい。
Re: (スコア:0)
ハードもなんだけど、実際としては計算機リソースが増大した結果
コンパイル時の最適化に頼った方が早くなるので人間が頑張る必要がなくなったのよ
だから、素直に処理書けば大体コンパイラの最適化処理で早くなる
間違ってるのであれば仕様を満たしていないし、仕様を満たしているのであれば
間違っていないので間違ってることをスパゲティの条件に入れることは間違っている
Re: (スコア:0)
謎解きのようなコードならあり得るかも知れないかな?
昔の特別な工夫したコードならないとも言えないけど
それを今風の大富豪が書いたコードになおしてめちゃくちゃ遅くなったことあったけどw
最近のトレンドのコードの書き方しか知らないと書き直そうとか簡単に言うんだよね
それしか知らないから仕方ないのかも知れないけど
Re: (スコア:0)
この話、新人あるあるネタですね。
書籍のコードが最善であって、書籍のコードと違う実装がしてあると間違っていると言い出す。
中には書籍が間違っていた事もあるのだけど、その可能性すら理解出来ずに「書籍に書いてあった」と強弁するだけの新人はよくいる。
Re: (スコア:0)
最近の挫折未経験の若い衆が体験した初めての挫折・・・みたいなふうに読めた。
自分が理解できない原因を外側に求めて自分は悪くない!と。
そりゃ鬱にもなるだろうさ。