「リファクタリング」を含む日記 RSS

はてなキーワード: リファクタリングとは

2024-02-26

[] 最小の労力で実施する

コード修正する、システムに変更点を追加する、など色々なことを開発者実施している。

ここで重要なのは、最も少ない労力で実施する方法を探すことだ。

例えばコード修正する場合、100行を追加するよりも、1行だけ追加して実現できないかを探る。

あるいはシステムについても、専用のコード作成するよりも前に、*nix系コマンドの組み合わせでできないかを探る。

最小の労力で実施するために、すこし時間をかけて考えた方が良い。

「最小労力」という基準採用すると、保守性を上げることができる。

これを意識すれば、頻繁にリファクタリング実施せずに済む。

2024-02-25

[] 全部を書き直す必要はない

コードエントロピー機能追加によって増大する傾向にある。

「この関数にこういうパラメータを使ったこういう処理を追加してくれ」などと言われたら、コードは複雑化するのは当然だろう。

かといってこういう要求が来た時に、コード全体を一から作り直して簡潔にしようと思うのはナンセンスだ。

コードの量にもよるが、一定程度の量のコードがそこにあるときは、やはりリファクタリングの方が効率よく進められる。

「僕はリファクタリングなんてしませぇん、一から書いた方がいいでぇす」というのは、特定現場・状況だけにあてはまるものだと認識しておこう。

かにコード全体をリファクタリング」なんてしようと思ったら大変すぎるが、通常は「修正担当する部分をついでにリファクタリングする」でOKだ。

ユニットテストさえかけていれば、そのリファクタリングによって、バグが見つかりやすくなるだろうし、保守性も上がるのである

なお、本当にコードベースが酷いカオス状態で、ゴッドオブジェクトを使っているような状況になったら、「書き直す」という利点が少しはあるかもしれないが、そういう場合関係各位に同意を取らなければやってはいけない。

そういったカオスな状況でさえ、平均的なプログラマーは「良いコード」よりも「慣れているコード」に愛着を持つ傾向にある。

もしあなたが「コードを綺麗にするためにすべてを一から書き直そう」と、無断でそのようなことをやったら、彼らが慣れていないという理由批判の嵐が殺到するだろう。

もう一度言うが、最善の方法修正担当部分だけをついでにリファクタリングすることだ。これだけにとどめておけ。

2024-01-19

SESリファクタリングやり始めてるとこあるのか・・・

ヤバすぎワロタ

完全に人間を木や石とか、人形・道具として見てる思想

共産主義にも通じるな・・・

やっぱトップはあっちの国の人が多いのだろうかね

2024-01-06

プログラマーの三代美徳本能」「感情」「混乱」

プログラマーの三代美徳は、怠惰でもなければ傲慢でもない。本能感情、混乱である

 

本能とは、モチベーション本質的部分であるエロいdeepfakeを作りたい、頭よく見られたい、金儲けしたいといった動機によってプログラマーは手を動かす。

本能がなければドーパミン存在しない。コードを書く誘因は本能衝動によって生み出されている。

 

感情とは、要するに好き嫌いのことだ。たくさんの経験を積み重ねてセンスを獲得するには、好き嫌いに敏感でなければならない。

なぜvscodeがクソで、emacsが素晴らしいのか。なぜマイクロサービスアーキテクチャに強い疑念があるのか。なぜベンダーロックインが金の浪費に繋がるのか。

そういったことは、経験から学び、そして感情という次元に落とし込まれる。感情は少数の次元美的感覚を得るための優れたセンサーである

 

混乱とは、人生である。混乱したことのないものエントロピーを操ることはできない。

コードは常にエントロピー増大の法則に晒されている。高エントロピーの乱雑的コードを読んで混乱したことがなければ、リファクタリングもできないだろう。

混乱したことのあるものけが、秩序を作り出すことができる。

2023-12-14

プログラマーのワイが読んだ中で良かった本ベスト10

1. UNIXという考え方 Mike

2. プログラミング作法 Brian and Rob

3. テスト駆動開発 Kent

4. 達人プログラマー Andy

5. リファクタリング Martin

6. プログラマーが知るべき97のこと

7. ソフトウェアアーキテクトが知るべき97のこと

8. レガシーコードからの脱却

