2024年11月29日　遅れニュース：Replit有料加入／優れたソフトウェア開発習慣

Replitの1年間有料会員登録

AIプログラミングツールを使ってみる必要がありそうなので、12月1日までのブラックフライデーセールで登録しました。

これを選択した理由は、まともなパソコンを持っていないからです。

• コンパイラやインタプリタをローカルにインストールする必要がなく、ブラウザで実行と結果確認が可能
• 環境設定を心配することなく、プログラミングを学べます。
• 共同コーディングプロジェクト。（私がリンクを共有すれば、ペアプログラミングが可能です）ー必要であれば、誰でも一緒にやりましょう。
• コードの迅速なプロトタイピングとテスト。
• 対話型方式で生徒にコーディングを教えます。
• 軽量なウェブアプリケーションまたはAPIのホスティング。

今後はこれを使って動画も撮ってみないといけませんね。 https://replit.com/

世界を見よう。（様々なニュース）

経済

2024-11-29（金）モーニングルーティン（韓国経済新聞）：韓国金利引き下げ3.25 → 3.0％／所得格差拡大、消費減少／エックスブルショルダー（ウェアラブルロボット）／条件株ETF20％好調（外国人投資家によって購入されているとされる）

＞＞結局、外国人投資家が買わなければ株価が上昇する方法がないですね。

IT

参照リンク1，参照リンク2

優れた開発者になるために守るべき10個の習慣

＞＞テレマティクス／クラスタプラットフォームを作成、維持管理する中で私が感じたこと、しかし、それをきちんと実行することができなかったのですね。変化を恐れてはいけない、そしてここにあるように細かく分けて実行すれば可能になるでしょう。

原文：韓国語、英語

1. "これくらい小さくても大丈夫かな？"と思うくらいコミットを小さく保ちましょう。
いつ特定の変更をロールバックしなければならない事態になるかわからないからです。6日前に発生したバグの正確な位置がわかり、複雑なマージコンフリクトなしにそのコミットだけをロールバックできるということは大きな安心感を与えてくれます。私の基準は簡単です。コンパイルできるコードであればコミットできます。

2. ケント・ベックの格言を実践しましょう：「望む変更を行うために、まずその変更を容易にし（注意：これが難しい場合があります）、それから容易になった変更を行いなさい。」

"望む変更を行うために、まずその変更を容易にし（注意：これが難しい場合があります）、それから容易になった変更を行いなさい。"
全コミットの半分以上がリファクタリングになるようにしましょう。継続的なリファクタリングとは、10分以内で行える改善策を見つけて適用することです。このような小さな改善のおかげで、後で大きな要求が来た場合でも、簡単な変更だけで解決できるようになります。大規模なリファクタリングは避けるべきです。

3. すべてのコードは負債です。
デプロイされていないコードは負債の中の負債です。コードが正しく機能しているか、少なくとも他の機能を壊していないかを確認する必要があります。テストは自信を与え、本番デプロイは検証を提供します。頻繁なデプロイによりホスティングコストがわずかに増加する可能性がありますが、最後の作業が実際の前進であったことを確認できるという点で十分に価値があります。アジャイル原則の1つは「動作するソフトウェアが進捗の主要な尺度である」ということです。ここで"動作"と"進捗"という言葉が重要な意味を持つため、独自の定義を設けました。"動作"とはデプロイ可能なレベルを意味し、ある機能に貢献するコードであればそれが"進捗"です。

4. フレームワークの機能をテストしているかどうか自問自答してみましょう。もしそうなら、やめましょう。
フレームワークはすでにあなたよりもはるかに専門的な人々がテストしており、useState()フックが意図したとおりに動作すると信頼する必要があります。コンポーネントを小さく保つことで、フレームワークがほとんどの主要な作業を処理するため、多くのテストは必要ありません。コンポーネントが大きくなると複雑さが増し、それだけ多くのテストを作成する必要があります。

5. 特定の関数がどこにも合わないと感じたら、新しいモジュール（またはクラスやコンポーネント）を作成し、後で適切な場所を見つけましょう。
合わない場所に無理やり押し込むよりも、新しい独立した構造を作る方が良いでしょう。最悪の場合でも、独立したモジュールとして残ることはそれほど悪くありません。

6. APIがどのようなものになるべきかわからない場合は、まずテストを作成しましょう。
これは、この場合あなた自身である"顧客"の視点で考えるようにします。先にコードを作成し、後でテストしたのでは発見できなかったケースを見つけることができます。TDDに過度に教条的である必要はなく、より大きな単位で作業しても構いません（例：テストがパスする前に複数の行のコードを作成）。失敗状態のコードの量が常に少ない必要はありません。何をしているのかわかっているなら、原則が生産性を阻害しないようにしましょう。

7. コピー＆ペーストは一度までは大丈夫です。
二度目の重複（つまり三度目のコピー）はやめましょう。この時点では、良い抽象化を作成できる十分な事例があるでしょう。同じ機能の実装が互いに異なるリスクが大きすぎるため、統合が必要です。似たような機能を何度も実装するよりも、多少ぎこちないパラメーター化の方が良いでしょう。このような状況が再び発生した場合、4つの異なる実装を統合するよりもパラメーターを改善する方が簡単でしょう。

8. 設計は古くなるものです。
リファクタリングによってその速度を遅らせることはできますが、最終的には動作方法を変更する必要があります。かつて大切に思い、誇りに思っていたものを捨てる時、あまり悲しまないでください。当時は最善を尽くし、変更する必要がないほど完璧にできなかったと自分を責める必要はありません。ソフトウェア開発の大部分はソフトウェアを変更することです。それを受け入れて前進しましょう。完璧な設計はなく、変更はソフトウェア開発の中核です。どれだけ巧みに変更できるかが、開発者としての能力を決定します。

9. 技術的負債は3つのカテゴリーに分類できます。
1）現在の作業を妨げるもの、2）将来の作業を妨げるもの、3）将来の作業を妨げる可能性のあるもの。他のすべての分類は、この3つのサブセットです。#1に該当するものを最小限に抑え、#2に集中しましょう。#3は気にしなくて大丈夫です。

10. テスト可能性は、優れた設計と密接に関連しています。
簡単にテストできないということは、設計を変更する必要があるという合図です。時には、その設計がテスト設計であることもあります。例えば、em.getRepository(User).findOneOrFail({id})をモックするのが難しい場合は、その呼び出しをモック可能な別の関数に分離するか、エンティティマネージャーメソッドを簡単にモックできるテストユーティリティを作成することをお勧めします。テストが作成されない理由は、テストしたくないのではなく、テストするのが難しいからです。