メイン

システム開発 アーカイブ

2005年05月02日

ハッピープログラミングのススメ

結局のところ、技術というよりは、コミュニケーション能力が問われるわけです。

仕事とは?

* 技術を習得し、その技術を利用して、お客様に便利なサービスを提供していく。
   これがわれわれの仕事です。
* 技術を追求していくことも勿論大切なのですが、技術だけで仕事ができるわけではありません。
* 何のための開発や制作であるかを忘れてはいけません。
* お客様は、人間であることを忘れてはいけません。
* お客様が困っていることは何でしょう。と自分に問いかけてみよう。
* お客様が怒っていることは何でしょう。と自分に問いかけてみよう。
* お客様が喜ぶことは何でしょう。と自分に問いかけてみよう。
* お客様の声に耳を傾け、じっくりと考えていきましょう。
* 自分がやれる、やれない。というレベルで考えるのではなく、
会社として、どのようにすればできるのか、まずは考えていきましょう。

iPLUSONEのハッピープログラミングのススメ

* プログラミングは知的でわくわくする楽しいことである。
* しかし、そこへたどり着くにはなかなか難しい時代である。
o コンピュータへの要求が多様化しているということが一番大きい。
o 特に初心者は、何からやっていいのか。
o そうはいっても、やれる人はどんどん進んで、やれない人は甘えているだけというのが大きい
o できる人、できない人という括りは、結局は、やる人、やらない人というだけのことだ。
o とはいっても、精神論だけでは解決策が見出せないので
o ソフトウエア開発を事業とするものとしては、なんらかの方針を示す必要がある
o 何でもかんでも、個人任せな会社にはしたくない。
* 初心者が、エンジニアになるために、どういったアプローチがよいか。
* その中で、何が問題になるのだろうか。

* 理論ばかり立派でアウトプットがでないのでは困る。
* 理論と実践のバランスが大切である。
* とにかく実践せよ。実践すると何らかの結果が出る。
* ネットでだれかやったことを鵜呑みにしてはいけない。実際に試して、どうなるか。確認すること。
* 「・・らしい」では、話が先に進まない。
* 「・・だった」。だから、次にどうする。という最終判断までもとう。

* 最初は誰もわからない
* 最初は、知らないことばかりだ。
* 何かを習得しようとすれば新しい言葉の嵐で、それらを調べていくうちに、何を覚えようとしていたのかがわからなくなる。こんな経験はないだろうか?
* 全部を一気に習得することは難しい
* 個々の小さく噛み砕いて、理解できる範囲を狭めていくことが重要
* とにかく、コツコツと蓄積していくしかない。
* 最初からあれこれ聞いていては、煙たがられるだろう。 などと、気を使うことはない。
* ビギナーの特権である。最初から聞きまくれ。
* ただし、すべてを聞くのではなく、聞くポイントを考えてみよう。
* 自分が試せば済むことは、自分でやること。
* 何を聞いたらいいのかわからない。と困っているなら、それを相談すればよい。

2006年08月30日

オブジェクト指向言語におけるクラスと継承 EC-CUBEのクラス構成


いわゆるオブジェクト指向言語とよばれるクラス機能をもったプログラミング言語は、
単にクラスを定義するだけではなく、
生産効率を考えた、拡張性が準備されている。

例えば、継承という機能のおかげで、
将来、どんな拡張が行われるかがまだ未定だが、
拡張を行う場合には、このクラスを拡張してね。
というような構成にしておくことで
既存機能には一切影響を与えずに、拡張することも可能になる。

これは、EC-CUBEについてもいえることである。

クラスのすべてに対して、継承したExクラスが用意されている。
実体(インスタンス)を生成しているのは、このExクラスなわけだが
このExクラスを拡張することで、機能追加ができるようになっている。

ec_class.gif

例えば、商品詳細のページで表示している商品詳細のクラスは、LC_page_detailクラス
このクラスを親クラスとして、LC_page_detail_Exクラスを派生していて、
detail.phpでは、このLC_page_detail_Exクラスのインスタンスを生成している。

2007年12月23日

UNIXの哲学

UNIX創始者の一人でパイプ発案者でもある
Doug McIlroyによるUNIX哲学