9. Design It!

10. 少年メイドクーロ君

2023-12-10

技術負債を返済すること

コードを書いていて、2つの選択肢に襲われる。

一つは少し時間をかけて整理された読みやすコードを書くこと。

もう一つはすぐに仕事を終わらせるためにそれっぽいコードで終わらせること。

後者を選ぶと、どんどんと技術負債のしかかっていく。

開発のイテレーションの中では、過去コードリファクタリングする時間など無いことが多い。

から今、少し時間をかけるべきことが多い。

このような技術負債意図的負債と言われる。

意図しない負債というのは、きれいコードを書くようにしていても、問題領域のものが難しくて整理するのが難しくなってくることだ。この場合は、設計の方に重点を置くのが良い。

2023-12-09

anond:20231209145500

誰にも相談せずに

リファクタリングしろという命令があったんだよ

命令した上司リファクタリングして良くなったと言ったが、他のコーダー意図を分かってなかったみたい

最短時間理解可能コードとは

コードを書く上で重要なことは?という質問に対して、アスペならば「実行できること」と答えるだろう。

当たり前なことしか言っていない。「実行できること」という文からは全く有益な知見を得られない。

実行できることは重要性ではなく、必要性である重要性とは、必要なことをすべてやった上でなおやる価値のあることを意味する。

そう考えた時に私がよく思うのは「最短時間理解可能であることが重要であると思うわけである

しかしここに宗教がある。そもそも人間物事理解するプロセスは人それぞれである

私は一度、関数モジュールで適切に分離するためのリファクタリングというものを行ったことがある。

というのも、一つの関数に万を超える行が書かれていたため、上司リファクタリング命令したためである

具体的詳細はprivateメソッドに、公開する必要のあるものはpublicメソッドに移した。

そして当初働いていた職場での反応はどうだったかというと、「スパゲッティコード」だというのだ。

スパゲッティコード?一つの関数に万を超える行があるほうがスパゲッティだと普通は思うだろう。

ところが、彼らの脳内では、「常にコードの詳細が見えていなければ気がすまない」という、カプセル化無視する思想で動いていたため、関数化すると関数の最下層まで辿らないと気がすまないらしかったのである

このようにして、教育の無い人間コードの読み方もカプセル化も知らないので、非生産的方法が最短の方法になってしまうのである

コードを最短で理解するためにはどうするのか。基礎知識教育された集団の中に身を置くのがまず先決である

例えばcalc_monthly_salary_yen(Person p)という行が存在した時、いちいちcalc_monthly_salary_yenの中身を常に見に行くような人たちはダメだ。

人間データ入力すれば円単位で月の給料計算してくれるんだろう」とざっくりと自然言語的に読み進められる人たちでなければ「最短理解」は難しい。

まり最短理解するためのコードを書いた時に、それが本当に最短理解されるためには事前の教養必要なのである

教養のないところに生産性はない。悪いことは言わない。ゴッドオブジェクト管理するような会社からは逃げ出せ。

2023-12-08

Tracer Bullet Development

開発手法でしっくり来てるのがAndy HuntさんのTracer Bullet Developmentで、開発の方向性を示すのに試作を作る方法

1. 主要なシステム オブジェクト定義UIサーバーロジックビットデータベース抽象化レイヤー等。

2. システム オブジェクトを介したデータ フロー定義

3. データフローを実現するために API とその戻り値コーディング

4. 単体テスト使用して API の予想される使用法を文書化。

5. 各 API必要な量の既定のデータ (別名、ダミー データ、偽のデータハードコーディングされたデータ) を追加して、API が「実行」されるようにする。

6. あらかじめ用意されたデータを実際の機能に段階的に置き換える。

7. コードリファクタリングし、システム オブジェクトを調整し、完了するまでこれを続ける。

実用上最小限の実装というプラクティスにも似ているが、ステークホルダーに動くサンプルを素早く見せられるのがポイント

2023-12-03

ドキュメントを整備しないまま会社やめてすみませんでした

リファクタリング不十分なまま会社やめてすみませんでした

ドキュメントを整備しないまま会社やめてすみませんでした

リファクタリング不十分なまま会社やめてすみませんでした

ドキュメントを整備しないまま会社やめてすみませんでした

