オープンセミナー2017@岡山
オープンセミナー2017@岡山
みなさん、PHP書いてますか？ここ2ヶ月くらいPHPも書いていたのでその話を書きます。 この記事はVOYAGE GROUP techlog / Advent Calendar 2016の記事です。 例えば以下のような話に身に覚えはありませんでしょうか。 例外がどこかで握りつぶされており、例外的状況なのにエラー表示がまちまち。レスポンスステータスも一貫性がない。エラーログが適切に出ていない。 エラーログ出力用コードがいろんなところで散乱している。エラー文字列整形のための適当なヘルパメソッドがクラスごとに実装されている。 エラーごとにエラー表示のためのメッセージを設定するのが面倒になり、「システムエラーが起きました」とだけ表示されるようになってしまった。 例外ハンドリング周りのコードは考えるのが面倒なのでコピペだらけになっている。 オブジェクトの依存関係がクラスのプロパティに大量に埋め込まれて
単なる延命策ではない、進化させるという発想！ コードがレガシーになるのはなぜでしょう。その要因を特定し、 コードベースの品質を上げるためには、なにをすればいいのでしょう。 本書はこれらの古くて新しい質問に真摯に答えてくれるでしょう。 単純な（でも難解な）クラスやメソッドレベルのリファクタリングから、 モジュールあるいはコンポーネント全体を視野に入れた、広い範囲のリファクタリング。 また、最終手段としてのリライトに関するノウハウ（機能低下の予防方法や回避方法、 各種データのスムーズな移行など）を示します。 また、単に手を動かすだけではなく、いつもソフトウェアをフレッシュにしておくべく、 自動化のための方法論や、そのインフラストラクチャの作り方を詳解します。 「動いているものは触るな」が鉄則のソフトウェアを、それでも要請に応じて よりレスポンシビリティの高い、そして新機能を盛り込まれた、 メン
Releases, Offers & More Be the first to hear about our newest content, best promotions and upcoming events. Plus get 25% off your next purchase. Newsletter Sign Up Download Accounts Your email address is your account identifier. You can create a password, or just download from the links sent via email. My Orders (Resend order emails) How We're Different Hands-on instructions Solutions to real-worl
こんにちは！開発の所(@ctokoro_me)です。 クラウドワークス勉強会「レガシーコード改善の戦略と戦術」前篇（戦略）に続き、後篇（戦術＆懇親会）をお送りします。 「レガシーコード改善の戦略と戦術」 講師：和田 卓人(@t_wada) タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。 その後様々な縁に導かれソフトウェアパターンやXP（eXtremeProgramming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。 テスト駆動開発によって「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」から解かれてからは、文章や講演、ハンズオンイベント等を通じてテスト駆動開発の啓蒙に努めている。 今日もグリーンバンド（テスト駆動開発者の証）を左手に着
こんにちは！年初からクラウドワークス開発に新たにジョインした所と申します。 先日、クラウドワークスではテスト駆動開発とRESTFulアーキテクチャのエバンジェリストとして有名な和田卓人さんをお招きして社内勉強会を開催いたしました。 和田さんは、数多くの会社にてレガシーコード改善のコンサルティングの経験をお持ちで、書籍も多数執筆されており界隈でも有名な方です。 また、弊社CTO大場の旧知の友人でもあります。 クラウドワークスのサービスは立ち上げから現在に至るまでRuby on Railsで開発を行っており、サービス拡大に伴いアプリケーションの規模も大きくなっています。 比較的テストが書きやすいフレームワークではあるものの、ビジネスの急激な成長を支えるために速度を優先した機能開発が行われていた時期もあり、レガシーコードが残っている部分があります。 将来に向けて技術的負債の返済をしていくことは、
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27（土）の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード（テストコードが無いコード）と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 ＜開催趣旨・目的＞ テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、
今日テストなくてめちゃくちゃに壊れてるアプリケーションのテストを一から書いてて、わりと書けてよかった。午前中セットアップに手間取ってて、午後からテスト書き始めて、小さいアプリケーションだったのでC0 90%くらいまでいけた。3年間くらいテストないせいでびくびくみんな触っててめちゃくちゃに壊れててよくなかった。テストえいって書けば書けるんだから、隙を見て書いていきたい。ずっとテストのあるWebアプリケーション眺めてるのでだんだんコツが分かって気がする。まず最初にCIに載せて、カバレッジ測れるようにする。面倒だけど、これやっておくと後で役立つ。普通にテスト書くと、実行環境までは定められないけど、CIがあれば、そこをベースに議論できる。最初は、アプリケーションのルートのモジュールをuse_okするだけ、くらいでまず通して、カバレッジも取れるようにする。たとえば、MyAppっていうアプリケーション
はじめまして。荻原といいます。グリーのプラットフォーム部門で、サーバーサイドのエンジニアをしています。 昨年末ぐらいまで業務の空き時間にテスト周りでごにょごにょと動いていたので、今日はそのことについて書かせて頂きます。 こんな人は読むと役に立つかもしれません。 レガシーなプロダクトになんとかして突破口を開きたい PHPUnit の書き方で参考になりそうなものを探している Ruby でスマートフォンのブラウザ操作を自動化したい 経緯 こちらでも言及されている通り、サービスを運営している以上、時には技術的負債に向き合わなければなりません。GREEも歴史が長いプロダクトなので、日々コードをリリースしていく中でそういった問題に頭を抱える場面もありました。 技術的負債による副作用はたくさんありますが、どういう点に不安を感じていたのか、実際に開発の現場に立って感じたことをいくつか書いてみたいと思います
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
はい、というわけで自分のトークです： 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました： 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
色々忙しい時期が続き報告にかなり間が空いてしまいましたが、少し前にxUnit Test Patterns読書会の最終回に参加させていただきました。 このxUnit Test Patterns読書会、前のWorking Effectively with Legacy Code読書会から連続して続くもので、初期のころから参加させていただいています。プログラマの読書会コミュニティとしては初めて参加した勉強会であり、かつ参加してから丁度3年経過したということで、今回ちょっと振り返ってみたいと思います。 WEwLC読書会との出会い この読書会への参加は、流し読みしていたIT勉強会カレンダーでたまたま「Working Effectively with Legacy Code」という書名とその第一回読書会を見つけたのがきっかけとなっています。当時レガシーコードに悩んでいたこともあり最初は個人で読み進めて
目的 業務で現在、とても厄介なC#コードと戦っています。途方に暮れかけていましたが、TDDBC札幌で教えていただいたことから突破口が見えてきました。感謝の気持ちを表しつつ、ちょっとした現状メモです（それにしてはすごく長くてすみません）。 正確には「戦ってみた」じゃなくて、「戦い始めた」ですね。 敵のデータ どんなアプリケーションか C#で書かれた（一部C++もあるが）Windowsフォームアプリケーション。ドライバ的なところからビューアまで、かなり巨大。 とりあえず今自分が見ているところはビューアの改造とかのわりと表層的な部分。C#のみ Visual Studio 2008 Professional Edtionで開発 コードの状態 コードの質が悪すぎる。今までみたコードの中で最もひどい コピペコード多すぎ。とにかくところかまわずがんがんコピペ状態。 メソッド長過ぎ。クラスがでかすぎ。Cじ
TDDしたい、CIしたいと思ってもなかなか導入できない。何でだろう？ PHP製WebアプリケーションでのTDDを学び始めた現時点の気持ちまとめ。 Seleniumを使うような高いレイヤーのテスト どんなテストを書けばいいのかわからない 例えばDBから商品情報取ってページ生成する場合。 商品カテゴリごとに異なる趣きのページを作るのでそれぞれにviewのテストを書いたとする 各ページ内の商品詳細URLにパラメータが追加されることになった URL生成は共通のモデルで行っている 修正は一ヶ所で簡単なもの だったとしてもviewのテストはそうは行かない。 先に用意したテストケースを全部書き直さなきゃならない。 小さな変更にかかるコストが大きくなる 単純に時間がかかるというより めんどくさくなる → どうせやらなくなる という思い。 コントローラーとか中間くらいの層のテスト viewよりは下、ユニット
Every once in a while, people ask me whether I'm going to do a 2nd Edition of 'Working Effectively with Legacy Code.' I've dodged the question for quite a while because, on the one hand, it would be nice to move on. There are so many other things I'm interested in. On the other hand, I've learned a lot since the book was published and it would be a shame to just let that all slip away. These da
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
