中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場
「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ
「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan
あるサイトで連載の話を進めていて、そのコンテンツを考えていた。目次を書き出しているときにふと「プログラマ35歳定年説」なるものを思い出した。 プログラマ35歳定年説とは、「プログラマは年齢を重ねて行って、35歳ぐらいになったらSEなりマネジメントなり、次に行かないとオマンマ食べられないよ」というものだ。 「そういえば、自分もそう言われてきたっけ・・・。若いころは「俺たちがシステム作ってんだ！実力があれば絶対に大丈夫。ふざけんな！」と思っていたよなぁ。」 ふと考えれば私は今36歳。その説によれば定年を迎えている年齢だ（笑）。年金はもらえないが・・・。 プログラマ、SE、マネジメント、経営の一通りを経験してきて、その説の私なりの考えを書いてみたくなった。 35歳プログラマ定年説は本当か？・・・私にとって かつては技術力に自信があったし、楽しいプログラマ人生を送ってきた。そんな私だが、今もし誰
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
良好なレスポンスを実現するアーキテクチャ ― ＠IT
「ITアーキテクチャ構築の勘所」では、アーキテクチャ設計手順を示し、それぞれのステップにおける勘所を示した。その続編となる本連載は、ビジネス要求に応えるために必要な、「大量トランザクション処理」「24時間365日稼働」「使いやすい」といったシステムの特性に着目し、これを実現するためのITアーキテクチャ構築の勘所を述べていきたい。第1回の今回は「良好なレスポンス」を実現するアーキテクチャについて勘所を示す。 ITアーキテクチャ設計は、ビジネス要求に適切に応えるために、ビジネス要求に即したシステム特性を実現していく作業である。例えば、オンライン証券では多数の照会や売買の要求に対して迅速に応答する必要があり、このためにはクラスタリングやキャッシングをうまく適用したアーキテクチャ設計を行うとよい。 前回の連載では、アーキテクチャ設計手順を示し、それぞれのステップにおける勘所を示した。この続編となる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
