InfoQ ホームページ Software_Craftsmanship に関するすべてのコンテンツ
-
古いシステムと現代的な技術のギャップを埋める
手動で時間のかかるやり方で管理されている、長年動かし続けているプラットフォームはコストがかかる。チームは経営陣に対してビジネスケースを作ることで、繰り返し作業やヒューマンエラーで失われた時間に基づいて、自動化ツールやコンテナのような現代的な技術を導入して改善ができる。結果として、配置作業は予測可能で反復的なプロセスになり、配置も頻繁かつ安全に行えるようになり、人間の介在も最小限になる。
-
リーンでEコマースを再構築する
Auchan Franceのオンライン食料品サービスであるAuchan:Directは、新しいEコマースウェブサイトの開発にリーンを導入することにした。CEOが最初の顧客であり、新しい体験をした顧客からの継続的で高速なフィードバックを使って、ウェブサイトの品質を継続的に改善した。
-
リーンスタートアップのスケーリング: プロセスの原則
大組織はリーンスタートアップのようになろうとするが、アジャイルな組織となるためには、いかにスタッフを雇い、彼らにインセンティブを与え、マネージするかを考え直す必要がある。組織はチームに対して、即座に学習して低リスクの決定を下すことに対して報奨を与え、デリバリーに加えて学習の価値を高めるべきだ。
-
モノリスあるいはマイクロサービスの技術的負債を占う水晶玉 - Amam Tornhill氏の考察
QCon LondonでAdam Tornhill氏は、“A Crystal Ball to Prioritise Technical Debt”と題して講演し、技術的負債のメタファがソフトウェア界に浸透したにも関わらず、いまだ大部分の組織が技術的負債の優先的な返済に苦慮している点を指摘した。講演では、“コードの複雑性とチャーン(churn)の‘ホットスポット’を特定するには”、などの話題が取り上げられた。
-
アジャイルテストの習得
一般的に、アジャイル開発プラクティスを採用すると、ソフトウェアのデリバリーを高速化できると受け取られている。しかし、開発プロセスにQAプラクティスを直接組み込んでおかないと、プロダクトの品質低下は避けられない。たえず高品質を実現するためには、最後にテストするのではなく品質を作り込めるように、仕事のプラクティスとチームの役割の両方を変える必要がある。
-
TextTestを使った承認テスト
承認テスト(Approval Testing)は、現在のコードの出力を、“承認済”バージョンのものと比較するテスト技術だ。承認済バージョンは、事前にテスト出力を調査して、その結果を承認することによって作成する。要件が変更された場合でも、承認済バージョンを再検討することで簡単に更新することができる。テキストベースのオープンソース機能ツールであるTextTestは、この承認テストをサポートする。
-
デッドコードは取り除かなければならない
デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。それは考え方と文化の問題だ。
-
Eric Evans氏はDDDが完璧主義者のためのものではないと述べた
ドメイン駆動設計(DDD)の当初からの問題は完璧な設計を求める探求行為であるが、DDDは完璧主義者のものではない。この探求を止めるために、完璧ではないがよく設計されたソフトウェアの開発方法に関する発想を得ることが必要であると、Eric Evans氏はアムステルダムで開催された最近のDDD Europe Conferenceにおける発表で述べた。
-
10%の自主タイムで学習を向上させる
学習のためにチームで10%の時間を自主的に使えるようにすると、納品までの時間が減少し、品質やモチベーションが向上する。10%ルールでは、自分たちが重要だと思うことに取り組むために、チームに完全な自主性を与える。これにより、チームメンバの創造性を解放し、チームは潜在能力を成長させられるようになる。
-
AtlassianのQA
AtlassianでクラウドQAマネージャを務めるMark Hrynczak氏は同社の今年のサミットで高い価値のQAチームはどのように振舞うかについての氏のビジョンを語った。氏は、QAチームの価値を、第一に企業の戦略���目的と完全に足並みを揃えること、と定義している。足並みを揃えることで、企業が特定のタイミングで直面するかもしれない重要な問題の解決に貢献するのだ。
-
Barclayがアジャイル移行で得たもの
スループットの向上，コードの複雑性の低減，運用時の障害減少，デプロイメントサイクルの短縮，チームの幸福度向上 — これらはみな，Barclaysがアジャイル移行で実現したメリットだ。ディシプリンド・アジャイルに基づいて実施された同社の移行は，最初の１年間で800以上のチームにアジャイルを採用するという，アジャイルの実践例として最大級のものである。
-
Coolblueの継続的デプロイメント
継続的デプロイメントは結果的に，より高い責任感とデプロイメントの品質向上をもたらす - CoolblueのテクニカルパスファインダであるPaul de Raaij氏は，このように主張する。コーディング標準はコードベースの混乱を防止し，自動化されたインスペクションは退屈で単純なチェック作業に効果がある。そして手作業によるチェックは，ロジックやコードの利用の妥当性のチェックに最適な方法だ。
-
優れたエンジニアリングプラクティスによって"常に出荷可能な製品”を実現する
優れたエンジニアリングプラクティス(Good Engineering Practice)は，アジャイルチームが出荷可能な製品を提供するためのツールだ。効果を証明されたエンジニアリングプラクティスはたくさんあるが，期待されるほど広くは活用されていないのが実情である。結果として，アイスクリームコーン型ソフトウェアテストなどアジャイルのアンチパターン，技術的負債の蓄積，機能的サイロが，���リース可能な製品の提供を妨げているのだ。
-
リファクタリングとコードの臭い – きれいなコードへの旅
リファクタリングは、より理解しやすく、メンテナンスしやすい、きれいなコードにするのを助けてくれる。それにはコードの臭いを嗅ぐ経験と実践が必要だ。つまり、コードの中にあるより深い問題を示す悪い設計の兆候を見つけることだ。コードを壊すことなく、小さなステップでリファクタリングを行うことを支援するツールもある。
-
自動運転車のソフトウェア開発にモデルを使用すること
モデルは自動運転車のような自律システムのソフトウェア開発において重要な役割を果たしている。モデルは振る舞いのシミュレートや検証、システムの文書化、そしてコードを生成するために使用される。Jonathan Sprinkle氏が、自律システムで使用するモデルをどうモデリングするか、モデリングの利点、テストデータを用いてどう自動車を運転するソフトウェアを検証するか、信頼性のあるコードを記述するための技法を説明する。