※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。
原文
Principles of Code - Five Key Points to Better Systems - DEV Community
意訳+要約
このブログでは、コードの原則について述べられています。以下がそのまとめです。
可読性の重要性: コードは他の人や将来の自分が理解しやすいように書かれるべきであり、明確な変数名やコメント、構造化されたコードが必要です。
一貫性の確保: コードは一貫性を持つ必要があります。命名規則やフォーマットの統一、スタイルガイドの遵守が重要です。
単一責任の原則: クラスや関数は一つの責任を持つべきであり、これに従うことでコードがシンプルで理解しやすくなります。
依存関係の最小化: コンポーネント間の依存関係を最小限に抑えることが重要であり、少ない依存関係は変更を容易にします。
テスト可能性の確保: コードはテスト可能であるべきであり、テストしやすいコードは品質が高く、バグを見つけやすく修正しやすくなります。
ゾンビ戦略の重要性: ゾンビコード（メンテナンスが放置されたコード）はプロジェクトにとって脅威です。そのため、ゾンビコードを排除するための戦略が必要です。
ボーイスカウトルールの原則: ボーイスカウトルールは、コードを修正した後でもそのコードがプロジェクトの品質を向上させるようにする原則です。修正したコードが他のコードよりも良い状態であることを確認することが重要です。
- 修正時の注意点: ボーイスカウトルールを適用する際には、修正したコードが他の部分と一貫性を持ち、プロジェクト全体の品質を向上させることを確認する必要があります。修正したコードが他のコードと調和しているかどうかを常に意識しましょう。
これらの原則を実践することで、より良いシステムを開発することができます。
ChatGPTへのQA
Ｑ：ゾンビ戦略とは、一般的なワードなのでしょうか？
「ゾンビ戦略」は、一般的な用語ではありません。この文脈では、ゾンビ戦略とは、メンテナンスが放置されたコード（ゾンビコード）を排除するためのアプローチや戦術を指しています。一般的な会話や業界外ではあまり使われることはありませんが、ソフトウェア開発などの技術的な文脈では理解される場合があります。
Ｑ：日和見リファクタリングは、日本のエンジニアがしがちに思いますが、日本特有でしょうか？
日和見リファクタリングは、日本特有の現象ではありません。この概念は、プログラミングやソフトウェア開発における普遍的な課題の一つです。日和見リファクタリングとは、特定のコードや機能を改善することを避け、問題が起きたときにだけ修正するというアプローチを指します。
このようなリファクタリングの回避は、エンジニアリングの分野で広く見られます。原因としては、リソースの制約や時間の圧力、新しい機能の開発に対する優先度の高さなどが挙げられます。これは文化や地域によるものではなく、ソフトウェア開発における一般的な課題です。
ただし、個々の文化や組織の特性によっては、特定の傾向が強調されることがあります。日本のエンジニアが日和見リファクタリングに対して敏感であると感じる場合もあるかもしれませんが、これはあくまでその文化や組織の特性によるものです。
感想＋雑記
要約にはなかったが、日和見的リファクタリングってワードにすごく興味を引かれた。
思い返すと、場当たり的なリファクタリングをする現場が多かったなと感じる。
それは、意思決定をする人と実際に修正する人の距離が遠すぎるのが問題なように感じる。
たぶん、サービス開発している会社は、大胆なリファクタリングとかができるけど、SIとかの仕事だと難しい気がする。
少し前に、小さいけど緊急の要件追加で、改修をこうした方がいいと指示したけど、出てきたものが現行踏襲してて、直すように強く言えなかったのを、結構後悔してる。結局、現行踏襲したせいでバグにつながってるからなぁ。。。
もう少し、自分を信じる必要があるとも思った。
リファクタリングは、技術だけじゃなく、確固とした自信を持って押し通す力が必要だと感じている。あと、ソフトウェア工学に精通していれば、もっと大胆に言えたのかもしれない。
日和見って言われると、アスラン・ザラを思い浮かべるのだが、俺だけ？
どっちの陣営につくんや！って、SEEDの放映見ると思ってしまう。
でも、そのおかげて敵同士だったのが仲間になるってのがいいんだよなぁ。
映画ではブレなかったな。
アスランのイジり方が、公式が一番熟知しているのだと感じさせられた。
