アカウント名:
パスワード:
ソースコードの品質が低く理解できず、またこのままでは問題があると思い
これが諸氏もよく話題にする「よくわからないけど動いてるコード」ってやつか。
「本番運用中のコードを変えようとしたら挙動が変わらないことだけを願いますと言われるのは当たり前」
個人的にはこれが一番理由としてでかい。「動いてるものをわざわざいじって動かなくなったらどうすんの？いじる必要ある？」みたいな。そこに時間割くなら別のことしましょうという。
ぶっちゃけ、主体性の無いザコエンジニアさんなんだと思う。環境なんて渡されたのをそのまま使うよりまず自分の使いやすい環境をベースに作業を始めてだんだんとそこの環境に近づけていけば良いのだし、ソースコードが読めないのが品質が悪いとか、何を甘えたことを言ってるのかと。いじる必要があるんだだから当然読む必要があるわけで、読めよ。
まあ、変更の容易さを担保せずに本番を絶対的正義として技術的な負債が積まれるままになると、変更しづらさでにっちもさっちもいかなくなることが多いけどね。完全に塩漬けでいいならいいけど、運用されてるシステムってのは多少なりとも変更が発生するので。
変更に時間がかかって無事脱落のパターン
それを判断するのは新しく入った者ではなく、マネージャーの仕事だよ。何を長期運用するのか、何は捨てておいていいシステムか、判断する能力も権限も新人にはない。
「チームに入って初手リファクタリング提案は絶対ダメ」経営者や管理職として入ったならまだしも、一兵卒として入ったならその役割は求められていない。
うーん、機械学習ベンチャーでもこんなレベルなのか。挙動が変わらないのを運任せでお祈りするようなコードだから品質が低いと言われるんだが。
まあ、雑魚エンジニア氏もプロジェクト入る前にちょっとコード見せてもらうとか、まずUnitTesTとCIを導入しましょうとか穏便なところから入って、静的解析やリファクタリングの話を持ち出せばよかったのにね。
気を取り直して次いこ、次。
記事を読むと、件の先輩エンジニアは天才肌の人で、第三者の視点で考える能力が欠如しているケースに感じますね。同じ部内でそのコードが「正直私はあまり触りたくはないですね…」とか「（私が追加した）コメントがなかったら、何をやっているか本当にわからない」とか言われてることからも、この先輩個人か、その周囲の小さめのグループに関する話でしょうね。
まあ、院まで行って論文たくさん書かなきゃいけなくなるとコードのメンテより論文のネタ、になるからね。そのままの感覚で仕事してればそうもなるよね。つまるところ、他人は自分じゃないから、経験もそれに伴う考え方も違う。
経験を前向きに活かしてほしいものです。
理解できないのに、どうしてリファクタリングできるのか。単体テスト環境作ろうって提案するのが先な気がする。
テスト作るにしても、何を持って正しいとするかもわかんないよね。
このままでは機械学習エンジニアがコードを理解できず機械学習の仕事を進められないので、「私」はいじる必要を感じたけど、その必要性について周りとうまく合意できなかったって感じかな。そもそも誰がリファクタリングするの？っていうリソースの問題もあるだろうし。ありもので何とかしろってのは仕事ではよくあること。
違う違う。
いわゆる「よくわからないけど動いてるコード」ってのはプログラマ本人が理解できてないけど動いてるときに使う。スリープ（待機命令＝待ち時間）入れたとこで挙動は変わらないはずなのになぜかスリープ入れると安定して動くとかそういうタイプ。
今回のはほかのプログラマが書いたコードが読めないってだけだから違う。
君の方が違うよ。ソース読んできなよ。
自分で書いたコードじゃない。
ソースコードをクローンして、読み始めました。すると「？」となりました。どうも全くソースコードの意味が分からないのです。その当時は「僕のコード読解力が足りないせいで読めないんだ…」と思い、かなり落ち込んでいました。しかし休職してからある本と出逢いました。それが以下の本になります。
私でいえば「コードの保守性・運用性(=長期的な課題解決)」を重視すべきと考えているため、コードの綺麗さや意図を伝えようとする努力に対して高い期待値を持っています。それが低い状態で運用されているのを見ると、修正したくなってしまってしょうがないのです。 しかし、逆に先輩は「アルゴリズムによる(目先の)課題解決」を重視されている方だったのです。
「最初は自分のせいだと思ってたけど、この本に出会って気づいた。悪いのは自分じゃない。ほかの奴らだ！」よくいる意識高い系のお話しだよ。
元コメが本人と言っているのは先輩エンジニア氏のことだ。チャットで自分でもわからんと言ったという記述がブログにある。
# この業界に鬱が蔓延するのも無理ないきがする、これが+2モデか。
自分でもわからんと言ったなんてことにはどこにも書かれてないぞどこ読んでる?他の先輩がわからんと言った、というのならあるが
> 「このコードは挙動が変わらないことを保証できなかったから、いじれなかっただけなんだ」これでしょ
動作が変わらないことを保証するってのは単に理解してるだけじゃできないってことがわからんやつだってことかまぁ若いうちはあるけどねそういうのこのブログ主の類似求人タイプか
記事読んだけど何かまぁそんな立ち回りじゃそうなるよなっていう感じ
リスクベネフィットもろくに提案せず「キレイがいいからキレイにしましょう」じゃなぁキレイが良いと強く思ってりゃ最初からそんなコードにゃならんのよ
しかも強く断られたわけでもなく難色を示された程度で…損で大したことできなかったらかと評価が低かったと。そらしゃーないでしょ。
挫折したことなかったのかたまたま体調悪かったんかもしれんな
＞チームメンバーには受け入れらずこの部分が重要で、リファクタリングする必要性がそもそも無かったんでしょうね。チームへの貢献として、ソースの可読性チェックだけするような人なんて邪魔でしか無いからね。
構造的な問題を指摘した上で構造変更する必要性を訴えるならまだしも、だったらそもそもリファクラリングの必要すら無い。
話に挙がってる開発者はコード見るだけのために雇われた訳じゃないはずなので、変更のしづらさや変更量の多さ等を盾ににリファクタリング提案できなかったのであれば、ある意味最適化されているコードなのかもしれない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
リファクタリングの必要性 (スコア:0)
これが諸氏もよく話題にする「よくわからないけど動いてるコード」ってやつか。
個人的にはこれが一番理由としてでかい。
「動いてるものをわざわざいじって動かなくなったらどうすんの？いじる必要ある？」みたいな。
そこに時間割くなら別のことしましょうという。
Re:リファクタリングの必要性 (スコア:3, 興味深い)
ぶっちゃけ、主体性の無いザコエンジニアさんなんだと思う。
環境なんて渡されたのをそのまま使うよりまず自分の使いやすい環境をベースに作業を始めてだんだんとそこの環境に近づけていけば良いのだし、ソースコードが読めないのが品質が悪いとか、何を甘えたことを言ってるのかと。いじる必要があるんだだから当然読む必要があるわけで、読めよ。
Re:リファクタリングの必要性 (スコア:2)
よくわからないけど、工場出荷検査では動いているコードを本番運用にぶっこむと、他のクエリの結果が印刷され・・・
Re: (スコア:0)
まあ、変更の容易さを担保せずに本番を絶対的正義として技術的な負債が積まれるままになると、変更しづらさでにっちもさっちもいかなくなることが多いけどね。
完全に塩漬けでいいならいいけど、運用されてるシステムってのは多少なりとも変更が発生するので。
Re: (スコア:0)
変更に時間がかかって無事脱落のパターン
Re: (スコア:0)
それを判断するのは新しく入った者ではなく、マネージャーの仕事だよ。
何を長期運用するのか、何は捨てておいていいシステムか、判断する能力も権限も新人にはない。
「チームに入って初手リファクタリング提案は絶対ダメ」
経営者や管理職として入ったならまだしも、一兵卒として入ったならその役割は求められていない。
Re: (スコア:0)
うーん、機械学習ベンチャーでもこんなレベルなのか。
挙動が変わらないのを運任せでお祈りするようなコードだから品質が低いと言われるんだが。
まあ、雑魚エンジニア氏もプロジェクト入る前にちょっとコード見せてもらうとか、
まずUnitTesTとCIを導入しましょうとか穏便なところから入って、静的解析やリファクタリングの話を持ち出せばよかったのにね。
気を取り直して次いこ、次。
Re:リファクタリングの必要性 (スコア:1)
記事を読むと、件の先輩エンジニアは天才肌の人で、第三者の視点で考える能力が欠如しているケースに感じますね。
同じ部内でそのコードが「正直私はあまり触りたくはないですね…」とか「（私が追加した）コメントがなかったら、何をやっているか本当にわからない」とか言われてることからも、この先輩個人か、その周囲の小さめのグループに関する話でしょうね。
Re: (スコア:0)
まあ、院まで行って論文たくさん書かなきゃいけなくなるとコードのメンテより論文のネタ、になるからね。
そのままの感覚で仕事してればそうもなるよね。つまるところ、他人は自分じゃないから、経験もそれに伴う考え方も違う。
経験を前向きに活かしてほしいものです。
Re: (スコア:0)
理解できないのに、どうしてリファクタリングできるのか。
単体テスト環境作ろうって提案するのが先な気がする。
Re: (スコア:0)
テスト作るにしても、何を持って正しいとするかもわかんないよね。
Re: (スコア:0)
このままでは機械学習エンジニアがコードを理解できず機械学習の仕事を進められないので、「私」はいじる必要を感じたけど、その必要性について周りとうまく合意できなかったって感じかな。そもそも誰がリファクタリングするの？っていうリソースの問題もあるだろうし。ありもので何とかしろってのは仕事ではよくあること。
Re: (スコア:0, オフトピック)
違う違う。
いわゆる「よくわからないけど動いてるコード」ってのはプログラマ本人が理解できてないけど動いてるときに使う。
スリープ（待機命令＝待ち時間）入れたとこで挙動は変わらないはずなのになぜかスリープ入れると安定して動くとかそういうタイプ。
今回のはほかのプログラマが書いたコードが読めないってだけだから違う。
Re: (スコア:0)
君の方が違うよ。
ソース読んできなよ。
Re:リファクタリングの必要性 (スコア:4, 参考になる)
自分で書いたコードじゃない。
ソースコードをクローンして、読み始めました。すると「？」となりました。どうも全くソースコードの意味が分からないのです。その当時は「僕のコード読解力が足りないせいで読めないんだ…」と思い、かなり落ち込んでいました。しかし休職してからある本と出逢いました。それが以下の本になります。
私でいえば「コードの保守性・運用性(=長期的な課題解決)」を重視すべきと考えているため、コードの綺麗さや意図を伝えようとする努力に対して高い期待値を持っています。それが低い状態で運用されているのを見ると、修正したくなってしまってしょうがないのです。 しかし、逆に先輩は「アルゴリズムによる(目先の)課題解決」を重視されている方だったのです。
「最初は自分のせいだと思ってたけど、この本に出会って気づいた。悪いのは自分じゃない。ほかの奴らだ！」
よくいる意識高い系のお話しだよ。
Re: (スコア:0)
元コメが本人と言っているのは先輩エンジニア氏のことだ。
チャットで自分でもわからんと言ったという記述がブログにある。
# この業界に鬱が蔓延するのも無理ないきがする、これが+2モデか。
Re: (スコア:0)
自分でもわからんと言ったなんてことにはどこにも書かれてないぞ
どこ読んでる?
他の先輩がわからんと言った、というのならあるが
Re: (スコア:0)
> 「このコードは挙動が変わらないことを保証できなかったから、いじれなかっただけなんだ」
これでしょ
Re: (スコア:0)
動作が変わらないことを保証するってのは単に理解してるだけじゃできないってことがわからんやつだってことか
まぁ若いうちはあるけどねそういうの
このブログ主の類似求人タイプか
Re: (スコア:0)
記事読んだけど何かまぁそんな立ち回りじゃそうなるよなっていう感じ
リスクベネフィットもろくに提案せず「キレイがいいからキレイにしましょう」じゃなぁ
キレイが良いと強く思ってりゃ最初からそんなコードにゃならんのよ
しかも強く断られたわけでもなく難色を示された程度で…
損で大したことできなかったらかと評価が低かったと。そらしゃーないでしょ。
挫折したことなかったのか
たまたま体調悪かったんかもしれんな
Re: (スコア:0)
＞チームメンバーには受け入れらず
この部分が重要で、リファクタリングする必要性がそもそも無かったんでしょうね。
チームへの貢献として、ソースの可読性チェックだけするような人なんて邪魔でしか無いからね。
構造的な問題を指摘した上で構造変更する必要性を訴えるならまだしも、だったらそもそもリファクラリングの必要すら無い。
Re: (スコア:0)
話に挙がってる開発者はコード見るだけのために雇われた訳じゃないはずなので、変更のしづらさや変更量の多さ等を盾ににリファクタリング提案できなかったのであれば、ある意味最適化されているコードなのかもしれない。