真似て学ぶぐらい憧れを感じる
述べてません。アナタの頭の中の声です。治療法が確立されてます。
洗練というリファクタリング極まると最終的に哲学書のような文章になる
そういう見方もあるとは思う。
しかし、リファクタリングかな?コンテキストの深い専門用語を行き当たりばったりで作って無闇に初学者への戸口を狭くする怠惰だと思ったけど。
]]>好き勝手出来るで。
ワイが昔いた大企業、情シスだけで1,000人くらいいたから全然社内SE感なかったわ。
]]>ここで重要なのは、最も少ない労力で実施する方法を探すことだ。
例えばコードを修正する場合、100行を追加するよりも、1行だけ追加して実現できないかを探る。
あるいはシステムについても、専用のコードを作成するよりも前に、*nix系コマンドの組み合わせでできないかを探る。
最小の労力で実施するために、すこし時間をかけて考えた方が良い。
「最小労力」という基準を採用すると、保守性を上げることができる。
これを意識すれば、頻繁にリファクタリングを実施せずに済む。
]]>「この関数にこういうパラメータを使ったこういう処理を追加してくれ」などと言われたら、コードは複雑化するのは当然だろう。
かといってこういう要求が来た時に、コード全体を一から作り直して簡潔にしようと思うのはナンセンスだ。
コードの量にもよるが、一定程度の量のコードがそこにあるときは、やはりリファクタリングの方が効率よく進められる。
「僕はリファクタリングなんてしませぇん、一から書いた方がいいでぇす」というのは、特定の現場・状況だけにあてはまるものだと認識しておこう。
確かに「コード全体をリファクタリング」なんてしようと思ったら大変すぎるが、通常は「修正を担当する部分をついでにリファクタリングする」でOKだ。
ユニットテストさえかけていれば、そのリファクタリングによって、バグが見つかりやすくなるだろうし、保守性も上がるのである。
なお、本当にコードベースが酷いカオス状態で、ゴッドオブジェクトを使っているような状況になったら、「書き直す」という利点が少しはあるかもしれないが、そういう場合は関係各位に同意を取らなければやってはいけない。
そういったカオスな状況でさえ、平均的なプログラマーは「良いコード」よりも「慣れているコード」に愛着を持つ傾向にある。
もしあなたが「コードを綺麗にするためにすべてを一から書き直そう」と、無断でそのようなことをやったら、彼らが慣れていないという理由で批判の嵐が殺到するだろう。
もう一度言うが、最善の方法は修正担当部分だけをついでにリファクタリングすることだ。これだけにとどめておけ。
]]>完全に人間を木や石とか、人形・道具として見てる思想だ
共産主義にも通じるな・・・
やっぱトップはあっちの国の人が多いのだろうかね
]]>
本能とは、モチベーションの本質的部分である。エロいdeepfakeを作りたい、頭よく見られたい、金儲けしたいといった動機によってプログラマーは手を動かす。
本能がなければドーパミンも存在しない。コードを書く誘因は本能的衝動によって生み出されている。
感情とは、要するに好き嫌いのことだ。たくさんの経験を積み重ねてセンスを獲得するには、好き嫌いに敏感でなければならない。
なぜvscodeがクソで、emacsが素晴らしいのか。なぜマイクロサービスアーキテクチャに強い疑念があるのか。なぜベンダーロックインが金の浪費に繋がるのか。
そういったことは、経験から学び、そして感情という次元に落とし込まれる。感情は少数の次元で美的感覚を得るための優れたセンサーである。
混乱とは、人生である。混乱したことのないものはエントロピーを操ることはできない。
コードは常にエントロピー増大の法則に晒されている。高エントロピーの乱雑的コードを読んで混乱したことがなければ、リファクタリングもできないだろう。
混乱したことのあるものだけが、秩序を作り出すことができる。
]]>2. プログラミング作法 Brian and Rob
3. テスト駆動開発 Kent
4. 達人プログラマー Andy
5. リファクタリング Martin
6. プログラマーが知るべき97のこと
7. ソフトウェアアーキテクトが知るべき97のこと
8. レガシーコードからの脱却
9. Design It!
10. 少年メイドクーロ君
]]>一つは少し時間をかけて整理された読みやすいコードを書くこと。
もう一つはすぐに仕事を終わらせるためにそれっぽいコードで終わらせること。
後者を選ぶと、どんどんと技術的負債がのしかかっていく。
開発のイテレーションの中では、過去のコードをリファクタリングする時間など無いことが多い。
だから今、少し時間をかけるべきことが多い。
このような技術的負債は意図的な負債と言われる。
意図しない負債というのは、きれいにコードを書くようにしていても、問題領域そのものが難しくて整理するのが難しくなってくることだ。この場合は、設計の方に重点を置くのが良い。
]]>誰にも相談せずに
リファクタリングしろという命令があったんだよ
命令した上司はリファクタリングして良くなったと言ったが、他のコーダーは意図を分かってなかったみたい
]]>当たり前なことしか言っていない。「実行できること」という文からは全く有益な知見を得られない。
実行できることは重要性ではなく、必要性である。重要性とは、必要なことをすべてやった上でなおやる価値のあることを意味する。
そう考えた時に私がよく思うのは「最短時間で理解可能」であることが重要であると思うわけである。
しかしここに宗教がある。そもそも、人間が物事を理解するプロセスは人それぞれである。
私は一度、関数やモジュールで適切に分離するためのリファクタリングというものを行ったことがある。
というのも、一つの関数に万を超える行が書かれていたため、上司がリファクタリングを命令したためである。
具体的詳細はprivateメソッドに、公開する必要のあるものはpublicメソッドに移した。
そして当初働いていた職場での反応はどうだったかというと、「スパゲッティコード」だというのだ。
スパゲッティコード?一つの関数に万を超える行があるほうがスパゲッティだと普通は思うだろう。
ところが、彼らの脳内では、「常にコードの詳細が見えていなければ気がすまない」という、カプセル化を無視する思想で動いていたため、関数化すると関数の最下層まで辿らないと気がすまないらしかったのである。
このようにして、教育の無い人間はコードの読み方もカプセル化も知らないので、非生産的な方法が最短の方法になってしまうのである。
コードを最短で理解するためにはどうするのか。基礎知識を教育された集団の中に身を置くのがまず先決である。
例えばcalc_monthly_salary_yen(Person p)という行が存在した時、いちいちcalc_monthly_salary_yenの中身を常に見に行くような人たちはダメだ。
「人間のデータを入力すれば円単位で月の給料を計算してくれるんだろう」とざっくりと自然言語的に読み進められる人たちでなければ「最短理解」は難しい。
つまり最短理解するためのコードを書いた時に、それが本当に最短理解されるためには事前の教養が必要なのである。
教養のないところに生産性はない。悪いことは言わない。ゴッドオブジェクトを管理するような会社からは逃げ出せ。
]]>1. 主要なシステム オブジェクトを定義。UI、サーバー、ロジックビット、データベース抽象化レイヤー等。
2. システム オブジェクトを介したデータ フローを定義。
3. データフローを実現するために API とその戻り値をコーディング。
4. 単体テストを使用して API の予想される使用法を文書化。
5. 各 API に必要な量の既定のデータ (別名、ダミー データ、偽のデータ、ハードコーディングされたデータ) を追加して、API が「実行」されるようにする。
6. あらかじめ用意されたデータを実際の機能に段階的に置き換える。
7. コードをリファクタリングし、システム オブジェクトを調整し、完了するまでこれを続ける。
実用上最小限の実装というプラクティスにも似ているが、ステークホルダーに動くサンプルを素早く見せられるのがポイント。
]]>リファクタリング不十分なまま会社やめてすみませんでした
ドキュメントを整備しないまま会社やめてすみませんでした
リファクタリング不十分なまま会社やめてすみませんでした
ドキュメントを整備しないまま会社やめてすみませんでした
リファクタリング不十分なまま会社やめてすみませんでした
]]>リファクタリングが不十分なまま会社辞めてすみませんでした
リファクタリングが不十分なまま会社辞めてすみませんでした
]]>自動テストとか継続的インテグレーションなんて今や当たり前なのは分かるが、それらが走ってる以上リファクタリングが出来るのは当たり前だよな!!
「社会人ならコードの臭いに耐えて当たり前」なんてことはなかろうな。
]]>日本の開発現場はあんまりリファクタリングさせてくれんもんね。
コードの臭いを感じても、「社会人なら臭いに耐えて当たり前」がデフォ。
JUnitとかを使っててもそうなのかな…。
]]>プログラミングの話題と相性がいいんじゃないかと思って、昔読んだことがある達人プログラマー (1999年に出版された第1版の方、2019年に出版された第2版ではない) をぱらぱら見返してみた。プログラマーとしての姿勢やプラクティスなどは一般に普及したかどうかの判断が難しい。間違いなく一般的になったなと思えるものに絞って書く。インフラ面の進化が大きいと言えそう。
フリーレン「わずか数年で人類の開発方法論に組み込まれ、新しいインフラによってシステム開発の生産性を向上させた。」
でも今のチームはソースコード管理システムを使っていないんだけど……
恥ずかしいと思ってください! そして、これが伝道師となる機会だと受け止めてほしいのです。しかし、彼らが自ら進むべき道を見つける時まで、あなた一人ぼっちであってもソース管理を使うようにしてください。
フェルン「いまのはバージョン管理システムです。」
いつリファクタリングを行うべきなのか?
コードがうまくなじんでいないと感じたり、まとめるべき 2 つの事柄を見つけたりといった何か「おかしなもの」に遭遇した場合、手を入れることを躊躇してはいけません。
テストの文化
あなたの記述したソフトウェアはすべてテストの対象になります。あなたやあなたのチームの人間がテストをしなければ、最終的にユーザーがテストを強いられるのです。このため、テスト計画を徹底的に練る必要があります。しかし、事前にものごとを少し考えるだけでメンテナンス費とヘルプデスクへの呼び出しを大幅に削減できます。
(中略)
テストは技術というよりは文化なのです。こういったテスト文化は、使用する言語に関係なくプロジェクトに植え付けることが可能なのです。
フェルン「いまのはテスト駆動開発です。」
多くのプロジェクトでは、こういったレベルのビルドは毎晩自動的に実行されています。つまり、プロジェクトの特定部分を夜間ビルドで作成すると同時に、個別のテストよりも完全なテストを実行できるのです。これによって、完全なビルド実行時に行うテストをすべて実行させることも可能になります。結果として、その日のうちに回帰テストの問題を見つけられるようになるわけです。ソースの変更後、できるだけ早い時点で問題を検出できれば、バグの検出と修正を円滑に進められるようになるはずです。
フェルン「いまのは CI/CD です。」
]]>一番コア機能というか、問題が起こりそうな中核部分を書き始めると、
案の定、最初の予想通りにはいかないことが判明し、完成予想図ノ変更を強いられる。
いろいろ調べて解決策を見つけて、まぁ、これならちゃんと完成するだろう。
って思えた時が、一番完成に近い図が見えてる感じかな。
でも、その後も細部まで作りこむにつれて新たな問題がみつかり、
目指す完成形はコロコロ変わって行く。
紆余曲折あって、ようやく機能を満たすという意味で完成し、
公開したり納品して評価を頂くのだけど、
実際その時点は、出来栄えに満足してなくて、リファクタリングなどしつつ、
俺のプログラムの完成はこれからだ!
となって終わる。
]]>ありがとうございます。
]]>正直、実験して結果を確認するのが怖いからしてる。
もし想定と違う結果が出たらどうしようって思うと実験開始に踏み切れない。
怖いよ。
もちろん結果が想定と違っても、原因を調査して再実験するんだろうけど、やっぱり怖い。
不安になると死にたくなる。
身近な不安のない暮らしを送りたかった。
そんなのないか、多分。
]]>