すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して
このたび9月末日をもってオージス総研を退職し、10月よりアマゾンジャパン株式会社に入社しました。今後はSoftware Development Engineerとして、日本をはじめ世界各国のAmazonのモバイルWebアプリケーションの開発を担当することになる予定です。 およそ7年間にわたり、前職のオージス総研ではソフトウェアアーキテクトとして、SOAやEAといった全社的なシステムのアーキテクチャから、上流のモデリング、Java EEを使ったアプリケーションの開発など、技術者として様々な経験を積ませていただきました。私自身はこのブログでも何度も取り上げてきたように、モデリングやオブジェクト指向といった技術を用いて、実際の基幹業務システムの設計などに活用することで、高品質で保守性の高いシステムの構築に貢献したいという思いがありました。そのようなシステムを構築、維持するためには高品質なアーキテ
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月に行わ
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
ConQATを利用してソースコードの品質をチェックする - 達人プログラマーを目指して
ある程度プログラマーとして経験を積めば、ソースコードを読んだときに、そのソースコードの良し悪しというものは、嗅覚を使って直感的に嗅ぎ分けることができるものです。実際、そのように体の感覚を使ってこのコードは不吉だと感じるところは実際大いにあり、コードの臭い（code smell)として知られています。 コードの臭い - リファクタリングの必要性を示す兆候 これはファウラーの名著 リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見るでも紹介されており、こういった不吉な部分を適切に嗅ぎ分け
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
