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

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

2024-03-11

anond:20240311175503

真似て学ぶぐらい憧れを感じる

述べてません。アナタの頭の中の声です。治療法が確立されてます

洗練というリファクタリング極まると最終的に哲学書のような文章になる

そういう見方もあるとは思う。

しかし、リファクタリングかな?コンテキストの深い専門用語を行き当たりばったりで作って無闇に初学者への戸口を狭くする怠惰だと思ったけど。

2024-03-02

anond:20170626005657

この程度のレベルの爺さんが職責を全うできたってことは、そのクソコードリファクタリングした後は天国やん。

好き勝手出来るで。

ワイが昔いた大企業情シスだけで1,000人くらいいたか全然社内SE感なかったわ。

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

実験前夜

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

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

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

怖いよ。

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

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

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

そんなのないか、多分。

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