ただ一つ言えるのは、ミスマッチだったという事なんだろうなあ
— コケピー (@sasanquaneuf_) May 20, 2023
リファクタリングが"必要"かというと、コストとリスクを考えないと判断できないので、外部の立場だと要否はわからない
自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc #note https://t.co/8qgtFOjon0
---
組織としての問題
社内の好きなプロジェクトに取り掛かっていいよっていうのはつまり、現在のタスクを管理して適切に作業者に割り振る管理職の不在なんだよな。https://t.co/PYaGPDWaiQ
— 江添亮@足首靭帯の手術から6週間 (@EzoeRyou) May 20, 2023
「もしかしてオレ… 地位はあるけどその実社内で誰も相手したがらない系の、厄介ベテランおじさんの当て馬にされたんじゃね? Slackでコード見せてあの反応って…」という社内政治的な分析まで行けなかったのが、鬱になるまで逃げ道を塞ぐ失敗になった、なんですけど、初手でそんなんできるヤツおる?
— ひさてるさん (@tanakahisateru) May 21, 2023
雑魚くんの方に問題性を見いだしたがる反応あるの、合理的にロジックが組める職種なのに通しで問題点を認識できない人がいるの、ほんと不自然だなあと思ってて。もしかしてなんだけど、いじめっ子の味方側にいる子が、自己弁護のために詭弁を持ち出すあれなのかなって気持ちになっている
— ひさてるさん (@tanakahisateru) May 21, 2023
社内でもとくに可読性が低くて、引き継ぎに適さないコードの保守に、新人をアサインするって時点で、まず最初の間違いでしょ。で、彼がぱっと見で読めなかったのは、彼以外でも起きることだろう。ここが保守コストの損失だと認識できた。どう書けば初見で読みやすいのかも言ってくれた… だよね?
— ひさてるさん (@tanakahisateru) May 21, 2023
---
組織の成長に伴うフェーズの切り替わり
汚いコードの世界に入った新人が鬱になった話、手のかかる新人を自分の仕事優先タイプのメンターが放置して壊したよくある話を被害者が合理化してる結果読解が難しいけど、基本的にはメンター側が組織の変化についていってないのだと思うが、組織が変わる時に合意が常にあるかというとどうだろう
— メキシコ産 (@fuba) May 21, 2023
「我々はこれから自発的に作業ができない人も採用することにします」という組織の変化が直前に行われたということをこれから採用される人たちに教えるわけはないのだろうけど、その人達の面倒をみるメンターがそれを知り意識を変えることができるのかというとできている組織がどれだけあるのだろう
— メキシコ産 (@fuba) May 21, 2023
初期にゴリゴリ作った人だということと、エンジニアとして立派な考え方を持っていて偉いということを、単純に同一視して人事をやってはいけないという話です。前線で戦果を上げたことと、指揮官としての視野とは、全く別の能力なので、戦果ベースでだけ昇進するのは、やばいですよね
— ひさてるさん (@tanakahisateru) May 20, 2023
自社開発ベンチャーにおいて、低スキルだけど初期に根性で活躍して評価されてる人を、後から入った、より高スキルなのに評価されない人が見たときのジレンマについては、もうすぐ発売される「レガシーコードとどう付き合うか」に書かれています https://t.co/mIbN0cEt7l https://t.co/u5RhYt1bMn
— ひさてるさん (@tanakahisateru) May 21, 2023
創業期のエンジニアへの期待値は、PMF するまでハイパフォーマンスに改善を繰り返すことを求められがちで、PMF 以後のエンジニアに求められるのは安定性とスケーラビリティ。技術的負債を作った創業期のエンジニアを貶すのは本質的ではないし、PMF 以後のエンジニアが評価されないのも本質的ではない
— めもりー (@m3m0r7) May 30, 2023
---
テスト書けっていう指摘多いけど、経験上だいたいこういうの設計から終わっててテスト書けないか、もしくはコスパ激悪になる気がする。もしくはテスト書ける範囲は別に辛さの根源ではない気がする。
— 統合開発環境@技術書典14（え09） (@sadnessOjisan) May 20, 2023
自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話 https://t.co/r7kkdPH4WE
腐海を見たことあるITエンジニアなら大体想像がつくと思うのですが、テストが存在しない大きいコードベースにはテスト実装を阻む魔物が潜んでいるのでそう簡単に勢いだけでテストは実装できないです。
— ノーン (@nkowne63) May 21, 2023
具体的には、以下のケースは見たことがあります
— ノーン (@nkowne63) May 21, 2023
- ORMや外部APIへの依存が切り離されておらず、再現コストが高い
- フロントや確率的挙動、複雑な仕様など、そもそもテストしづらい対象である
- 常に新規機能を追加する圧力に晒されており、改善コストを取れなかった
- チームにノウハウが存在しない
これは私の持論になりますが、このような状態は「コードそのものが周辺環境を変えてしまった」ことによる不適応というべきものであり、基本的にチームメンバーは誰も悪くないです。（むしろコードがワークしている証）
— ノーン (@nkowne63) May 21, 2023
なので粛々と問題点を洗い出し解決の手を打つのが良いと思います。
個人でできることを言うならば、リファクタリングによるビジネス的な価値をきちんと提示する、ということかな。
— ノーン (@nkowne63) May 20, 2023
リファクタリングはめちゃくちゃレバレッジが効くのでちゃんと計算するとかなり生産性は高い。
ビジネス価値が上がるほどレバレッジの効果によりリファクタリングの価値は上がる。（JTCで新規事業作るよりもコストカットしたほうが儲けやすいのも多分これ） https://t.co/WjiVrV1cCb
— ノーン (@nkowne63) May 20, 2023
つまり、「とにかく手を動かす」と「整理する」は共生関係にある。両方お互いがいないとそのうち死ぬ。
— ノーン (@nkowne63) May 20, 2023
マジレスすると、まずテストを書き始めるところからやったらいいのにと思いました。テストとリファクタリングは政治力が必要ってのを知らなかったんでしょうね … 。
— V (@voluntas) May 20, 2023
と言う何かを変えたいなら権力を手にせよ。が全てなので … 。
— V (@voluntas) May 20, 2023
パッと見価値がわからない/マイナスにすら見えることのある行為であるところのリファクタリングは特に政治臭が強いというのには大いに同意
— sksat (@sksat_tty) May 21, 2023
「着地すべきなのはたぶんここだが、少なくとも今の政治が許容しない（し、要件/技術的にも厳しい）ので一旦こっちに落としてから政治を曲げる」みたいなことをよく考える
— sksat (@sksat_tty) May 21, 2023
リファクタリングが必要なコード、そもそも適切なテストがないことが多いので、まずはリグレッションテストを整備するところから始めないといけない.......
— ふりふりモノトーン (@furifuri_mono) May 21, 2023
わかります。
— ふりふりモノトーン (@furifuri_mono) May 21, 2023
当初はバグだったんだけど、そのバグの挙動に依存した他のコンポーネントが作られてしまっているのでとりあえず仕様ということにしなければいけない挙動とかありますしね.....
リファクタリングの前にテストを書くべきって話は圧倒的に正しいんだけど、そもそもテストが書けるようなコードなら大幅なリファクタリングは必要ないのよね…
— Shinya Kato (@0x19f) May 20, 2023
テスト書けっていう指摘多いけど、経験上だいたいこういうの設計から終わっててテスト書けないか、もしくはコスパ激悪になる気がする。もしくはテスト書ける範囲は別に辛さの根源ではない気がする。
— 統合開発環境@技術書典14（え09） (@sadnessOjisan) May 20, 2023
自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話 https://t.co/r7kkdPH4WE
僕なら、既存のプロジェクトに入ったら、既存メンバーたちにどう貢献できるか、まず考える。全然わからなければ、議事禄係や雑用係。その上で貢献分野を増やしていく。自分が読めないからといって、他の人は読めているコードを直していたら、見放されるのは当たり前だよ。https://t.co/85oFxLxiat
— 杉本啓 (@sugimoto_kei) May 21, 2023
「学び」も少しズレていると思う。社内政治や信頼形成能力…
— 杉本啓 (@sugimoto_kei) May 21, 2023
支援して育成するというより、ふるいにかけているんだね。
— 杉本啓 (@sugimoto_kei) May 21, 2023
---
コミュニケーション
例の記事の話はさておき、弊社同僚が「名人さんのコード読みやすいんですけど、○○エンティティは振る舞いA/B/Cを有してるにしては不自然な設計ですよね。でも名人さんの実装当初はAしかなかったんで仕方ないですね。そのうち治したいです」って言った時はコミュニケーション完璧かと思いました
— 名人｜マナリンクCTO (@Meijin_garden) May 21, 2023
問題理解、背景理解、当時の担当者へのリスペクト…！
— 佐々木⋈和守 (@kazumori102) May 21, 2023
---
経営者「新機能開発進めて売上伸ばしたい！」
— ひさじゅ@Web系転職に強いプログラミングスクールRUNTEQ (@hisaju01) May 21, 2023
エンジニア「コード汚くて実装速度上がらない！リファクタしたい！」
この間に立って両者を納得させつつ、いい感じの落としどころを作るのがCTOのお仕事です。
あの Note の人は結局何のために雇われたのか最初から最後までよくわかんなかったよなぁ
— Shinya Kato (@0x19f) May 20, 2023
具体的にどういうタスクを任されてたのかもよくわかんなかったし
まぁでも実際に既存のプロジェクトに放り込まれてそこのコードと音楽性が合わなかったらどうすればいいのかは未だによくわからない
— Shinya Kato (@0x19f) May 21, 2023
プロジェクトの闇を満載した退職note書いてバズってTwitter転職
— あやせひろみ (@hiromi_ayase) May 21, 2023
私は日本でもそこそこ著名な会社ならLinux PC支給が当然でエンジニアの半分はLinux使用ぐらいになってると以前は思ってて、せいぜいUbuntuは知らないからDebianにできるか程度のことを心配してたが、蓋開けるとMacかWindowsと言われて呆然とした。修行だと思ってオープンソース担当だがMacを使っている https://t.co/G5ysCZAKkn
— Shuji Sado (佐渡 秀治) (@shujisado) May 20, 2023
提案させて却下を繰り返すのは学習性無力感にする簡単な方法
— masa@地方フリーランス (@voiprogramming) May 20, 2023
病んでもしゃーない https://t.co/tD8PByozUk pic.twitter.com/K9cJbKilbG
---
リファクタリングと政治
半年で休職→退職のnoteのコメント興味深いわ。「リファクタリングには政治力とか信頼がいる」みたいなツイートあって社会人12年目の今では首取れるぐらい分かる。
— 夏目葉太⛅️なつよさん (@infragirl755) May 21, 2023
自分も今の会社に入ったとき「リファクタリングやらせろ」とひたすら言い続けていた時期があったんだけど、「まずは信頼を勝ち取ってください」と言われて、すげー納得した。チームで働くってこういう事なんだな、と思った
— 寺本.hackforplay(); (@teramotodaiki) May 21, 2023
近視眼的であること(少なくともそのように周りから見えていること)に、本人が気づいてないのが問題なんだと思う
— 寺本.hackforplay(); (@teramotodaiki) May 21, 2023
まずは言われた通りやることで成果を出せて、成果を出すことで信頼が得られて、信頼を得ることで自分の意見を聞いて貰いやすくなる。一見遠回りのようにも見えて、実は必要な段階がある
（つづき）信頼を得ることで新たな仕事が舞い込み、チームに貢献できることが増えて、さらに信頼を得られる
— 寺本.hackforplay(); (@teramotodaiki) May 21, 2023
そして十分に信頼を勝ち取った頃には大量のタスクが自分のところへやってくるようになり、毎日忙しすぎてもはやリファクタリングどころではなくなっている、というのがこの話のオチ
このコードは汚いから保守性が悪い、リファクタリング必要という正論は技術的には非常に正しいが政治的には正しくないという話である。
— 暗黒美無王 dark Vim (@ShougoMatsu) May 21, 2023
Twitterで意見が割れるのは技術的正しさと政治的正しさが喧嘩してるからだ。
リファクタリングをしたいならそのビジネス価値を示すべきというの、リファクタリングをしない判断についても同じことが言える。バトルビジネス価値で勝負だ。
— トデス子'\ (@todesking) May 22, 2023
ほんまこれですわ。僕らのお賃金はクソコードで賄われてるんですよ。/糞コードは直すな。 - Qiita https://t.co/Y36ioLmQ5u
— botのおじさん。 (@SigmaEpsilonDe1) May 22, 2023
そう。一部だと思うが、エンジニアが政治力とかコミュニケーション力とか言いがちなのが、いつも気になる。例えば、大規模なリファクタリングの提案が受け入れられないのは、単に、提案が生煮えだったり今やるべきかわからなかったりで腑に落ちないからに過ぎない場合が多いと思う。政治とかじゃない。
— 杉本啓 (@sugimoto_kei) May 22, 2023
僕などは、政治とかコミュニケーションは苦手意識があるので、出来るだけそういうことに頼らずに、ファクトや数字、ロジックを用いて、相手が納得できるよう説明することを心がけている。そうした方が実務的だよ。
— 杉本啓 (@sugimoto_kei) May 22, 2023
文脈把握力とか提案力とか、もうちょっと粒度を下げて考えてみればいいのにそれをしないで抽象的な言葉で思考停止している人、散見されますね。
— ﾊﾟｲｾﾝ🍍 (@akimicyu) May 22, 2023
「文系だからIT苦手で……」と同レベル。
---
リファクタリング（その他）
「ユニットテストが十分ないと自信を持ってリファクタできないが，そもそも各コンポーネントが最早ユニットテストを簡潔に書けるようなインターフェイスではなくなっているからこそリファクタする必要性に直面しているのだ」という問題，重要なのにあまりアプローチされていない気がする
— 画力・博士号・油田 (@bd_gfngfn) May 22, 2023
phpのリフレクション機能ってあんまり興味ある人多くないから知らない人も多いかと思いますが、なんとコメントに書いたアノテーションも取得できるんですよ。
— 伊藤 祐策(パソコンの大先生) (@ito_yusaku) May 22, 2023
つまり、コメントを消したらなぜか動かなくなるとかが当然のように起こりえます。危険ですね！
MySQLのコードは長らくこんな感じだったのだがOracleが大々的にリファクタリングしてSelingerまで入れてるのでたいへん偉いよね。 https://t.co/YY2Pkqrjli
— くまぎ (@kumagi) May 22, 2023
---
テストと品質
～請負or準委任の場合～
— masa@地方フリーランス (@voiprogramming) May 21, 2023
新入社員「コードが汚いのでリファクタしたいです」
先輩「その工数の金誰が出すの？お客さん？万が一デグレ起きた時に何て説明するの？俺には説明できないから自分でお客さんに説明して工数貰ってよ」
新入社員「😭」
ー終了ー
あるある過ぎワロタ。
— ΦAΦ(ﾌｧｲ) (@Physical_eng) May 21, 2023
せめて単体テストは自社の品質担保の責任として書いてホンマ…。
単体テスト書く工数出してくれるお客さん中々居ないですからね😢
— masa@地方フリーランス (@voiprogramming) May 21, 2023
ウチは見積出す時点で工程に含んでいるので高くなり失注しがちです。でもその後その仕事を勝ち取った他所がトラブって結局納期も費用もウチの見積と同じくらいになった、なんて話もよく聞くのですわ…。
— ΦAΦ(ﾌｧｲ) (@Physical_eng) May 21, 2023
あるあるですね😢
— masa@地方フリーランス (@voiprogramming) May 21, 2023
あとで不具合出て修正費用取る方が儲かるしコード汚いと開発したとこに保守任せるしかなくなるので保守費用も取りやすくなるという…
会社としてはそれでも良いのかもですが、保守に全く心躍らない私としては勘弁願いたいのですわ…。
— ΦAΦ(ﾌｧｲ) (@Physical_eng) May 21, 2023
何なら不具合ならただの瑕疵対応ですわ…。
---
Python の保守性
？？？「Python コードに保守性ってあるの？笑」
— 勤怠入力を溜めるな (@mpyw) May 21, 2023
↑こう言われるの、アルゴリズムでの解決に Python が嫌というほど使われるからだよな…
「Python で自社開発やってます！機械学習やデータ分析で高度なこともやってます」
↑きれいなコードを書きたい人がこれを見たら避けたほうがいいシグナル https://t.co/CJIJSBYr3T
アーキテクチャの綺麗さで満足したい人は、ひたすらそんなに高度じゃない地味なドメインばっかやってたほうがいいと思う。そうじゃないとそっちに時間割かせてくれないから
— 勤怠入力を溜めるな (@mpyw) May 21, 2023
それをいっちゃおしまいというか、仕事ではどんなコードも保守しないといけないんだよね… https://t.co/y3U2h9xpDB
— 暗黒美無王 dark Vim (@ShougoMatsu) May 21, 2023
---
Mac
僕がMacのことを何よりも嫌ってるからですけど？？ https://t.co/5MphcB8u90
— 電子計算機の沼 (@Hishinuma_t) May 22, 2023
Apple は確実に一つの世界観を作っていてすごいと思うし Apple Silicon も Rosetta2 もアツいと思うけど、ソフトウェアの不自由さやキーボードへの慣れ等を差し置いても clang（微妙に clang でもない）が gcc を名乗っているというただその一点を持って使わない理由にはなる
— sksat (@sksat_tty) May 22, 2023
見た目
— 電子計算機の沼 (@Hishinuma_t) May 22, 2023
価格
価格
価格
apple silliconとかいうなんだか分からないもの
いつCPUのアーキが変わるかわからない恐怖
販売してるシステム構成
拡張性のなさ
良く分からないclang
それをgccにaliasしちゃうセンスのなさ
行政系のOfficeのファイルが偶にバグる https://t.co/WjZ7NQBsik
Powerで出してきたら手のひらクルクルしながらMac買う https://t.co/U9hjh07mm7
— 電子計算機の沼 (@Hishinuma_t) May 22, 2023
macは致命的にdockerとの相性が悪い
— 米谷昂@FastAPIガチ勢 (@yoneya_fastapi) May 21, 2023
という事実を何も知らないで、使ってるエンジニアが多いことに驚き
近年はdocker必須である場合が多いので、ワイとしてはmacの優位性はあまりないと思っている
ubuntuは簡単だし、docker早くて良い
20年弱前に情シス系SEやってた身の感覚としては、OSの話ではないが、一括調達の機種はマニュアル化で1日に10台とか片づけられるんだけど、社員が思い思いのパーツで組んだPCが情シスに戻ってくると、1日に1~2台しかメンテできず大変なんだよな。WindowsとMacで選択肢あるだけでも恵まれてると思ってる
— Takeshi HASEGAWA (@hasegaw) May 22, 2023
---
その他・別の話
10年ソフトウェアエンジニアをやった結果、開発側の問題で事業やプロダクトがポシャることは少なく、成功するには開発以外に要因が必要という感想になっており、正直若干の無力感を覚えている。ビジネス側やプロダクトマネジメントの部分を開発でカバーして成功させることは、まあほぼ無理。
— Keita Software Engineer (@w_keita_1023) May 21, 2023
逆に開発が酷くてもビジネスやプロダクトマネジメントが成功していれば売れるしスケールしていく。それはそれで開発は地獄になるんだろうけど、経営的にはバッサリ人員を入れ替えて何とか立て直すというのは予算を投じれば可能なことが多い。これまた見方によればある種の悲しい事実かもしれない。
— Keita Software Engineer (@w_keita_1023) May 21, 2023
まさにそうだと思います。
— 東風谷はエンジニアを探している人【正社員募集中】/SES営業 (@Beside_HR) May 22, 2023
弊社はコンサルティングファームなので事業はしっかりグリップして、開発側に負荷をかけないよう調整してます。
事業者の一方的な思いの事業やシステム側の事情で作りやすいように作ったシステムは、最終的に使いにくくクレームになりやすい傾向かな。
リファクタリングが話題ですが僕は毎日この地持ちです pic.twitter.com/50x0XfIlrI
— しんやさん☯️70.0kg (@hangstuck) May 22, 2023
0 件のコメント:
コメントを投稿