1.1つのプログラムが、1つの役割に専念する。

2.複数のプログラムは協調して働く。

3.プログラムは汎用的インターフェイスである標準入出力を扱う。

X Window System設計チームの一員だったMike GancarzによるUNIX哲学

1. Small is beautiful.
(小さいものは美しい)

処理単位が小さいことは、理解しやすいだけでなく、バグを出しにくくする。
あれもこれも詰め込んだ関数などは便利に再利用できることが少ない。
小さいものの集まりであれば、融通も利くが、
大きいものは特定の場合にだけ便利で、それ以外に利用価値がない。

2. Make each program do one thing well.
(1つのプログラムは単純な1つの機能を行う)

関数やプログラムが何をするのか、簡潔に説明できるようにすること。
ビギナーほど、あれやこれや詰め込みたくなるが、本当にそこでやるべきなのか考えてみよう。

3. Build a prototype as soon as possible.
(なるべく早くプロトタイプを作成せよ)

とにかく動くレベルで検証しておくこと。口よりも先に手を動かせ。

4. Choose portability over efficiency.
(効率よりも移植性を重視せよ)

特定の環境でしか動かなくするようなことを避ける。
UNIX, Linux, Windowsそれぞれで同一のソースが動くことが望ましい。

5. Store data in flat text files.
(データは単純なテキストファイルに格納せよ)

アプリ依存のデータは作らないほうがよい。
プレーンなテキストであれば、多くのツールをつかって自由自在に加工が可能である。

6. Use software leverage to your advantage.
(ソフトウエアを自らを助く手段として利用せよ)

自分を助けるためのソフトウエアをどんどん利用すべきである。
プログラムが書ける人の中には、便利なプログラムをうまく利用していない人が多い。
特定な環境に依存する技術者になるな。
WindowsだろうがLinuxだろうがUNIXだろうが、どこの環境でも便利なものはどんどんつかえ。

7. Use shell scripts to increase leverage and portability.
(シェルスクリプトを利用し自らを助け、移植性を高めよ)

シェルsh,bash,sed,awk,perlなど適材適所で利用せよ。
組み合わせて、とにかく書いて動かしてみよう。

8. Avoid captive user interfaces.
(ユーザ・インターフェースを1つに強制するな)

固定観念を捨てよ。

9. Make every program a filter.
(全てのプログラムはフィルタとして振る舞え)

入力がファイルである必要はない。標準入力でよい。
出力がファイルである必要はない。標準出力でよい。
こうしておけば、入出力を切り替えることができる。
パイプとリダイレクトで、つなげていこう。

2008年01月27日

ソフトウエア開発の歴史

コンピュータの歴史はまだまだ浅い。しかもビジネス向けにソフトウエアを開発するように
なってからまだ・・・

モークリー、エッカートのENIACが、1946年だから、62年前。
これが真空管 18,800本 リレー 1,500個で弾道計算用につかわれ、
10進演算方式で乗算2.8msecだそうだ。

この2年後に、ノイマン型コンピュータEDVACだから丁度60年前。
商用としての初のプログラム内蔵方式は、UNIVAC-1 これも同じ年。

IBMがFORTRANをつくったのが、この4年後の1956年。
言語があれこれ沢山出てはいるが、
昔は限られた資源を利用して、目的が明確であった。

しかい、コンピュータの性能があがってくると、
より人間の高い要求にこたえられるようになってきた。

長らくは、手続き型プログラミングが主流であり
理論としてのオブジェクト指向はあったがビジネスで使われだしてきたのは
この10年くらいまえからだ。

今の時代は、言語に左右されるのではなく、
まずは理論をきちんとつかんで、さまざまな言語を適材適所で使えるというのが理想だ。

データ構造とアルゴリズムが理解できれば、
それをもとに構造化したプログラムをかいてみればよい。

オブジェクト指向になれてみたければ、理論を学び、じっさいクラスを書いてみればよい。

About システム開発

ブログ「iPLUSONE Photo Blog」のカテゴリ「システム開発」に投稿されたすべてのエントリーのアーカイブのページです。過去のものから新しいものへ順番に並んでいます。

前のカテゴリはオープンソースです。

次のカテゴリはフォトです。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.34