リファクタリング不十分なまま会社やめてすみませんでした

リファクタリングが不十分なまま会社辞めてすみませんでした

リファクタリングが不十分なまま会社辞めてすみませんでした

リファクタリングが不十分なまま会社辞めてすみませんでした

2023-11-18

anond:20231118022354

じゃあ、お前の現場リファクタリングをさせて貰えるか!!

自動テストとか継続的インテグレーションなんて今や当たり前なのは分かるが、それらが走ってる以上リファクタリングが出来るのは当たり前だよな!!

社会人ならコード臭いに耐えて当たり前」なんてことはなかろうな。

2023-11-16

anond:20231116094912

こういうのね、外から見てると笑えるけど、実際に現場にいて精神病んでくるとだんだんホラーって感じるんだよな。

日本の開発現場あんまりリファクタリングさせてくれんもんね。

コード臭いを感じても、「社会人なら臭いに耐えて当たり前」がデフォ

JUnitとかを使っててもそうなのかな…。

2023-10-29

達人プログラマーゾルラーク

anond:20231027224113

プログラミング話題と相性がいいんじゃないかと思って、昔読んだことがある達人プログラマー (1999年出版された第1版の方、2019年出版された第2版ではない) をぱらぱら見返してみた。プログラマーとしての姿勢プラクティスなどは一般に普及したかどうかの判断が難しい。間違いなく一般的になったなと思えるものに絞って書く。インフラ面の進化が大きいと言えそう。

フリーレン「わずか数年で人類の開発方法論に組み込まれ、新しいインフラによってシステム開発生産性を向上させた。」

17 ソースコード管理

でも今のチームはソースコード管理システムを使っていないんだけど…

恥ずかしいと思ってください! そして、これが伝道師となる機会だと受け止めてほしいのです。しかし、彼らが自ら進むべき道を見つける時まで、あなた一人ぼっちであってもソース管理を使うようにしてください。

フェルン「いまのはバージョン管理システムです。」

33 リファクタリング

いつリファクタリングを行うべきなのか?

コードがうまくなじんでいないと感じたり、まとめるべき 2 つの事柄を見つけたりといった何か「おかしもの」に遭遇した場合、手を入れることを躊躇してはいけません。

34 テストやすコード/43 容赦ないテスト

テスト文化

あなた記述したソフトウェアはすべてテスト対象になりますあなたあなたのチームの人間テストをしなければ、最終的にユーザーテストを強いられるのです。このため、テスト計画を徹底的に練る必要がありますしかし、事前にものごとを少し考えるだけでメンテナンス費とヘルプデスクへの呼び出しを大幅に削減できます

(中略)

テスト技術というよりは文化なのです。こういったテスト文化は、使用する言語関係なくプロジェクトに植え付けることが可能なのです。

フェルン「いまのはテスト駆動開発です。」

42 どこでも自動化

多くのプロジェクトでは、こういったレベルビルドは毎晩自動的に実行されています。つまりプロジェクト特定部分を夜間ビルド作成すると同時に、個別テストよりも完全なテストを実行できるのです。これによって、完全なビルド実行時に行うテストをすべて実行させることも可能になります。結果として、その日のうちに回帰テスト問題を見つけられるようになるわけです。ソースの変更後、できるだけ早い時点で問題を検出できれば、バグの検出と修正を円滑に進められるようになるはずです。

フェルン「いまのは CI/CD です。」

2023-09-16

anond:20230916210759

こうあってほしいという、完成予想図は、最初にある感じ。

一番コア機能というか、問題が起こりそうな中核部分を書き始めると、

案の定最初の予想通りにはいかないことが判明し、完成予想図ノ変更を強いられる。

いろいろ調べて解決策を見つけて、まぁ、これならちゃんと完成するだろう。

って思えた時が、一番完成に近い図が見えてる感じかな。

でも、その後も細部まで作りこむにつれて新たな問題がみつかり、

目指す完成形はコロコロ変わって行く。

紆余曲折あって、ようやく機能を満たすという意味で完成し、

公開したり納品して評価を頂くのだけど、

実際その時点は、出来栄えに満足してなくて、リファクタリングなどしつつ、

俺のプログラムの完成はこれからだ!

となって終わる。

2023-08-24

