開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？ - 達人プログラマーを目指して
皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、本年もどうぞよろしくお願いいたします。 さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。 グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して この記事では、一般にSIerによって開発される日本のシステムはあの事件のおせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて 最近はOSSやクラウドなどの影響で社内システムもどんど
ここぞというときの集中力Upのために、ヘッドフォンで音楽を聴きながらプログラミングしましょう - 達人プログラマーを目指して
仕事や趣味でプログラミングしたり技術書を読みながら勉強したりする際には、言うまでもなく集中力を高めて維持することが大切ですね。職業プログラマーに必要な集中力ということには少なくとも二つの意味があるとは思いますが、 単純に正確に繰り返しキーをタイプしたり、Excelシートをひたすら埋めるような単純作業を一定時間以上継続する 新しいアルゴリズムの設計やリファクタリングのアイデアを構想する いずれにしても、自分の場合は寝不足だったり、周りの雑音で気が散ったりしてコンディションが悪い時にはあまり集中できずに、圧倒的に作業効率が下がってしまいます。逆に、調子よく集中できた時には時間がたつのも忘れて一気に仕事を片付けることができます。 もちろん、プログラミングで集中力を高めるためには、日頃から規則正しい睡眠や食事などが欠かせませんが、ここぞという時に一人で集中するにはヘッドフォンで音楽を聴くのが個人的
すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して
このたび9月末日をもってオージス総研を退職し、10月よりアマゾンジャパン株式会社に入社しました。今後はSoftware Development Engineerとして、日本をはじめ世界各国のAmazonのモバイルWebアプリケーションの開発を担当することになる予定です。 およそ7年間にわたり、前職のオージス総研ではソフトウェアアーキテクトとして、SOAやEAといった全社的なシステムのアーキテクチャから、上流のモデリング、Java EEを使ったアプリケーションの開発など、技術者として様々な経験を積ませていただきました。私自身はこのブログでも何度も取り上げてきたように、モデリングやオブジェクト指向といった技術を用いて、実際の基幹業務システムの設計などに活用することで、高品質で保守性の高いシステムの構築に貢献したいという思いがありました。そのようなシステムを構築、維持するためには高品質なアーキテ
普通の構造化プログラマーがオブジェクト指向の存在意義を理解するコツ - 達人プログラマーを目指して
オブジェクト指向言語の存在意義を理解するのは難しい？ id:amapetasさんによる、ちょっと興味深い記事がありました。 オブジェクト指向言語が流行した必然性について考える(1) - Programmer’s Log そして、その記事の中で説明されているのですが、やはり、C言語など構造化言語のプログラマーにとってはオブジェクト指向の存在意義を理解するのがなかなか難しいところがあるようですね。 初心者向けの書籍を最近読んでいないので、最近の書籍ではうまく説明されているのかもしれませんが、そんな話を聞いたことがないので、たぶん今でもオブジェクト指向に関する説明の始まり方は 「世界は全部オブジェクトで出来ているんじゃぁぁーーー」 という「オブジェクト至高教への洗脳」から始まっているものと推察しますw テンション高めの説明から入るのでドン引きする人多数な感じがかなりアレですね。オブジェクト指向の
SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ
Java EE6で単体テストや結合テストを自動化する方法について - 達人プログラマーを目指して
今週水曜日に、オラクル青山センターで行われたGlassfish Japanユーザーグループの勉強会でJava EE6のお話をさせていただきました。勉強会のスライドとビデオは以下のリンク先にあります。 Glassfish勉強会（JavaEE6について） View more presentations from Ryo Asai http://www.ustream.tv/recorded/16552906 今回は基本的に私がこのブログで書いてきたJava EE6関連の情報について紹介させていただきました。欲張って少し内容を詰め込み過ぎたところがあったかもしれませんが、Java EE6を使った単体試験や結合試験の自動化については、説明をスキップしてしまい、ちょっとわかりにくくなってしまいました。ここで、あらためてJava EE6上のアプリケーションのテスト自動化について簡単に補足させていただき
staticおじさんとオブジェクトおじさんはお互いに分かり合えるようになるかもしれません。 - 達人プログラマーを目指して
先日書いたstaticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指してのエントリに、なんと、みながわけんじ氏ご本人よりコメントを頂きました。もともとは一般のstaticおじさん達（英語ではstatic ojisansという感じ）に向けて書いたのですが、思いがけず、元祖staticおじさん（The static ojisanあるいはMister staticといった感じ)ご本人からのご意見をいただき、本当に嬉しく思います。 オブジェクト指向の再利用性と非オブジェクト指向の関数やサブルーチンとの違いを明確に示していないから いろいろ理屈を込めても無駄ではないでしょうか？ 誰かが作ったクラスを継承して再利用したところで、バグが少なくて、メンテナンス性がいいものができるでしょうか？ そんなものをあてにするより、天才が作ったクラスライブ
Javaエンジニア必携の「プログラミングGroovy」を献本していただきました - 達人プログラマーを目指して
昨日、ポストを確認したところ、執筆陣の皆さんより、献本として送っていただきましたプログラミングGroovyが届いていました。 プログラミングGROOVY 作者: 関谷和愛,上原潤二,須江信洋,中野靖治出版社/メーカー: 技術評論社発売日: 2011/07/06メディア: 単行本（ソフトカバー）購入: 6人 クリック: 392回この商品を含むブログ (155件) を見る私の人生で初の「献本」であったということもありますが、本当に出版を心待ちにしていた本であったので届いていたのをみつけたときは、（まったく季節外れな表現ですが）子供のころにサンタさんからプレゼントが届いていたのを見つけた時と同じような感動を覚えました。私は「Groovyおじさん」と呼ばれてもよい年齢なのですが、新しい技術書が届いた時のわくわく感というものは常にありますね。でも、出版から一足早く「献本」を受け取るというのは生まれて
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
ConQATを利用してソースコードの品質をチェックする - 達人プログラマーを目指して
ある程度プログラマーとして経験を積めば、ソースコードを読んだときに、そのソースコードの良し悪しというものは、嗅覚を使って直感的に嗅ぎ分けることができるものです。実際、そのように体の感覚を使ってこのコードは不吉だと感じるところは実際大いにあり、コードの臭い（code smell)として知られています。 コードの臭い - リファクタリングの必要性を示す兆候 これはファウラーの名著 リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見るでも紹介されており、こういった不吉な部分を適切に嗅ぎ分け
こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい
侵略的なフレームワーク - 達人プログラマーを目指して
SpringやSeasar2などの軽量なフレームワークが登場し、POJO、DI、AOPという考え方が今ではすっかり浸透してきているのかと思いきや、ぜんぜんそんなことはないみたいです。客先でも（主に社内での）実績最優先という考え方から、最近のOSSフレームワークには手を出さず、日本の大手SIer謹製のフレームワークを採用したり、自社フレームワークを採用したりするケースが意外に多いですね。そういう場合によくありがちなのが、プログラマーのスキルによらずに作れるようにするという目的から、無意味な規約を強制するケースです。 実際、今日ある国産ベンダーのフレームワークを採用したシステムの設計書に記載されているクラス一覧を見ていて無駄がいかに多いかということに驚いてしまいました。たとえば、ユーザー一覧を検索するという処理でSeamならエンティティクラス、画面、JPQLがあれば実装完了なのですが、そのフレ
普通のSI会社では評価されにくいのだけど、多くのシステムは研究熱心な技術者の小さな発見と工夫の積み重ねによって支えられているのでは？ - 達人プログラマーを目指して
昨晩遅く、id:backpaper0さんの以下のツイートが目にとまりました。 staticでない本物の内部クラスは暗黙で外側のインスタンス（エンクロージングインスタンス）のthisにアクセスできる仕様なので、newを使った普通のインスタンス化の方法では決して外部のインスタンスが存在しない状態でnewできないようになっています。つまり、内部クラスのインスタンス化にはエンクロージングインスタンスの存在が前提となるというのが私が長年Javaのコードを書いてきた中での常識でした。 実際、エンクロージングインスタンスの外側で内部クラスのインスタンスを作成する場合、以下のようにnew演算子の前にエンクロージングインスタンスを書かなくてなならない仕様となっているため、これがnullでは決して内部クラスが生成できないように構文上工夫されています。 public class Outer { private
普通の業務系Java PGでなくても一度はハマる？JavaScriptのthisの奇妙な振る舞い - 達人プログラマーを目指して
先日書いた普通の業務系PGには意外と知られていないJavaとJavaScriptの相違点10選 - 達人プログラマーを目指してでは、これからJavaScriptを本格的に勉強する層のプログラマーの人を対象に、JavaとJavaScriptの違いを理解する上で重要な１０個のポイントについて説明しました。いただいたコメントの中には、JavaScriptとJavaは当然まったく別の言語で、比較すること自体問題であるという趣旨のご指摘もいただきました。確かにその通りなのですが、実際、業務で本格的なプログラムの開発はJavaでしかしたことがないという開発者は結構自分のまわりにはたくさんいますし、時代の流れから言って、これから初めて本格的にJavaScriptを書くという人も今後たくさん出てくるのではないかと思います。そういう人にとっては、やはり、違いを意識するところから入っていくというのは学習のアプ
普通の業務系PGには意外と知られていないJavaとJavaScriptの相違点10選 - 達人プログラマーを目指して
以前はJava EEの普通のWebアプリケーションで、JavaScriptはあくまでも利便性のために補助的に使うものという認識がありましたが、さすがに最近では普通の業務系のSI案件でもテーブル表示や入力補助などで高度なAjaxライブラリーの使用が当たり前のように求められるようになりつつあります。サーバーサイドのJavaScript技術といったものもありますが、そういった新しい技術を使わないまでも、ごく普通にある程度大きなJavaScriptの作成が必要になってきているということです。 もちろん、JavaとJavaScriptはその名前にかかわらず、本来全く別の言語です。しかし、意図的に似た構文でロジックが書ける*1ため、兄弟の言語として認識している人も意外に多いのではないかと思います。しかし、使用できるライブラリーに違いがあるという点が一見してわかる最も大きな違いですが、基本的な言語の文法
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指して
Twitterでフォローさせていただいている@chok12jaさんのつぶやき がきっかけで、外国人の視点から日本のSI業界の問題について分析した面白い英文の記事を見つけました。 How the Japanese IT Industry Destroys Talent | Japan -- Business People Technology | www.japaninc.com [ThinkIT] 第2回：なぜ日本のIT業界ではスーパーSEを育てられないのか (1/4)（New 日本語訳が見つかりました。） 2007年に書かれた記事なのでもう４年も前に書かれたものですが、日頃から私が感じてきた業界の問題点について鋭く批評を加えており、非常に共感する内容が書かれていました。本ブログの主な読者の方々にとっても興味深い内容だと思いますので、ここで簡単に内容について紹介させていただきたいと思います
クラウドが昔ながらのSIerの仕事を奪うようになってきてはいるけれど - 達人プログラマーを目指して
Salesforceといえば、ちょうど最近行われたSalesforce Developers | Developer Eventsというイベントに参加された方もSI業界では多くいらっしゃるのではないかと思います。私はそのイベントには参加していませんでしたが、先日会社でSalesforceのSE*1の方からお話を伺う機会がありました。 Salesforceの提供するForce.comのようなパブリッククラウド上での開発を最初からなんとなく敬遠してしまう組織もあるかもしれませんが、多くの業務システム開発に対しては開発生産性がJavaや.NETの5倍という宣伝文句は決して大げさでないケースが多いと考えます。実際この5倍という数字は日本における実績というよりワールドワイドでの実績に基づくものと思われますが、海外ではそもそもSalesforceが対象とするような領域ではもともと生産性の高いフレームワ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
