タグ

ブックマーク / objectclub.jp (8)

  • - eXtreme programming FAQ

    Kent Beckらによって提唱されているソフトウェア開発プロセス(工程)です. 正式には eXtreme Programming ,略してエックスピー(XP)と呼ばれます. 開発リスクを早期に軽減することを主眼におき,繰り返し型 (iterative)の開発を取り入れている点は,RUP(Rational Unified Process) な どのオブジェクト指向プロセスと同じです.ただし,次の点が XP の大きな特徴です. 開発の中でコーディングおよびテストという工程に特に重点を置いている 初期設計よりもリファクタリングによる再設計を重視している すぐにでも始められるライトウェイトな方法論である 明確な言葉で XP を行うための「12のプラクティス」が示されている そして何より,「プログラマは人間である」という温かな視点による思想 が全体を通して流れていること,これがエクストリームプログ

    rydot
    rydot 2019/09/28
  • オブジェクトゲーム

    © NEC Corporation 2006 オブジェクト・ゲーム ~コードを使わず最速でオブジェクト指向がわかる方法~ 2006年 6月29日 NECシステムテクノロジー 第一産業ソリューション事業部 牛尾 剛 © NEC Corporation 2006 CIO プロセス改善/生産革新部門 管理者 普通の技術者 出来る技術者 ・オブジェクト指向がわかった ・最新アーキテクチャが理解できよう になった ・一般の技術者でもオブジェクト指向が わかってもらえるぞ ・オブジェクト指向ベースの手法が使え るようになるな ・はじめてオブジェクト指向とPJでどう 使うかがわかった ・すぐには導入しないけど、事例が増え たら使ってもいいかも・・・ ・はじめてオブジェクト指向とPJでどう 使うかがわかった ・アーキテクチャが違った見方ができる ようになった ・独学でわかりにくいところがわかった ・後輩に

    rydot
    rydot 2016/03/29
  • オブジェクト倶楽部 - TOPページ

    当サイトは ... ソフトウェア開発に関する技術について実践、研究、発表するグループ、「オブラブ」のページです。 XP及びモデリング、PFについてのコミュニティや、ドキュメント、フリーソフトウェアで構成されています。

  • PF ふりかえりガイド

    Copyright (c) 2006-2022 ESM, Inc. Oblove, AMANO Masaru 1/60 プロジェクトファシリテーション 実践編 ふりかえりガイド (株)永和システムマネジメント オブラブ 天野勝 第 1 版 2006 年 6 月 7 日 第 30 版 2015 年 8 月 23 日 第 31 版 2015 年 8 月 30 日 第 32 版 2015 年 11 月 24 日 第 33 版 2016 年 4 月 25 日 第 34 版 2018 年 1 月 27 日 第 35 版 2021 年 5 月 13 日 第 36 版 2022 年 10 月 30 日 オリジナル:http://ObjectClub.jp/community/pf/#material このドキュメントは、クリエイティブ・コモンズ・ライセンス(帰属 2.0)の下 で提供しています。このライ

  • ObjectClub - ソフトウェア原則 ちょっと横道 その2 Name and Conquer

    前回は、名前に関するエピソードとして、「Joshua Tree Principle(名前を知 ることで、見えなかったものがめるようになるという法則)」を紹介し、名前の 重要性を指摘しました。今回はもう1つの名前に関するエピソードを紹介します。 それは、「問題を解く方法」に関するものです。数学の問題解決法を分析し、 大きく2つに分けると、 (1)Divide and Conquer(分割攻略) (2)Name and Conquer(定義攻略) になるそうです(*1)。Divide and Conquerは複雑な問題をより単純なサブ問題 に分ける方法です。ごく普通の考え方です。ソフトウェア開発に例えると、そ れはサブシステム分割や構造化分析設計になるでしょう。 (2)Name and Conquerは少し変わっています。これは、「名前を付ける」方法 です。 「まだ未知だが、とりあえずこの数を

    rydot
    rydot 2012/08/23
  • - ソフトウェア原則 ちょっと横道 その1

    前回は、SRP(Single Responsibility Principle)を解説し、抽象(あるいはク ラス)は一つの責務を持つべきこと、また、よい名前を持つことが質的であ ることを書きました。何人かの方から感想を頂き、特に名前の重要性について 賛同していただきました(ありがとうございました)。 さて、そこで今回と次回は趣向を変え、名前についてのエピソードを紹介したいと思います。 来のソフトウェアの原則シリーズから逸れてしまうので、「ちょっと横道」です。 名前に関する横道1 JTP: Joshua Tree Principle この原則は私が大好きなデザインのである、"The Non Designer's Design Book"(*1) の冒頭で、著者のRobin Williams(*2)が述べている法則です。 彼は、自分が住む町の図書館で植物図鑑をたまたま見ているときに、Jo

    rydot
    rydot 2012/08/23
  • - 自動化のための nmake 入門講座

    2001/09/24 石井 勝 はじめに ここでは,make ユーティリティを使ってプログラマやSEが行う作業を自動化するための方法を解説したいと思います. make は,単にプログラム開発作業だけでなくいろいろな作業を自動化してくれます.自動化する作業のプラットフォームとして make を活用することができます.ところが,最近のプログラマは統合開発環境を使っているせいか, make を理解できる人が非常に少なくなってきました.今やっている開発でも,Makefile をメンテできるのは僕一人という非常にまずいことになっています.また, make について書かれたサイトや書籍が非常に少ないことも敷居を高くしている原因です.make について少しは知っているけど,あまり使いこんだことがない人はこの記事を参考にしてみてください. ところで,make といってもいろいろな種類があり,それぞれ仕様が

  • - 継続的インテグレーション

    継続的インテグレーション 原題: Continuous Integration Martin Fowler Chief Scientist, ThoughtWorks Matthew Foemmel ThoughtWorks 「確実なビルドを行う」 -- これはどんなソフトウェア開発プロセスであれ重要なことだ。そのわりには、このことがきちんとされていないことに驚かされる。論文では、Matt が ThoughtWorks 社でのある大規模プロジェクトにおいて採用したプロセスを紹介する。このプロセスは全社的な広がりを見せつつある。テスト部分も含めて「全てが自動化された」「再現可能な」ビルドを、「日に何度も」行うことに力点がおかれている。このプロセスを用いれば、開発者はインテグレーションを毎日行うことになるので、インテグレーションに伴う問題を減らすことができる。 継続的インテグレーションの恩恵

    rydot
    rydot 2010/07/12
  • 1