はてなキーワード: リファクタリングとは
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
そもそも高い賃金が欲しくてプログラマーになったようなやつは勘違いしているようだけど
なぜなら経済として会社を支えているのはどんなときでも営業だからだ
現に9割9分の会社は技術などないが営業が優秀なので存続している
(ちなみにここでいう営業というのはプロモーションや戦略系も含まれる)
例えば流行の機械学習を生業としているようなベンチャー企業であっても
最新のトレーニング手法やパラメータ定義なんかを使っても得られる利益はほとんど無いのだ
Web系でもAngularだろうがReactだろうがVueだろうがどうでもよくて
とにかくデザイナーの出したものを忠実、もしくはそれ以上のものを生み出せれば技術などどうでも良いのである
という人もいるが、残念ながら全ての技術は5年後に負債になっている可能性が等しくあるということを理解していただきたい
そんな中で日本での人材流動性の高まりであるとかプログラマー育成問題なんかもあって
技術系(プログラマー)の市場価値が高まり、たまたま今だけ高給になっているわけである
卵が少なくなって卵の値段が上がったとしても
その卵が美味しいかと言われるとそんなわけはないのだ
どちらかと言うと腐った卵まで流通するのが恐ろしいところである
私が見てきたベンチャーの腐った卵には下記のようなジャンルがある
メガベンチャーや伸び盛りのベンチャー系に多く、特に旧帝大出身(特に東大)に多いのがこのパワハラ系
とにかく(自分の)理論が正しいということを前提に自覚無くパワハラを繰り返す
これが雇われ社員ならそれほど問題でもないのだが、経営者側のCTOなどだった場合は目も当てられない
テックだろうがベンチャーだろうが雇用主と雇用者という関係性は変わらないのに平気でゴリゴリパワハラを行う
雇用主側に主張されると組合も無い弱い立場の雇用者は何も言えない
その状況を理解していないのか雇用主側のパワハラはエスカレートしていく傾向にあり
社員は退職するが新しい人材は集まらずたいていの場合は逆に雇用主側が病む
この手のテックマウントパワハラ系の特徴は、ドメイン駆動や過度の抽象化、もしくは無駄な高速化や機械語への執念などが挙げられる
例示するのは難しいが、PRを上げてきた新人社員をSlack上で公開にボコボコに論破した上に
「社会人としてできて当たり前」
みたいなことまで説教を始める人を何人か知ってる
小さめで大きくなってきているベンチャーに多いのが、この結局全部自分でやる系
締め切りの前日もしくは当日、もしくは過ぎた後に自分で全部やり直す人
それまで部下や関係者が相談しつつ進めていても結局は全部ぶち壊して全部自分でやる
などというのは完全な素人で、単に他者に業務依頼できない人である
「言ってくれればもっと早く出来たのに」
ということしかない
そんな調子で依頼することができないので結局は自分で実装を繰り返し更に時間がなくなる
「俺ほどの技術力を持った人がいなくて困る」
みたいな自己肯定感を醸成しているのでそのうち上のパワハラ系へと移行していく
特徴としてはSlackにしろPRにしろ話が抽象的すぎて文章力が無い人である
「1を聞いたら10を知るのが当たり前だろ!」
と言う人が多く(1と10から100は分かるけど1だけで10を知ったら変態ですよ)
ヒドイ人になるとIssueやPRの管理も全然できず、ブランチも規則無く乱立してしまっていて
新しく入った人もいったい何をどうすればいいのかさっぱり分からない状況で放置してしまう
これも例示すると、新サービスの仕様だけは決まっていてページレイアウトが無い状態で
デザイナーの配属が難しいので実装側が考える、ということになったとき(割とある)
と言っても音信不通で渋々とこれまでのレイアウトを踏襲して3人できっちり作ったところ
リリース前日になってCTOが徹夜で全部作り直す、ということがあった
レイアウトも全然変わっていて、実はニュースリリースの段階から新規テーマになることが決まっていたらしく
それに合わせて全部作り替えたそうだ
新規テーマは1ヶ月も前から決まっていたのだから共有さえしてくれればそれに合わせて作ったのになぁ、という話をした
余談だがこういうときにこの手の人が「デザイン共有できず申し訳なかった」というような一言はほとんど無い
そういうコミュニケーションが取れる人は最初から業務依頼ができるのだ
最後が最近一番多いのだが、単に技術力が無くて頑張ってるだけの技術者
JavaScriptでリストの中に'apple'があるかどうかを調べる時に array.includes('apple')と書くとして、
10個のフルーツのリストがあってそれらが含まれているかを調べる時に10個のincludesを書いてしまうような人である
「せめてfor文で書こう」「そもそもデータ構造がおかしい」「というか本当にやりたい処理は?」
などなど様々な疑問が出てくるが、不思議なことにこれらを指摘しても絶対に直ることは無く、全く同じことを何度もやる
他にも例えば男性か女性かでメッセージを変えて出力しているコードがあったとする
if( gender === 'male') { ... } else { ... }
これに、20歳以下の場合は男女共通で違うメッセージを出す場合に
if( gender === 'male') { if ( age <= 20 ) { ... } else { ... } } else { if ( age <= 20 ) { ... } else { ... } }
みたいなコードを書いてしまう(20歳以下の部分は同じコードのコピペ)
メッセージ表示させるだけなら大したことないが、実際にはもっと複雑な処理をコピペで貼り付けるのである
そのため
「20歳以下の表示部分のバグについて、男性の場合は直ってるけど女性の場合に直ってない」
if ( gender === 'female' && age <=20 ) { ... }
これでもだいぶオブラートに包んでいて、実際にはもっと複雑なロジックをぐちゃぐちゃのまま整理せずに追加するのでとてもじゃないがメンテできない
(最近だとそういう部分はまとめてChatGPTに放り込むと綺麗にしてくれるので非常に助かっている)
こういう低レベルな技術者は結構いるのだが、大企業だと時間をかけて成長していくのに対して
ベンチャーになると自己肯定感が高いのか成長せずに偉そうである
「動いてるものは触らないで欲しい」
「Javaだとこういう書き方するんだよね」(そんなことはない)
みたいなことを言って、とにかく学習しない
曲がりなりにもそういう職に一度就いてしまうと指摘されることもないので学習しないんだと思う
特にCTOだとあくまで雇用主側の立場なので雇用者側から指摘されることも少ないし
同業他社のレビューなんてのもないからそこで時間が止まってしまうんだろうな、という感じ
こういう技術者のコードでも、見た目は動いているので営業側から見ると売るには問題ないのだ
なので営業が優秀だと下手に売れてしまって成功体験からますます自己肯定感が増して手が付けられないモンスターCTOの誕生である
「成功してから伸び悩んで大手企業が買収したけど技術的負債が凄まじ過ぎてリファクタリングだけで一大プロジェクトになる」
「リファクタリングが上手く行かずに仕様変更することになって『大手企業に買収されてダメになった』というレッテルが貼られる」
「当時のCTOは別の会社で新しい事業のCTOとして活躍している」
という流れはこうして生まれている
幼馴染同士で作ったベンチャー企業でクソコードのメンテナンスばかりやってた主人公が追放されて転職して、元の会社は重複するコードが分散してバグフィックス不能に陥って損害出して倒産して、主人公は転職先の安定した大手でメンテナンスのスキルでめちゃくちゃ評価される話を書いたら、コメント書いてただけの人にめっちゃウケそう。
酷いコードのリファクタリング、書いた人よりも能力がないと大抵上手くいかないので、「酷いコードだな〜」と思いながらほーんと読めるくらいの能力がないのにリファクタすれば読めるようになる!はそりゃあ失敗するわと思うし、まずは能力をつけるために頑張って手を動かすのが重要だったんじゃないですかねえ
[B! エンジニア] 自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話|JoanOfArc
あのさ、リファクタリングを扱った書籍では「まずテストを書け」ってほぼ確実に書いてあるんだよ。
意図せずバグが発生するように、意図せず挙動を変えて壊してしまうことは不可避だから。
なのでまず(粒度は荒くてもいいから)回帰テストをできるようにする。
リファクタリングはその後の話。
だというのに、元記事には一切「テスト」というワードが出てこないんだよ。
挙動を保証せずに「挙動は **たぶん** 変わってません」と言ってソフトウェアを壊したら本末転倒だろ。
あなたはプログラミング言語Rubyの熱心なユーザーです。プログラミング言語Disりコンテストというものがあり、静的型付け言語を動的型付け言語でもあるRubyの視点からバカにすることになりました。ユーザーなら思わず納得するような視点も交えつつ、静的型付け言語のデメリットを200字程度で攻撃してください。
静的型付け言語の愛好家よ、それでも本当に静的型付け言語が優れていると思ってるのか?Rubyのような動的型付け言語の柔軟性と自由さを体験したら、君たちも考えを変えること間違いなしだ。
まず、静的型付け言語は、コンパイル時に型チェックを行うため、開発速度が著しく遅くなる。それに対してRubyは、型の宣言が不要で迅速にコードを書き進められる。煩雑な型宣言に時間を浪費するなんて、プログラミングの真髄から外れているだろう。
次に、静的型付け言語は、型の制約が厳格すぎて、柔軟な実装が難しくなることがある。それに対して、Rubyは動的型付けのおかげで、データ構造やアルゴリズムを自由自在に操れる。革新的なソフトウェアを生み出すのは、やはり柔軟性が重要だ。
最後に、静的型付け言語のユーザーは、型の間違いを恐れてコードのリファクタリングをためらうことがある。しかし、Rubyなら型に縛られず、思い切りリファクタリングができるので、保守性も抜群だ。
つまり、静的型付け言語は開発速度の低下、柔軟性の欠如、保守性の悪化を招く。Rubyのような動的型付け言語を使えば、これらの問題が解決され、プログラミングがもっと楽しくなるぞ!
大手メーカーのプロダクトについて手伝って欲しいってことで業務委託で入ったんだけど
見させてもらったんだけど、まぁクソコードでした
どれぐらいクソかっていうと{ apple: 100, banana: 200, orange: 300}ってなってる中からorangeの値を取ってくるときに
for文でkeyをループして一つ一つをイコール比較して見つけたらbreakするっていうコードが日常的に使われてるぐらいクソ
他にも数え上げたらキリが無いんだけど「難しくて読めない」じゃなくて「アホすぎて読む気が失せる」っていうコード
そんでそのクソコードに対して追加機能を入れてくれって言われたんだけど
こんなクソコードだとバグを引く可能性がめちゃくちゃ高いし作業効率化のためにリファクタリングしましょう、って提案
結果としてはこの半年ぐらいで想定の進捗の半分ぐらいしか行ってない
「最初は半年でコレぐらいができるって言ってたのに半分しか進んでないぞ!」
とか言ってくるんだけど
「だからリファクタリングしないと作業効率悪すぎて全然進めないですよ、まずはリファクタリングしないと無理ですよ」
ちなみにその人の実装スピードはこっちの3分の1ぐらいなので慣れたら早いとかそういう問題じゃ無い
質問するシーンというのは
2.意図が読み取れなかった時
3.変更して欲しい時
5.承認するかどうか迷ってる時
1の時は言葉尻が変わる、「◯◯について詳しくないんですが」あたりが付くだろ
2の時はコードが悪いわけだから、質問じゃなくて「意図が読み取れなかった」わけだから悪いコードだ、「修正しました」というのは「修正したけどこれなら意図わかるか?」だ
3は質問ではなく指摘
4も表現が変わるはず、「AとBがあると思いますが、Aにした理由は何ですか?」
→ 特に理由もなく、Bのほうが良いと思ったら「修正しました」となる
→ Aにした理由があれば、回答が返ってくる
5はただの圧、上司による「やりなおし、理由は自分で考えろ」と同じ
確固たる理由があれば返ってくるが、そうじゃない場合はよりリファクタリングをした上で理由をつけて返したくなるので「修正しました」となる
つまり「純粋に質問ですが、どうして〜〜なんですか?」なんていう純粋な質問は基本存在しない
1.「◯◯について詳しくないんですが」
4.AとBがあると思いますが、Aにした理由はなんですか?私は優劣つけられないんですが
5.この部分について◯◯の懸念がありますが、〜〜とした理由か修正をお願いします
そもそも結婚があって、家族があって、両親があって、姓名があって、というのは数十万年の人類の生活方式によるものだった
ようやくその傾向が薄れてきていると思う
原因はインターネットの登場だろう、これにより全国民に対して一律のサービスを提供できることになった
まだ国の枠は残っているが、インターネットサービスによっては国の枠すら超える
そうなると、家族の意義はかなり薄れてくる
血族は現実問題消えないだろうし、幼少期の育ての親という関係も消えない
成人してからの人生は約60年もある、こっちのほうが圧倒的に長く、社会を家族主義の設計にしなくても良くなってきた
何ならそういうしがらみが嫌な少数派の声が大きくなってきている
シングルマザー、シングルファザーもそうだし、LGBTQもそうだし
じゃあ家族主義の設計は無くしていく方向にリファクタリングするんじゃないの?というのは考えとして自然だと思う
とは言え置き換えるコストが大きいし、今特別困っているわけではないので、その変化はゆっくりと起きると思われる
100年後か200年後か
以前このようなエントリを投稿したのだが、このエントリの文脈を前提にColabo騒動を考えるのであれば「自由を得るため皆で関わろう」という考え方になる。
ボクのような性質を持った人間は情報がオープンであることが望ましいと考えるし、その観点から言えばColaboは保護している女性に危害が及ばないよう慎重になりながら情報を可能な限りオープンとし、我々市民は自治体や団体と連携しつつオープンな情報を活用してデバッグ(検証)とリファクタリング(最適化)を行えるような体制を築いたほうが良い。
そのようなものは理想論だと言いたくなる人も居るだろうが、我々は理想を実現するためにFLOSSやGNUを標榜しているのでは無かったか?
理想論、それは褒め言葉だろう感謝する。
GNUはそもそも、製品を無償で提供しサポート業務を有償で請け負うと言ったビジネスモデルが提唱されている。
そのような中で発展したGNU/Linuxはプロプライエタリの代表格であったMicrosoftがWindowsのサブシステムとしてGNU/Linuxを取り込むといった成果が近年見られるし、より一般大衆目線で事例を挙げるのであればAndroidスマートフォンはGNU/Linuxベースだ。
FLOSSやGNUの事例を参照し、女性の保護は無償で請け負いつつも生活のサポートは有償で行うというような、無償を支えるための有償ビジネスモデルとして様々な無償-有償パターンを洗い出し・議論し・試験し・実現していくことこそ、女性が、そして我々が自由を得るために必要な行動なのではないかと皆さんへ問いたい。
ボクは以前のエントリで語ったように思想には詳しくない。
しかしボクがよく知るハッカー文化は、万人が自由にアクセスできる環境や道具や制度を揃え、万人が自由にそれらを選択し活用し好きなものを好きなように好きなだけ生産できる社会を是とする。
様々な事情により不自由であった女性が保護された先で、自由に使うことが可能な選択できる環境や道具や制度が社会にあることを知り、好きなものを好きなように好きなだけ生産できるようになることは素晴らしいことじゃないか。
更にその生産するまでの過程がオープンであるのならば、それを見て憧れ、1人2人と自由に至る女性が増えていくことへ繋がる。
「失敗したらどうするのか?」と言いたくなるだろう。
そんな意見への返答は「動かせばバグ出る!ボクたちはそれをよく知っている!」だ。
バグを恐れるな先ずは動かせ!壊れたら、落ちたら、問題が見つかったら検証し取り除こう!
それがボクたちのやり方だし、だからこそ検証可能性は担保しておかなければならない。だからこそブラックボックスではいけない。
Colaboだけでなく全ての団体へ言おう!
自由でオープンな社会を目指そう!自由でオープンな団体となろう!
ボクはそうなれるようこれからもColaboだけでなく全ての団体を応援し、FLOSS活動を通してColaboだけでなく全ての団体へ貢献していく!
恐らくニーズが変化しないような機能しか実装してきていないからそういう感想を持っているんじゃないかな
基本的にプログラムは機能が増えるほど複雑性が指数関数的に増えて行くので
如何に単純な機能の組み合わせで実装を進めていくかっていうのが大事だけど
それを最初から考えて実装するのは無理なので実装+リファクタリングを繰り返す必要がある
「最初から完璧な設計が出来ていればリファクタリングしなくて良い」というのは正解なんだけど
ユーザーニーズは常に変化するから最初から完璧な設計っていうのは神にしか出来ない
設計を変えず、リファクタリングもせずにユーザーニーズに応えようとすると単純な機能の組み合わせで実現できなくなってくるから難解な作業になる
この辺が「プログラミングは単純作業じゃ無い」っていう根本にあるんだけど
ニーズが変化せずに最初の設計から変える必要がないようなシステムだと「プログラミングは単純作業」とかいう発想になるんだと思う
オーダを知らないで書かれたコードなんかよりもっとやばいのが並列処理な
爆弾みたいなもんだけど、世の中のシステムにかなり内包されてる
こんな感じで人類はまだ並列処理の最適解を見つけていない
そのくせに「並列化したら早くなるよね!」っていう人が多いので事故ることが多い
Twitter社員がよくわからん基準で次々に解雇され、週報まで求められるようになったとのニュースを読んだ。Twitterは社員に対し、明確に「すぐに目に見える成果を出せないやつはクビだ」というメッセージを発している。
こうなると、社員としては受けの良いタスクばかりに集中することになる。具体的には、新機能の実装だったり、新しいインフラへの移行だったり、UIの変更だったり。
バグの修正……3週間調査してコードの修正は1行だけみたいなのはザラ……は、当然のように優先順位が下がる。というかそういうタスクに時間を使っちゃったエンジニアは、自動的に解雇される。既存の不具合が直ることはもう期待しないほうがいい(いやもちろん、週報読む人が「これは難易度もインパクトも大きいバグだったんだな」って評価してくれればいいけれど、期待できないでしょう)。
新しく作られたものも、品質はおそらく悲惨なものになる。コードレビューは手抜きになるだろう。だって自分の実績として週報に書けないし。普通はリファクタリング(コードの整理)をしてコードの複雑度を下げてから機能を足したり修正したりするのだが、雑にコードを足すだけになってコードの複雑度が一方的に増加していくようなことになるはず。だってリファクタリングとか人事考課で評価されないでしょ。
そもそも、残っている全員が誰もTwitterの持続可能性を気にしていないんじゃないかと思う。ビザホルダーは永住権取るか良い転職先が見つかるまで職を維持できればいいやとしか思ってないだろうし、「ハードコア」に共感した人もなにか一発当てて去っていくことしか考えてないだろう。だから、誰にとっても技術的負債なんて知ったことではない。どうせ数年以内にクビになるか転職するし。
心理的安全性のなくなった職場の生産性の低下度や、SREがいなくなったことによるサービス品質の低下については、正直なところよくわからない。まぁ、上がりはしないんだろうけど、もしかすると大して影響ないのかも。
まともなインターンでも酷くて時給2000円とか普通で時給3000円なのに、それよりも低い価値しか提供できないのか?
新技術の検証とか、リファクタリング試行とかインターンにやらせたりするが、10年やってもそのインターンよりも低いレベルなのか?
孫請けSIerや零細企業だと月給20万円とかいう世界があるのかもしれんが、もしインターンより安いのが当たり前だと思うなら転職した方が良い。
クソみたいなJST大手SIerで雇用してる低レベルプログラマーでも月100万円/人月で、
月稼働時間が(22日*7.5時間/日=)165時間だとすると、時給6060円だぞ。
簡単なことをやるにせよ、