ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT docomo Business Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
Java SE 9の紹介: モジュール・システムを中心に
Java SE 9を、新たに導入されたモジュール・システム（Jigsaw）を中心として紹介します。JJUG CCC 2017 Fallの発表資料です。 補足: p. 7 正しくは「JMX」→「JMS (Java Message Service)」。JMXはJava SE内の、モニタリング用の仕組みです。 p. 43 これに加えて、SPIの実装を提供するモジュールも、モジュールレイヤーに含まれます。具体的にはConfiguration.resolveAndBindの動きです。 p. 47「Oracle JDKでは、外部モジュールの非公開メンバへのリフレクションが可能」は、OpenJDKでも同じ動作です。「HotSpot系の」とすべきところでした。 このスライドはCC Attribution Licenseの元に、利用・改変・再配布をライセンスします。
Less is more：プログラミング言語設計の進歩史 | POSTD
多くの言語は冗長性を有していますが、これらの機能を省いていくことも言語設計の進歩につながります。 巷には数多くのプログラミング言語があり、新しい言語も継続的に紹介されています。でも新しいものが古いものより優れているかというと、そうとは言えません。なぜなら、何が“優れているか”を判断する明確な尺度は存在しないからです。 それでも過去からの流れを見ていくと、優れた言語を作る1つの方向性は、言語にある冗長性を特定し、それらを持たない新たな言語をデザインすることにあるように思えます。 「完璧とは、それ以上足せない時ではなく、それ以上引けない時に達成される」 – Antoine de Saint Exupéry この投稿では、現在までに知られている言語の冗長的機能を見ていくと共に、恐らく冗長性を有しているだろうと思われる機能についても触れていきます。 自ら墓穴を掘るあらゆる可能性 初めてコンピュータ
隊長、Androidアプリのソースがぐちゃぐちゃであります！！ - Qiita
複数の責務をFragmentやActivityに押し込めてるのが原因です。 公式サイトに書いてあるようなこともありますが、今一度まとめてみました。 -- Activityの長さが10000行を超えました！！とても保守できません！！隊長！！ 初期のAndroid開発は手探りでした。Activity、Intent等、大きな枠組みでは優れてましたが、その上の層に関してはノータッチでした。 皆Activityが単位として大きすぎるのは理解してましたが、多くの人はActivityにコードを詰め込む道を選びました。フレームワークを 使う ことに慣れすぎて、 作る ことには不慣れだったのです。 とはいえ、そんなコードはすぐ破綻します。それではまずいということで、GUIフレームワークの知見のある人達は、各々、オレオレフレームワークを内部で抱え込むことになりました。暗黒時代です。 しばらくして、開発が追いつ
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
やさしい設計 〜 Android 編 - Qiita
アプリを作っていてありがちなこと Android には、画面を構成するための Activity というコンポーネントがあり、概ね MVC フレームワークの Controller に相当する機能を持っています。 MVC といえば、肥大化する Controller というのがよくある問題として挙げられますが、Activity も例に漏れず、往々にして肥大化しがちです。 また、Model も、その責務を詰め込んでいくと肥大化しやすいレイヤと言えます。 この投稿では、Controller や Model の肥大化を極力防ぐためのレイヤわけを、Android アプリ向けに書いていきます。 Activity を綺麗に保つ Activity は、Controller として、様々な UI から受けるイベントを受けて、適切にハンドリングする役割を持っています。 OptionsMenu や ContextM
一つのメソッドに上から下にずらっと全部書いてしまう現象の考察 - basyura's blog
とある機能を実装するとする。例えば外から Excecute が呼ばれてその結果を返すような場合。多いのが Execute メソッドの中に全部書いてしまって、何 10 行を超えて何回スクロールするんだろうになっているパターン。その際はレビューで以下のようにアドバイスする。 Execute にはシナリオを書いて、中身は別に書くと良いですと。僕の経験的にこの方が良かった、という深い根拠のないものではある。けど、間違った考えとも思わない。自然だろうと。private なメソッドではインスタンス変数を直接扱うのはやめて、public なめそっどから引数で渡したほうがいいとか細かいところもあるけど、そのへんはすっ飛ばしてまずは上記のようにいう。 そんな考えを持っているので、レビュー依頼されたものやコミット済みの資源をなにかの機会で見たときに、上記に反するものを見かけると気になってしまう。 もうちょっと
若作りするためのJavaコード - 谷本 心 in せろ部屋
このエントリーは Java Advent Calendar 2012 の10日目として書きました。 なんか色々あって、公開が2日ぐらい遅れてしまってごめんなさい（＞＜） 前日は、Hideki Kishida (@quicy) さんの「Xtend の Lambda とストリーム処理」です。 http://legacy-style.blogspot.jp/2012/12/xtend-lambda.html 翌日は、Katsumi Kokuzawa (@kokuzawa) さんの「WiiRemoteJで遊ぼう on OSX 10.8.7」です。 http://kokuzawa.github.com/blog/2012/12/11/wiiremotejdeyou-bou-on-osx-10-dot-8-7/ どちらも今風ですね！ そんな中、若干、加齢臭が気になり始めたこの頃の私としては、 若さアピ
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
言語女子会2: varは必要？/privateがない？ - 西尾泰和のはてなダイアリー
言語女子会: undefとnullは両方必要？の続編です。 varは必要なの？ とあるプログラミング言語が集う女子会にて: Python: JavaScriptちゃんってさ、なんでvarだらけなの？ JavaScript: えっ、変？ Python: varなんかいらなくない？私ぜんぜん持ってないよ？ JavaScript: えー、じゃあ変数をどうやって宣言するの？ Python: 宣言っていうか…「x = 1」みたいな代入文があれば変数xが必要なのって自明じゃない？宣言とか必要？ Ruby: 必要ないよね。っていうか変数宣言とか古臭くない？ JavaScript: そうかなー。 Python: 少しダサイかも。ほら断舎離ブームだし要らないものは捨てなきゃ！ JavaScript: 要らないかなぁ、変数宣言。Pythonちゃんは関数がネストしているときに外側のスコープの変数に代入するのって
ProxyパターンとProxyクラスと黒魔術 - プログラマーの脳みそ
Java Advent Calendar 2011 の18日目です。 17日目の記事は JavaEE使ってウェブアプリケーションつくろうよ - 水まんじゅう2、 19日目はJavaエバンジェリストの寺田さんですよ。乞うご期待。 プロローグ 後:「先輩、いまさらなんですけど上からSQLの遅いところを調査してくれって依頼がきてて、全クエリの実行時間を実データで集計とれと言ってるんですけど。これ、SQL発行前後で時間計測するしかないですかねー。このプロジェクトどんだけクエリ発行してるところあるんだろ…。簡単にやれないですかね。とりあえず調査に1週間かかるって返答しちゃいましょうか」 先:「まぁまて。全部のクエリにもれなく時間計測のコードを挿し込むとかやってられんし、手作業で漏れも発生するだろ。こういうのはオブジェクト指向で解決するのがスマートだ。あ、とりあえず調査に1週間かかるとは返答しておけ」
2011年度生物情報科学演習 リファクタリングとデザインパターン
コードのリファクタリングとデザインパターン C++, Javaなどオブジェクト指向の考え方、クラスを上手に使うとコードをよみやすく整理できる場合が多くあります。 プログラムの動作を変えずにコードを整理することをリファクタリングと呼びます。 最初からコードを上手に設計するのは、熟練のプログラマでも難しいものです。少人数で開発する場合は、むしろ積極的にコードをリファクタリングし、アルゴリズムの見通しをよくするとよいでしょう。コードを修正する際にはversion管理ツールを使えるようにしておくと安心です。以前のソースコードの状態にいつでも戻せます。 ソースコードの版管理ツール Mercurialの使い方 http://www.xerial.org/wiki/lecture/2010/Mercurial デザインパターンに関しては、GoF本や結城浩さんの本などを読むと理解はできると思いますが、
Java7 で ArrayList の foreach が速くなった理由を調べてみました。 - 地平線に行く
Java7でList/TreeMap/TreeSetのIteratorがかなり早くなって、 ArrayListのforeach文（拡張for文）も、普通のfor文より早くなりました。 コレクションの細かい話、だが面白い！ - 谷本 心 in せろ部屋 そうなんですか！？ …と思って試してみたところ、ArrayList の foreach文（拡張for文）が Java6 → Java7 で約2.5倍速くなっていました。 手元の環境では、普通の for 文より速くなることはなかったものの、ほとんど気になならないぐらいの差でした。 - 2011年11月26日 訂正： 速くなっていたのは ClientVM で実行した場合のみで、ServerVM では変わっていませんでした。 詳しくは、Javaの実行速度を調べるなら、ClientVM/SeverVM の違いを考慮しておくべきでした。 - 地平線に行
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
Javaプログラミング能力認定試験課題プログラムのリファクタリングレポート（その１） - 達人プログラマーを目指して
昨日書いたSI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指してが予想以上に大きな反響があり驚いています。特に、あの有名なひがさんにもSI業界の現状と未来に関してコメントをしていただきました。（SI業界からはさっさと抜けだしたほうがいい） ただし、SI業界の今後がどうかということや新しいサービスを使ったビジネスのことについては、私自身最先端技術に十分にキャッチアップできておらず、自分の考えを整理できていないため、一旦考えないことにして、ここでは例の試験問題の設計とリファクタリングについて考察してみたいと思います。具体的な例に基づいて説明することで、オブジェクト指向がSI業界の多くの方々に考えられているほど理解不能なものなのではなく、問題を単純化し、プログラムの保守性を桁違いに向上させるうえできわめて重要な役割を果たすということ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いコードとは
from old Java to modern Java