anond:20230824162236

リファクタリングで済むぐらいのお行儀のいいプログラム触ってるからそんなこと言ってられんだよ。

2023-08-11

anond:20230811224103

エクリプス使ってるなら、リファクタリングの項目あるだろ。そこに、便利ツールあったと思うけど。一括変換みたいなやつ。

2023-07-14

anond:20230714085936

ちゃごちゃした状態リファクタリングすると速く小さくなるからついやりたくなる(なお仕様外のバグが発生する模様)

2023-06-01

実験前夜

実験の前にコードリファクタリングしてる。

正直、実験して結果を確認するのが怖いからしてる。

もし想定と違う結果が出たらどうしようって思うと実験開始に踏み切れない。

怖いよ。

もちろん結果が想定と違っても、原因を調査して再実験するんだろうけど、やっぱり怖い。

不安になると死にたくなる。

身近な不安のない暮らしを送りたかった。

そんなのないか、多分。

anond:20230531201233

法律って大変だよね。プログラミング言語ならテストコードあればリファクタリングして文章すっきりにできるけど、自然言語にはテストコードがない。コードしかないとか恐ろしい。こういうのもすべて与党不作為だよなあ。

2023-05-27

はてな退職エントリを書いています

私は約3年間、はてなエンジニアとして働いていました。

この期間に、様々なプロジェクトに関わり、多くのことを学びました。

今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います

 

## RailsでのWebアプリケーション開発

はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。

はてなログはてなブックマークなどの有名なサービスはもちろん、社内向けのツール新規事業プロトタイプRailsで作っていました。

Railsは、高速に開発できるというメリットがありますが、それと同時にコード品質パフォーマンスにも気を配る必要があります

私は、テストリファクタリングコードレビューなどの技術的なプラクティス積極的に取り入れることで、Railsの開発をより効率的安全に行う方法を学びました。

例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。

また、Pull RequestやPair Programmingといった方法を使ってコードレビューを行い、バグ改善点を見つけたり、知識ノウハウを共有したりしました。

 

## クラウドサービスでのインフラ構築

また、はてなでは、AWSGCPなどのクラウドサービス活用してインフラを構築していました。

私は、DockerKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーションインフラストラクチャ・アズ・コードなどの技術実践しました。

これらの技術は、開発環境と本番環境差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。

私は、モニタリングロギングアラートなどの技術的な仕組みを整備することで、インフラ運用をより安定的信頼性の高いものにする方法を学びました。

例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステム状態パフォーマンス監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。

また、ElasticsearchやFluentdといったツールを使ってログ収集分析を行い、原因究明や改善策の検討に役立てました。

 

## チームでの協働

はてなエンジニアとして働くことで、私は多くの技術的なスキル知識を身につけることができました。

しかし、それ以上に大切だったのは、チームで協力して問題解決することでした。

はてなでは、エンジニアだけでなくデザイナープロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。

私は、コミュニケーションフィードバックドキュメンテーションなどの技術的ではないスキル重要だと感じました。

私は、自分意見提案積極的に発信することで、プロダクトやサービス品質価値を高める方法を学びました。

例えば、私が参加したプロジェクトでは、SlackZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。

また、FigmaMiroといったツールを使ってデザインアイデアの共有やフィードバックを行いました。

 

## 退職への決断

私は、はてなエンジニアとして働くことがとても楽しく充実していました。

しかし、私は自分キャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。

私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。

そこで、私はこの度、はてな退職することにしました。

私は今後、別の会社エンジニアとして働く予定です。

 

## おわりに

はてなで働いた3年間は私にとってかけがえのない財産です。

私は、はてな出会ったすべての人に感謝しています

に私が所属したチームのメンバーには大変お世話になりました。

彼らから学んだことや刺激されたことは数え切れません。

彼らと一緒に仕事ができたことを誇りに思います

彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います

 

以上、AIによるフェイ記事です。

どの程度、真実味がありましたか

2023-05-23

可読性悪すぎるコード拡張を頼まれたらリファクタリングするか?

自分なら自分拡張のために書き直さないといけない部分だけ書き直すし、書き方も前の人に合わせて書く

それ以外は怖いので書き直さな

ログイン ユーザー登録
ようこそ ゲスト さん