テストとリファクタリングに関する深い方法論 #wewlc_jpレガシーコード改善勉強会 in Yahoo Japan 2014.09.27 プロジェクトに対する方法論構築と、タスクマネジメントについての紹介 後半はMikado Methodの簡易紹介です。
Google Engineering Practices Documentation (日本語訳)
Google Engineering Practices Documentation (日本語訳) Google には、全言語および全プロジェクトをカバーする広範なエンジニアリングの慣行があります。 ここにあるドキュメントは私達が長年の経験からさまざまなベストプラクティスを蓄積してきたことを表しています。 この知識がオープンソースプロジェクトや他の組織の利益になることを願って、私達は可能ならそれを誰にでも利用できるように公開します。 現在、以下のドキュメントがあります。 Google コードレビューガイドライン。これは 2 つのドキュメントからなります。 コードレビュアーのガイド 変更作成者のガイド 用語 ここにあるドキュメントには、Google 内部で使われる用語があります。外部の読者のために意味を掲載しておきます。 CL: 「changelist」の略。一つの独立した変更を意味していて
テストの自動化とテスト駆動開発
組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
リファクタリングチームに入ってから学んだ理解しやすいコードを書くための基本的なこと - クラウドワークス エンジニアブログ
こんにちは！ 去年の４月に新卒入社してからお酒ばかり飲んでいるエンジニアのd4teです。 4月から11月まではUX改善チームにてお仕事検索画面のフロントエンド開発を担当しておりましたが、11月からはリファクタリングチームにてcrowdworks.jpのリファクタリングをしています。 現在のcrowdworks.jpの状況 過去の記事にもあるように、crowdworks.jpはサービスインから約8年が経過し、30万行を超えるモノリシックなRailsアプリケーションになってきていて、コード行数の増加量やファイル変更数の推移は年々鈍化してきています。 内部には開発生産性を低下させる技術的負債が溜まってきており、技術的な投資がしづらくなってきているという課題があります。 自分が所属しているチームは、外部から見た動作を変えずに内部のコードを整理するリファクタリングで技術的負債を解消し、開発生産性の向
良いコードの書き方 - Qiita
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
