InfoQ ホームページ Code_Quality に関するすべてのコンテンツ
-
技術的負債を防ぎ、返済する方法：チームと技術リーダー、マネージャーができること
技術リーダー、プロジェクトマネージャー、管理職は、ソフトウェア開発者に多くの時間を与えることで技術的負債を防ぐことができる。さらに、チームがコードを改善できるように、余剰時間やリファクタリングスプリントを計画することができるとNedelcho Nikolov氏は主張する。技術的負債に優先順位をつけるために、開発チームは、今投資すればどれだけの時間を節約できるか、今技術的負債を返済しなければ将来ソフトウェアがどれだけ複雑になるかを示すことができる。
-
Booking.comがDORAメトリックスとマイクロ・フロントエンドを使用して配信パフォーマンスを倍増させる
Booking.comのフィンテック事業部のチームは、プラットフォームのバックエンドとフロントエンドにわたって一連の改善を実施し、DORAメトリクスで測定されるデリバリー・パフォーマンスを2倍にできた。さらに、マイクロフロントエンド（MFE）パターンを使用して、モノリシックなFEアプリケーションを複数の分解アプリに分割し、別々にデプロイできるようにした。
-
安定性とユーザーフレンドリーを両立したUIを作るには
UI構築における重要な課題は、使いやすさと保守性、そして規模や複雑さのバランスを取ることだ。安定し、かつユーザーフレンドリーなUIを作るには、思慮深いコンポーネント設計と一般的な使用経路の理解が必要だ。自動化は、コードベースの効率と一貫性を改善する上で、画期的な変化となりうる。
-
コードを読む上での課題とその対処方法
コードの読むことは、多くの点で混乱を招く可能性がある。コードの読み方は明確に教えられておらず、コードの読み方を練習することはめったにない。ある役割を果たす認知プロセスを認識することは、コードをより適切に読むのに役立つ。
-
モブプログラミングの集団的習慣は技術品質を高めるための土壌になり得る
モブ(mob)プログラミングは、プロダクトをアジャイル手法で開発する上で、古い習慣を新しく効果的な習慣に変えるための有効な手段だ。周りを人に囲まれた環境において集団で培われた習慣は、簡単に忘れることはない。モブプログラミングは各メンバに対して、新たな習慣を定常的に実践させることによって、それらを取り入れやすくする。チームは同じ作業の繰り返しを容認しない。仕事を行うためのよりよい方法を探しているのだ。
-
AWSがAmazon CodeGuruの一般提供発表
最近AWSは、機械学習を利用した開発者向けツールであるAmazon CodeGuruの一般提供を発表した。 コードの品質を改善し、アプリケーションの最も高価なコード行を識別するためのインテリジェントなリコメンドを提供する。
-
壊れたコードがマージされることを防ぐGitHub Super Linter
GitHub Super Linterは、GitHubリポジトリの設定プロセスを自動化して、プルリクエストが作成されるたびに適切な静的解析ツール(lint)を使用することを目的としている。
-
組織トポロジと品質への影響
August Lilleaas氏は先頃、Microsoftの論文を引用して、組織の複雑性とソフトウェア品質との相関関係に関する記事を書いた。Rapid Software Testing Methotologyを開発したJames Bach氏も先頃、品質のメトリクスの解釈方法について記事を書いている。さらにTeam Topologiesの著者たちは、組織構造がソフトウェアプロダクトの健全性に及ぼす好影響について意見を述べている。
-
保険業スタートアップでのモブプログラミングから学んだこと
チームで2人の開発者が、3日間、ひとつの仕事に掛り切りになっていたら、あなたならどうするだろう？ある保険業のスタートアップは、チーム全体でモブプログラミングを試す決定をした。その結果、モブを始めた初日から、コードベースに対する知識が向上しただけでなく、一緒に作業することによって、お互いをよりよく知ることができたため、チームとしての効率も高くなった。
-
TDDの5つの前提 - GeePaw Hill氏に聞く
TDDは単なるテクニックではない、プログラミング全般のスタイルであり、関連する行動や考え方の統合システムである。TDDの5つの前提は、我々が活動するリングを提供する。それらはTDDを行うものが呼吸する大気なのだ。
-
コードレビューの実際
コードレビューは、バグを見つけたり、他のチームメンバーからインプットを得たり、知識とオーナーシップを共有するのに最適な方法だ。最大の恩恵を受けるには、コードレビューを開発プロセスに統合して、レビューされていないコードが本番環境に投入されないようにしなくてはならない。レビューは、開発プロセスにおける解決を必要とする未解決問題を明らかにするのに役立つ。
-
なぜ、どのように、いつ読みやすいコードを書くか
ほとんどの開発者が読みやすいコードを欲している。開発チームは機能性より読みやすさを好ましいと思っているかもしれない。しかし、読みやすさを定義しようとすると、意見が割れる。Explore DDD 2018でLaura Savino氏はなぜ読みやすいコードが良いのか、読みやすさとはどういうことなのか、他の考慮点よりも読みやすさが絶対的に優先度が高い場合はどんな場合か、について話をした。
-
持続可能なソフトウェアとアジャイル
持続可能なソフトウェア(Sustainable software)は、変更をより短期間で顧客に提供するとともに、バグ可能性の低減、アプリケーションの総所有コストの削減、ビジネスアジリティの向上を可能にする。ソースコードの自動解析、専門家による技術的アーティファクトのレビュー、ベンチマークデータの比較を組み合わせることで、ソフトウェアの持続性を検証することが可能になる。
-
Meetupでの技術的負債の取り組み
継続的に製品の健全性を保つには定期的に一番影響のある技術的負債を優先順位付けして、それらを全体的に解消していくことだ。MeetupのCTOであるYvette Pasqua氏は、技術的負債に対する取り組み方を継続的に繰り返し適用することでより大きな成果を生み出すことを推奨している。最も影響の大きい負債から取り組み、その負債を解消したことで生まれる改善について伝える、というのが氏の主張だ。
-
モノリスあるいはマイクロサービスの技術的負債を占う水晶玉 - Amam Tornhill氏の考察
QCon LondonでAdam Tornhill氏は、“A Crystal Ball to Prioritise Technical Debt”と題して講演し、技術的負債のメタファがソフトウェア界に浸透したにも関わらず、いまだ大部分の組織が技術的負債の優先的な返済に苦慮している点を指摘した。講演では、“コードの複雑性とチャーン(churn)の‘ホットスポット’を特定するには”、などの話題が取り上げられた。