開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
Javaのクラスとオブジェクトについて再度解説を試みる - 達人プログラマーを目指して
オブジェクト指向プログラミングの考え方については、今までこのブログでも何度か取り上げてきました。 [オブジェクト指向] - 達人プログラマーを目指して オブジェクト指向プログラミングはプログラミング技法のすべてではないとはいえ、Javaのようなオブジェクト指向言語で本格的なプログラムを作るには理解を避けて通ることができませんし、また、関数型言語など他のパラダイムの言語を利用するにしても、オブジェクト指向の考え方をまったく理解しないまま使いこなすということは困難でしょう。オブジェクト指向の考え方はデータ構造やアルゴリズムといったことと同様に、プロフェッショナルなプログラマーが理解しておくべき基本的な素養といってもよいと思います。実際、海外では募集要項でオブジェクト指向の理解を前提とすると書かれていることが普通ですし、プログラマーの面接試験で、アルゴリズムと並んでオブジェクト指向プログラミング
すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して
このたび9月末日をもってオージス総研を退職し、10月よりアマゾンジャパン株式会社に入社しました。今後はSoftware Development Engineerとして、日本をはじめ世界各国のAmazonのモバイルWebアプリケーションの開発を担当することになる予定です。 およそ7年間にわたり、前職のオージス総研ではソフトウェアアーキテクトとして、SOAやEAといった全社的なシステムのアーキテクチャから、上流のモデリング、Java EEを使ったアプリケーションの開発など、技術者として様々な経験を積ませていただきました。私自身はこのブログでも何度も取り上げてきたように、モデリングやオブジェクト指向といった技術を用いて、実際の基幹業務システムの設計などに活用することで、高品質で保守性の高いシステムの構築に貢献したいという思いがありました。そのようなシステムを構築、維持するためには高品質なアーキテ
staticおじさんとオブジェクトおじさんはお互いに分かり合えるようになるかもしれません。 - 達人プログラマーを目指して
先日書いたstaticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指してのエントリに、なんと、みながわけんじ氏ご本人よりコメントを頂きました。もともとは一般のstaticおじさん達（英語ではstatic ojisansという感じ）に向けて書いたのですが、思いがけず、元祖staticおじさん（The static ojisanあるいはMister staticといった感じ)ご本人からのご意見をいただき、本当に嬉しく思います。 オブジェクト指向の再利用性と非オブジェクト指向の関数やサブルーチンとの違いを明確に示していないから いろいろ理屈を込めても無駄ではないでしょうか？ 誰かが作ったクラスを継承して再利用したところで、バグが少なくて、メンテナンス性がいいものができるでしょうか？ そんなものをあてにするより、天才が作ったクラスライブ
ConQATを利用してソースコードの品質をチェックする - 達人プログラマーを目指して
ある程度プログラマーとして経験を積めば、ソースコードを読んだときに、そのソースコードの良し悪しというものは、嗅覚を使って直感的に嗅ぎ分けることができるものです。実際、そのように体の感覚を使ってこのコードは不吉だと感じるところは実際大いにあり、コードの臭い（code smell)として知られています。 コードの臭い - リファクタリングの必要性を示す兆候 これはファウラーの名著 リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見るでも紹介されており、こういった不吉な部分を適切に嗅ぎ分け
Java EEサーバーが重くてテスト不能というイメージはもう過去の話かもしれない - 達人プログラマーを目指して
Java EE 5まではいろいろな面で生産性が低かったと言わざるを得ないところがあった 今まで仕事上、Java EEのサーバーを実行基盤として用いるさまざまなシステムの開発に関わってきましたが、JavaEE（古くはJ2EE）のサーバーというと経験上 xmlの設定ファイルの記述がきわめて面倒 J2EE1.4までは、EJBを使った場合Pojoとしてサービスやエンティティを作成できない サーバーの再起動にものすごく時間がかかる ライセンス料が高い サーバーを気軽にダウンロードして試せない というような非常に悪いイメージがあったというのが正直なところでした。 それゆえ、JavaをSEとEEに分類するのは今では無意味になってきている？ - 達人プログラマーを目指してでも紹介したように、Seasar2やSpringといった軽量コンテナというしくみが登場し、事実上EJBコンテナの機能はほとんど利用せず、
ドラゴンボールで学ぶオブジェクト指向 改（第弐話） - 達人プログラマーを目指して
ドラゴンボールでオブジェクト指向の学習という元ネタのアイデアがうけたのか、ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指しての記事がかなり大きな反響がありました。前回の記事では、クラス図とデザインパターンを使った設計により、ドラゴンポールの世界をモデル化する例について説明しました。ただし、この説明の内容だと、静的なモデリングに偏っていたところもあり、具体的にどのようにプログラムの設計に役に立つのかという点が見えにくいところがあったかもしれません。今回は、前回説明しきれなかった、いくつかの点について、もう一歩踏み込んで説明してみたいと思います。 プログラミング言語におけるクラスとオブジェクト 前回の記事では、概念的なオブジェクト指向モデリングの観点から、 クラス→複数のオブジェクトが共通で満たす性質（属性や振る舞い）を概念として表現したもの。（地球人武道家、サイヤ人、戦
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://ryoasai.hatenadiary.org/entry/20110321/1300696942