デッドコードは取り除かなければならない
デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。Kevlin Henney氏によると、それは考え方と文化の問題だ。 独立したコンサルタントでトレーナであるKevlin Henney氏が、ヨーロッパテストカンファレンス 2017において、基調講演「やり方の間違い」を行った。この基調講演で、デッドコードが実行されたために、ある企業が何億ドルもの損害を被ったことを発表した。 InfoQは、このカンファレンスをQ&A、要約、記事で扱う。 ソフトウェアの失敗は、個人的に不便だったり、迷惑だったりするが、経済的、または、社会的に重大な影響を与えることもある。Henney氏は、小さな不具合のせいで、何百万ドルもの損害を出した例をいくつか
コードレビューをより効果的にする方法
ツールに任せることができないどんなことを人間は指摘できるのだろうか？ 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか？ コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか？ 新しいコードでデザインパターンは使用されているだろうか？これらは適切だろうか？ コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか？コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか？ コードは正しい場所に配置されているだろうか？例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか
よいコードを書くために，プログラマは何をすればよいのか
よいコードを書くためには，設計の基本を守り，既存のコードを読むことが必要である – Java ChampionでハイパフォーマンスコンピューティングのスペシャリストであるMartin Thompson氏のことばだ。InfoQは，QCon London 2016で“Engineering You”と題した講演を終えた氏に，ソフトウェア産業が直面する課題は何か，プログラマがそれを克服して優れたソフトウェアエンジニアになるにはどうすればよいのか，などをインタビューした。 InfoQ: 講演の中であなたが引用した，1986年の，ソフトウェアエンジニアリングに関する最初のNATOカンファレンスの内容は，現在でも通用します。ソフトウェア産業がいまだ問題を解決できないのはなぜでしょう？ Martin Thompson: 1986年のNATOカンファレンスには，たくさんのテーマがありました。彼らはソフトウ
チームレベルのパフォーマンス最適化をすべきでない理由とは
Klaus Leopold氏がGOTO Berlin 2015カンファレンスでの講演で，チームレベルのパフォーマンスの重視が多くの場合，局所的な部分最適化を引き起こし，結果としてチーム全体のアジリティが向上しない理由について，詳しく説明した。InfoQは氏にインタビューして，なぜアジャイルフレームワーク導入がアジリティ向上に結び付かないのか，コラボレーション向上にかんばんをどのように利用すればよいのか，チームがかんばんに期待できるメリットは何か，などを聞いた。 InfoQ: アジャイル手法で開発を行なうために，かんばんを採用しているチームの話をよく聞きますが，あなた自身が開発に参加したチームではかんばんをどのように使用していたのか，例を紹介して頂けますか？ Leopold: 私はかんばんを使って，さまざまな分野で仕事をしています。古典的なハードウェア開発からマーケティング，管理，人事部門や
リファクタリングにありがちな誤解を解く
.NETコミュニティにおいて、リファクタリングが遅いスタートを切ったと言っても間違いではないでしょう。.NET開発者向けの主要製品であるVisual Studioは、C#においては、現在もなお、Refactoring Rubicon（http://www.martinfowler.com/articles/refactoringRubicon.html）を渡っているとは言えません。Visual Basic、あるいはより最近のものであるC++では、状況は改善されていますが、それは無償のリファクタリング・アドイン、Refactor!をダウンロードし、Developer Expressで開発されたVBやC++にインストールした場合に限られます。 その後の選択肢は、すべて代金を払わなければならない製品となります。確かに、これらの製品は投資をするに値しますが、企業買収の歴史を理解すれば、「コード品質
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google：マネージャはやはり重要な存在である
Googleと完璧なチーム
過剰なエンジニアリングを止めて、顧客が本当に必要とするものを作ろう
アジャイルは”再び"死んだ
インクリメンタルGCとシンボルGCを備えたRuby 2.2.0がリリース
自己組織化チームはなぜ必要か？
自己組織化されたアジャイルチームを確立する
ITILとDevOps - その観点の違い
ParseがRubyからGoへ移行，信頼性が大きく向上
アジャイルで欠落するテストの能力
注目を集めるリアクティブプログラミング
アジャイル組織における"勇気あるコミュニケータ"の重要性
iOSで継続的デプロイメントを実現するfastlane
「Ameba流Scrum」を浸透させるために私たちが実践したこと
昔ながらの企業にDevOpsを導入する