優れたプログラムとは (2)：気難しいプログラマ：エンジニアライフ
前回の続きです。 ○モジュール設計 優れたプログラムは、極めて慎重にモジュール設計がなされています。機能ごとに分けられたコンポーネントや適切に階層化されたレイヤーは、なるべく互いに関係性を持たないように区切られています。 例えば、上位に位置する層はOSやRDBMSに直接アクセスすることはありませんし、逆に下位層がユーザーインターフェイスの変更に影響を受けることはありません。重要なのは、そのモジュールをいかに外部を意識しないように作るか、ということです。 参照する側の事情に左右されない独立性・汎用性が、設計のカギとなることでしょう。オブジェクト指向言語においては、これら論理構造上の区分けは、クラスの階層やJavaのpackageなどでより明示化された実装が可能となります。 ○疎結合性を阻害するスコープの問題 プログラム品質を決定づける大きな要因の一つがスコープです。スコープが広がれば広がるほ
開発環境と本番環境の違いを埋めるHeroku、Engine Yardの新機能：Rails Hub情報局：エンジニアライフ
「でも、ステージング環境ではちゃんと動いています！」 こう言われてブチ切れた経験があります。業務アプリのバギーな動作を社内のエンジニアに指摘したところ、テスト用の環境では動いているというのです。「いや、ぼくら本番環境のアプリを使っていて現に困っているので、それを直してほしいだけなんですけど」というと、「でも、ちゃんとステージング環境では動いています。お使いになっているのがChromeのようですが、Chromeでの動作検証はしていません（キリッ」というようなやり取りに絶望しました。原因はブラウザではなく、バージョンアップしたアプリ自体にあったのですが、ステージング環境では問題が発現しなかったんですね。 というように、開発環境、ステージング環境、プロダクション環境（本番環境）の3つは、大小いろいろな違いがあって、完全に一致させることは難しいものです。手元の環境で動いているアプリが、プロダクショ
『Javaルールブック』――可読性の高いコードを書くルールを直感的に把握する：晴読雨読＠エンジニアライフ：エンジニアライフ
Javaルールブック 読みやすく効率的なコードの原則 大谷晋平、米林正明、片山暁雄、横田健彦（著） 電通国際情報サービス （監修） 技術評論社 2011年2月 ISBN-10: 4774145475 ISBN-13: 978-4774145471 2709円（税込） ■コーディングのルールは必要だ。だが、縛りすぎてもならぬ チームで開発を行うと、必ず「ルール」が必要になる。よくある規約としては、開発手法を定めた「開発規約」や、どのようなテストをどれだけ行うかを定めた「テスト規約」などがある。 コードを書く際、どのプログラミング言語にも最低限のルールは存在する。しかし、すべてのエンジニアがそれを熟知しているとは限らない。ルールを知らないエンジニアが書いたコードは、本人にしか理解できないものになる。そのようなコードを1つ許せば、いずれシステム全体が混沌状態に陥り、システムの品質を落としてしまう
新人プログラマが知っておくべき3つのこと：不思議そうで不思議でないちょっと不思議な現場の話：エンジニアライフ
こんにちわ。草食系妙齢プログラマ 野口おおすけです。わたしの住んでいる関東ではさまざまなところで節電対策ということで空調が止まっていたり、設定温度が高めになっています。基本的にスーツを着て出社するためこれからの時期が大変になりそうなので、スーパークールビズの流行に乗ってポロシャツとか軽装で出社したいものです。 さて、6月に入って、4月入社の新入社員が現場にやってくる時期になりました。研修で習ったことと現場との違いに戸惑うことも多いかと思います。今回は、現場に配属された新人が、プログラマとして仕事を始めるにあたって知っておきたい3つのことをご紹介したいと思います。わたしがJavaプログラマなのでJavaのことがメインになりますが、他の言語でも同じようなものです。 ■IDEもエディタもあるんだよ JavaでIDEといえばEclipseやNetBeansなどが代表的なものとしてあげられます。これ
ソースコードの質：気難しいプログラマ：エンジニアライフ
近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読
分かりやすいコード：アジアのソフトウェア開発現場にて：エンジニアライフ
シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 私は、恐ろしく物覚えが悪い。例えば、人の名前を覚えるのに苦労する。また、いったん覚えた人の名前も、数カ月会わないと忘れてしまっていることが多い。場所の名前なども同じだ。電話番号も、自分の家の電話番号さえいまだに覚えられない。現在、私の頭の中にある電話番号は、私が生まれた家、つまり今は両親が住んでいる家の電話番号だけだ。 映画『博士の愛した数式』で、主人公の数学博士（映画では寺尾聰）は、記憶が80分しか持たないという設定だが、私も、それに近いかもと思ったりする。もしかしたら若年性アルツハイマーかと思うことさえある。しかし、この物覚えの悪さは若いころからなので、多分そうではないだろう。単に私の頭が、生まれつきそういう作りなのだと
オブジェクト指向開発を理解した開発者に、設計書は不要：アジアのソフトウェア開発現場にて：エンジニアライフ
シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基本設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
ググるな危険：プログラマで、生きている：エンジニアライフ
だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
不思議そうで不思議でないちょっと不思議な現場の話：エンジニアライフ