ドメイン駆動で開発する ラフスケッチから実装まで
4. 拙い設計 • コードが重複しまくっている • 条件分岐の密林があちこちにある • どこに何が書いてあるかわからない • 変更した時にどこで何が起きるか推測できない • やっていることは解読できるが、なぜ、そこでそ の処理が必要か意味がわからない • パッケージ名/クラス名/メソッド名/変数名/コメン トが嘘だらけ • でも動いてる 動いていなければ、ろくでもない設計であることは誰でもわかるのに… 4 5. 善い設計 • コードの重複がなくなる • 条件分岐の密林がなくなる • どこに何が書いてあるかわかりやすくなる • 変更した時に影響範囲を限定しやすくなる • 処理の意図がすぐわかる • パッケージ名/クラス名/メソッド名/変数名が わかりやすく正確になる – コメントはむしろノイズ 5 ドメイン駆動設計を実践すると、自然にこうなっていく
ドメイン駆動設計の学習曲線とブレークポイント
15. ９つのルール 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 15 16. 名前をつける 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 16 パッ
現場から届けるアジャイル開発(5) パラレルプログラミングとは？
パラレルプログラミングとは、要件定義や設計中にプログラミングを並列に(パラレルに)実施するという手法です。この手法は、近年自分がチームリーダーを務める全てのプロジェクトで採用している手法です。今回は「パラレルプログラミング」を導入するメリットについて考えていきます。 これは、一般的にシステム開発では最も行なってはいけないとされている方法の1つです。通常は要件定義で何を作るかを明確化し、そして設計でどのように作るかを決めてから実装に入ります。アジャイルではイテレーション開発などで開発期間を短く何度も繰り返す進め方をすることが多いと思いますが、それでも要件定義で何を作るのかを明確化し、設計でどのようにつくるかを決定してから進めることが多いはずです。 パラレルプログラミングでは要件定義すら決まらないうちに作り出すというのですから、どういうこと？と疑問を持たれる方も多いでしょう。 上流工程での不具
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
Chromebookに開発環境を実装する方法2 ― Chromebrew編
前のエントリーでchromebookに開発環境を整えてくれる「Nitrous.io」のChrome用パッケージドアプリを紹介しました。Cloud9 IDEと同じようなクラウドベースのサービスです。 でも、無料のSTARTERプランのせいか１週間アクセスしないとワークスペースを削除されてしまいます。それに、ワークスペースを開くのに、すごく時間がかかります。 パッ開けば、すぐに使えるChromebookの長所が台無し。もっとサクっと使いたいと思い、探してみるとパッケージマネージャーがありました。先人に感謝 ChromeOS用パッケージマネージャー「Chromebrew」 Mac OS X オペレーティングシステム上でソフトウェアの導入を単純化するパッケージ管理システムのひとつである「Homebrew」。これのChromeOS版「Chromebrew」がありました。 Chromebrewでは、/
WordPressコアコントリビューターに聞く「ぼくのかんがえた最強の開発環境」
WordPressで開発をするなら、いまどきどんなツールを使うのがいい？ WordPress専門のデベロッパーであり、コアコントリビューターでもあるMatt Geriさんがおすすめるする、最高の開発環境とは？ 近年、WordPressによる開発は大きな進展を遂げています。特に、ツールに関しては。以前は、WordPressでサイトを構築しようものなら、ほぼ確実にMAMP/WAMPのローカルホスティングの設定をしなければならず、それはもう悩みの種でしたよね。ひょっとしたら、本番の状態でサイトの開発を進めなければならなかったりしました。 そう、私もその一人でした。 幸い、時代は変わり、いまではそんな頭痛の種や反復作業を取り除くツールが出てきました。 WordPress開発業者としてフルタイムで開発をしていた私は、WordPressから離れて丸3年後の2015年12月、再びフルタイムのWordPr
フォローアップ – WordPress テーマの継続的インテグレーション #wck2016 | WP-E (仮)
どうも、featherplain こと Hinotan です。WordPress のカンファレンス WordCamp Kansai 2016 で 「WordPress テーマの継続的インテグレーション(CI)」 という、割りとニッチな話をしてきました。 以下の内容はセッション中やスライドで触れなかったことだけをかいつまんで書く形になるため、スライドを見た前提で進んでいきます。スライドとあわせて読んでいただいて、少しでも参考になれば幸いです。 テストツールの導入について スライドの中盤あたりで紹介をしている PHP CodeSniffer (PHPCS) や WordPress Coding Standards, PHP Mess Ditector (PHPMD) は Composer 経由でインストールできます。もちろん単体でインストールもできますが、Composer の方が管理が楽なので
PHP初心者は最低限これはやっとけ - 開発に入る前編 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 主に経験談。 PHP初心者が初めて自分で何かするとか業務で何かするとかいうレベルを想定。 準備 PHP7.0を選べ PHP5.5は2016/07/10にサポート期限が切れた。 2016/07/10時点では、今からサーバ構築するならPHP7.0を選択すべきだ。 新規開発なら、もうPHP7.0を使ってもいいだろう。速いし。 使用予定のフレームワークがPHP7に対応していない等の理由があるならば、PHP5.6を選択する余地もあるだろう。 5.6と7.0以外のバージョンは、現時点ではそもそも選択肢に入れるべきではない。 HHVMとかは理解ってる
レガシー開発環境を今風の開発に近づけるために一年やってきたこと - Qiita
#自己紹介 @pugiemonn といいます。 オンラインサロンプラットフォームを手掛けるシナプス株式会社で開発とマーケティングを担当しています。 #今日の話 1年前にレガシー環境に参加したメンバーがレガシーな問題に対して、どのような取り組みを行ってきたかお話します。 #開発チームメンバーゼロ問題 #社長１人で3年開発していた １人で走るのはつらい 突然ユーザー数が増加しはじめピンチに #求人がんばった結果 チームメンバー10名（インターン生含む）になりました✨ バージョン管理されてない問題 #1人だったのでバージョン管理など無かった GitとGithubを導入した結果 まずはSourceTreeから 作業ログがわかるようになった 問題発生箇所の調査が容易に #作業がチケット化されていない問題 #1人だったのでチケットなど無かった 何のタスクかわからない チケット管理した結果 何の作業かわ
Composer WordPress Development Kit 3.0.2 をリリースしました。 - Toro_Unit
Composer WordPress Development Kit 3.0.2 をリリースしました。 Composer WordPress Development Kit という、Composer と PHP のビルトインサーバーを使って、WordPress 環境をサクッと立ち上げるものを以前作ったんですが、バージョンアップしました！ Composer で WordPress 環境をさくっと立ち上げるやつを作りました。 使ってみていろいろ気になったところなどが出てきたのでかなり大幅に変更しました。 変更点などなど ドキュメントルートをディレクトリ直下に変更しました。なので、サーバー上 で WordPress を立ち上げるときも同じコードをそのまま使えるようになりました。Git の Webhook を使って、レポジトリが変更されるたびに、自動デプロイ出来るようになったりしてます。デプロイ自
既存のコードの理解が捗るChrome DevToolsの使い方 - kitak blog
jQuery系ライブラリによるDOM操作が中心のプロジェクトにがっつり機能を追加する機会があった。 そのJavaScriptのコードは他の人から引き継いだコードで、一応引き継ぎ時にディレクトリ構成、設計、実装方針について共有を受けたが、それでもいざ手を入れようとすると自分自身のコードの理解が進んでおらず「えーっと...」となってしまった。 上記以外にも、長年、多くの人が触れてきたJavaScriptのコードに機能を追加する、修正するのはなかなか難しいのではないか、と思う。最初は、ちょっとしたユーザビリティの向上のために書かれたスクリプトが、気がつけば多数のDOM操作、至る所で宣言される変数、どこから実行されるか分からない関数群で無秩序に膨れ上がり、頭を抱えることになる(そうならないようにするのがウェブフロントエンジニアがいるひとつの理由ですが…)。 これらのケースでは、まずは修正、あるいは
ロードマップ指向とエコシステム指向 - アンカテ
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
[ようやく見つけたかもしれない]WordpressサイトをGit管理する方法[メモ] - Qiita
Wordpressってどうやってソース管理するのが正解なんでしょうか。 皆様いろいろ工夫しているようですが、あまりピンとくるものがなかったので、Wordpressはソース管理できないものと諦めておりました。 でも、WP-CLIなんてものを知ってからちょこちょこ試してみたところ、もしかしたらようやく見つけたかもしれないのでメモっておきます。 はじめに エンジニア目線です 全てのカスタマイズはthemes/mywebsiteフォルダにまとまっていると仮定します DBとuploadsフォルダは管理しません その他、faviconやgoogleのトラッキングコード？は適宜管理に追加します 準備 WP-CLIをインストール WP-CLIとは Wordpressの諸々の設定をコマンドラインから行えるツールです。 詳しい事はこのあたりを参考に。 WP-CLIの使い方 - Qiita インストール cur
![[ようやく見つけたかもしれない]WordpressサイトをGit管理する方法[メモ] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/24c18462a6f14a18a0aa27a9c527c7159d8cb2ab/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgyJTg4JUUzJTgxJTg2JUUzJTgyJTg0JUUzJTgxJThGJUU4JUE2JThCJUUzJTgxJUE0JUUzJTgxJTkxJUUzJTgxJTlGJUUzJTgxJThCJUUzJTgyJTgyJUUzJTgxJTk3JUUzJTgyJThDJUUzJTgxJUFBJUUzJTgxJTg0JTVEV29yZHByZXNzJUUzJTgyJUI1JUUzJTgyJUE0JUUzJTgzJTg4JUUzJTgyJTkyR2l0JUU3JUFFJUExJUU3JTkwJTg2JUUzJTgxJTk5JUUzJTgyJThCJUU2JTk2JUI5JUU2JUIzJTk1JTVCJUUzJTgzJUExJUUzJTgzJUEyJTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1mMzU1NjQ5Nzg3OWM2MTAxNjJjYjdkYzI1OTA5NWFlZg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBnb29zeXMmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTA4ZGMxNWNjZGU5YWRlMzIyMjMxYzk3MjQwNmEyMDAy%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3De3ddc80a51f56a4be47badb0eec4df52)
Windows 環境に戻るために必要そうなモノたち (ポエム) - Qiita
Ubuntu で UNIX 環境を学び、Windows 環境を脱却したのは何年前だったか。その後 OS X に移行し、NIX 互換シェル環境を快適に利用してきた。しかし今 Windows にしかない、ほしい環境がある。この際 Windows 10 を境に真面目に舞い戻ってみる試みのためのノート。 今のところ、全部妄想です。 開発環境 Visual Studio - Microsoft Developer Tools Microsoft がオープンソースに肩入れし始めたのも今は昔。かつては高級有償開発環境であった Visual Studio も、今では無償で利用できる! Visual Studio Community 2015 で快適な IntelliSense 環境をフリーで利用できる!! VsVim extension Visual Studio 用の優秀な Vim エミュレーションプラ
Homebrewでローカル環境構築 : WordPress | FindxFine
通常はVCCWで開発しているがちょっとした確認にPHPのビルトインサーバーを使うことがある。 HomebrewでMacへPHP, MySQLをインストールしWordPressを動かすまでのメモ。 VCCWでの開発は下記にまとめている。 ローカル開発環境 VCCWのメモ : WordPress Homebrew — The missing package manager for OS X PHPインストール $ brew install php56 MacにデフォルトでインストールされているPHPではなく Homebrewで新規にインストールしたPHPをシェル(Bash)が参照するよう.bash_profileのパスを設定する。 $ export PATH=$(brew --prefix homebrew/php/php56)/bin:$PATH 確認 // バージョン $ php --ve
Webアプリケーションの構成に関する予備知識 - Qiita
自分の担当したWebアプリケーションを引き継ぐ際に、予備知識として説明したことのまとめ 注意事項 もともと明確に定義されていない概念や、簡単に説明するため正確さを犠牲にした部分が多い 間違っていることを前提に、疑いながら読むのがベター アプリケーションの層構造 アプリケーションを構成するオブジェクトには非常の多くの種類がある アプリケーションの（より良い）構成をオブジェクト単位で考えるのは難しいので、もっと粒度の大きい単位で考えたい アプリケーションをいくつかの層（オブジェクトの所属するグループ）に分割し、層単位でアプリケーションの構成を考える View層（ビュー層） レスポンスをクライアントにとって都合のいい形（i.e. 画面）に変換する層 View層のオブジェクトは Controller層のオブジェクトから利用される DomainModel層のオブジェクトを利用して、ユーザーに表示した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WordPress Cli による環境構築 - Qiita
IDDD本から理解するドメイン駆動設計一覧
大串 肇
