リファクタリング
「このコードは既に十分に綺麗だから、（コメントは追加してもいいけど）リファクタリングする必要はない」" 一生リファクタリングしている自分とは仲良くなってくれなさそう。
Kumappus とはいえ、このnote書いた人とも打ち解けられそうにない…なんというかこう、もう少し中間的な柔軟な人でないと相手のメンタル壊しちゃいそうで… voluntas マジレスすると、まずテストを書き始めるところからやったらいいのにと思いました。テストとリファクタリングは政治力が必要ってのを知らなかったんでしょうね … 。 voluntas 信頼があっても利益に直結しないから厳しい反応されることが多い気がする。 どっちの言い分もわかるけど、つまるところ立ち回りですよね。。
hrjn 人生の中でリファクタリング議論無限にやってるけど、保守性拡張性は本当に保守性拡張性が問題になっているのかを考えてほしいなーと思うことはある。 滅多にいじらないであろうコードのリファクタしたところで得られる効用が低いわけでなー。
hrjn というあたりの議論をきちんとしてあげたら良かったのではとは思うな。。。 hrjn こういうの「ベンチャー向きの人ではない」で済まされがちだけど、きちんと議論してあげられるほどの能力が自分たちにないというのが原因のほとんどだと思うので相手を指して無能と呼ぶのはよくないかなとは思う。 hrjn というより、なんであれ採用した人がワークしなかった時のコストについては自分たちが深く反省すべきなんだよ。 だって金と人材を適切に使えなかったって話だよねそれ。それ、採用する資格もなければ人を使う資格もないよ。
hrjn メンバレベルならともかく管理職レベルで言わんやシニアレベルであれば「あいつはベンチャー向きじゃない」とか言っても無意味なんだよ。 いうなら「当社向きの人でないことを見抜けなかった自分や組織を悔やむ」だよ。それですら「一定退職を見込んで予算組んでます」くらいの説明できて然るべきで。
hrjn 最終的にそういう全てを織り込んで、自社の採用ブランド力とか給与競争力とかも包括的に考えて、"問題ないことを担保する"のがシニアマネジメントの仕事であって、そんな個別の向いてる向いてないとかでいちいち他人のせいにしなさんなという気持ちにしかならない。 yuiseki_ 新しく参加したチームでいきなりリファクタリングするの、私はどう動くのが正しいのか深く知らないソフトウェアを弄くり回して破壊したいです！って言ってるようなものでアンチパターンです yuiseki_ 新しくチームに参加したメンバーにGood first issueの一つも示していないのはチームの側にも大きく問題があると感じる。一番オススメの立ち回りは、徹底的に触ってみてソフトウェアの期待される挙動を把握しつつ、明らかにバグっている所を探して再現手順をまとめて報告、そして再現しないように直す tadsan 僕は知らないコードベースを習熟するために気の済むまで自分の好きなようにリファクタリングを試みてぶっ壊してみて、なぜ既存コードがそうなってないのか理想と現実の距離をはかってみたりする(マージすることは期待しない)のでなるほどなと思った tadsan そういう習熟目的を除けば、リファクタリングは無闇にやるんじゃなくて何を改善したいのか目的をはっきりさせないと独りよがりに終わるというのはある。 @zick_minoh: 「ソースコードがよく分からないのでリファクタリングしたい」は危険信号で、よく分かってない人がやるとロクなことにならない。別の方向性の酷さを再生産をしかねない。ソースコードをしっかり理解した上でどの箇所が特に酷いか、それを直したらどんなメリットがあるのか具体的に説明できてほしい。 wtnabe 雑魚エンジニアの話、「初手リファクタリングは悪手」って意見多いように見えるけど、「何してるか読み取るのに時間が掛かる」状況は間違いなく「コードが業務を阻害してる」ので、詰まっている状況が本人由来かコード由来かを切り分けてないのは上司の怠慢だと思うんよな。 wtnabe コードに手を加えなくても辞書やカタログのような何かでもよい。開発のリードタイムを悪化させる要素がプロダクト内にある、という状況を放置してるのは組織側、上司側の責任だと思う。メガベンチャーと呼べる状態ならもう個の記憶力に頼っちゃダメなんよ。 wtnabe 典型的な優秀なプレイヤーと優秀なマネージャーの話でもあるよなぁ。もちろん当人同士の合う合わないはあるけど、仮にもメガベンチャーなのであればこの辺の適性の話はさすがに組織、人事側に何らかの取り組みがあってよさそう。むしろベンチャーより中小の方が人がいない問題でありがちじゃないか。 wtnabe 上司にメンター、コーチがいないんだろうなぁ（おれもめっちゃ欲しい）。腕で黙らせちゃってるとこの辺がうまく分離、移譲できないってのはありそう。 sugimoto_kei 僕なら、既存のプロジェクトに入ったら、既存メンバーたちにどう貢献できるか、まず考える。全然わからなければ、議事禄係や雑用係。その上で貢献分野を増やしていく。自分が読めないからといって、他の人は読めているコードを直していたら、見放されるのは当たり前だよ。 sugimoto_kei 状況には同情するけれど、相手の視点から見てどう見えていたのか、もう少し考えなければ、同じことを繰り返しそうな気がするよ。 例えば「目的意識がない」と先輩が言ったとき、「目的」とはなんだったのか。この方の目的ではなくチームの目的に決まっていると思うのだけど。
@kumagi: ソースコードを理解できないのは背後の文脈を知らなくて書いた側のメンタルモデルを自分の中に構築しそこねてたから。 リファクタリングに理解が得られないのは変更後の構造について合意を得るステップを怠ったから。
辞めるに至ったのは思い通りに行かない理由が自分にあると勘違いしたから。
@tanakahisateru: いくら一般的なスキルが高い経験者を雇っても、業務固有の事情をコメントなしのコードから読み取る能力は新人と同じだけしかないから、そんなのに優秀な人としての待遇で雇った人材のコストが消えていくのは無駄、っていうのよく言ってる。この問題に無頓着なエンジニアを上役にするのは組織管理の失敗 「SQLやPythonコードにほとんどコメントが見られない。」「適切な粒度による関数の切り出しが行われていない。」「Pythonコードに docstring や型ヒントが一切ついておらず」
@kiyuzu: これ、研究畑を歩いてきた人には多くて、Fortran、R、Pythonあたりで非常に良くあるパターン。 大抵の場合、元論文とか書籍とかがREADMEとかgitとか別の階層に有って、それは読んでる前提で書いてある。
逆に読んでなきゃコードから思い付けるわけがないと思ってるから書かない。
聞いたら出てくる。
リファクタリングの記事に関する有益そうな感想をPolisにしました