タグ

開発と資料に関するryownetのブックマーク (3)

  • 10年以上続くサイトを初めてリニューアルして感じた事 | Basicinc Enjoy Hacking!

    ) 4月1日に10年続くとあるWebサービスをフルリニューアルしました。 リニューアルの目的は、システムが度重なる機能拡張により、必要以上に複雑化してしまい、ちょっとした修正でも非常に時間がかかるので今後、事業のスケールを拡大していく上のが難しくなってきたためです。 特に大きなところですと、スマホサイトがリニューアル前のサイトだと、スマホとPCで機能が完全に分断されてしまっていました。サイトを立ち上げた当初はスマートフォンすらなかった時代なのでしょうがないとは思いますが、これをこれ以上保守していくのはしんどいので、スマホファーストの思想を取り入れサイトを設計していきました。 技術的にも、PHPからRubyに変更して、ELBやS3をとりいれ、Githubベースの運用に変更することで、時代の流れに取り残されていたWebサイトを今風な感じの仕組みへと変更しました。 リニューアル自体はプロジェクト

    10年以上続くサイトを初めてリニューアルして感じた事 | Basicinc Enjoy Hacking!
    ryownet
    ryownet 2015/04/13
    会議に時間がかかる、テストに余裕がない、フレームワークとか環境を一新する、で一通り苦労したこと
  • いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道

    最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 (なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

    いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
    ryownet
    ryownet 2012/02/20
    仕様はその内容ではなく成立した過程に意味がある。仕様は変わるがメタロジックは変わらない(適当に決めた、偉い人が決めたetc)から過程を基準に考える
  • 基本設計書のアウトライン(案) - tomoyamkungの日記

    今度こそ基設計書のアウトラインを作成してみた。今後また作成することもあるだろうからメモとして残しておく。 基設計書として以下の4ドキュメントを作成。 環境設計書:使用するサーバと構成について アプリケーション設計書:アプリケーション全体の設計、個々に切り出される機能について 開発手順書:開発手順、コーディングルールなど 運用設計書:運用全体の考え方、納品したお客さまが参照する操作マニュアル類 環境設計書 構成図:サーバの構成についての説明と図示(APサーバ、データベース、イメージ専用サーバ、(メールサーバ)) 使用ソフトウェア:OS、APサーバ、データベースの名称、バージョン、URLなど アプリケーション設計書 プロダクト構成:使用するフレームワークやライブラリについて 構成図:MVC2モデル図 プロダクト:DI、ORM、ajax、テストなどで使用するプロダクトの名称、バージョン、UR

    基本設計書のアウトライン(案) - tomoyamkungの日記
    ryownet
    ryownet 2009/07/30
    基本設計書
  • 1