|
漁師プログラマ
山崎敏 YAMAZAKI Satoshi
vol.04 |
|
|
●●ある日 |
|
|
突然，遅れているプロジェクトを手伝うことになったのです．さらに納期も遅らせることはできないというプロジェクトを．すでに顧客はカンカンに怒っていて，その怒りは末端の作業者であるわれわれ漁師プログラマ（注1）に向けられました．納期まで残り2週間なのに，テストはおろか，コーディングさえも完成していない，さらには仕様書がボロボロという事実が発覚すれば，顧客でなくても怒るのは当然のことでしょう．このあと，仕様をまとめているプロジェクトの管理者が過労で倒れてしまうのですが，絵に描いたようにキレイな「デスマーチ」だったりします．
元はといえばプロジェクトの管理者の怠慢が招いた問題なのに，その問題が最終的には末端で作業する我々にそのまま落ちてくるのです．カンカンに怒っている顧客は「遅れているのはわかったから，誠意を見せろ」と言ってきました．最初「誠意」の意味がわからなかったのですが，早い話が「朝早くから夜遅くまで死ぬ気で働け！」と言っているのです．
しかし，この作業はソフトウェア開発なのです．単純作業の繰り返しとは話が違います．朝早くから夜遅くまで作業をしても効率は上がらないし，進捗も悪くなる．結果的には「がんばりすぎる＝倒れる」ことになりかねないのです．
筆者は「作業効率を上げるには禁止項目を増やせば良いと思っている管理者がいたのなら，その管理者を捨てることが一番効率的である」と思ったり「効率というのは，作業者が自ら考えて編み出していく技なのだから，管理者はその技が発見しやすいような自由な環境を与えるべき」と思ったりしながら，今日も「ソフトウェアの作り方を知らない奴が多すぎる」と嘆きつつ仕事に向かうのでした．
注1）理論ではなく実践（動いてなんぼ）を優先しているプログラマのこと．筆者の造語．
|
|
|
●●会社と個人 |
|
|
筆者は，学生のときからプログラミングを楽しんでいました．個人の趣味と会社の仕事の両方でソフトウェア開発の経験をしたわけです．会社には個人の開発にはないもの（仕様書，日程，納期，顧客，営業，上司，部下，などなど）が多くあります．
中でも，大きな違いは開発規模だと思います．筆者の経験では個人で書くプログラムの規模は（C言語で）1万行が1つの到達点であるように思えます．
時間をかければそれ以上の規模も書くことは可能とは思いますが，1万行を超えたあたりで全体のしくみが把握できなくなり，開発効率が極端に落ちていくと思うのです．
しかし，会社では10万行を超えるシステム開発はざらにあります．となると当然1人ではとても開発できないわけで，複数人でチームを作ってこの戦いに挑んでいくわけです．この点が個人と会社の一番の違いだと思うのです．
規模が大きくなれば人を増やす．これは単純な話なのですが，今回はこの大規模と小規模の違いについて取り上げます．その理由は「それほど単純な話ではない」ということを何度も身をもって体感したからです．
|
|
|
●●人月の落とし穴 |
|
|
●ピラミッドを作る
ここで簡単な算数の問題を出題します．
無数のレンガがあったとします．あなたがこのレンガを積み上げて高さ1メートルのピラミッドを作るのに1日かかったとします．
・問題1
あなた1人で同じ高さ1メートルのピラミッドを10個作るのに，何日かかるでしょうか？
・問題2
あなたとまったく同じ能力の人が10人いたと仮定して，その10人で同じ高さ1メートルのピラミッドを10個作るのに何日かかるでしょうか？
・問題3
あなたとまったく同じ能力の人が10人いたと仮定して，その10人で高さ10メートルのピラミッドを1個作るのに何日かかるでしょうか？ |
この算数の問題には規模と複雑さの関係が隠されていると思います．現実問題では単純に規模を人数で割ってはいけないのです．小規模なコード量であれば1人でも可能ですし，それが2人になったところで大きな問題は起こりません．ところが3人以上になると，意思疎通や方向性の統一などのコミュニケーションが問題になってきます．人数が多くなるほどこの問題は大きくなるのです．
●人月に注意を
筆者は開発規模に単純に「人月」という概念を適用することはできないと思っています．『人月の神話―狼人間を撃つ銀の弾はない』（フレデリック・P・ブルックス，Jr.著／滝沢徹ほか訳／アジソン・ウェスレイ・パブリッシャーズ・ジャパン／ISBN：4795296758）という本にも「『人』と『月』は交換可能ではない」ということが書かれています．
「1000人月の仕事はたとえ1000人用意できても1ヵ月で終わらせることはできない」ということが書かれています．筆者の思いと同じです（注2）．
さて，このピラミッドを作る問題ですが，問題3の場合，次の3点が重要な要素になると思います．
・高さ10メートルは単純に高さ1メートルの10倍の作業量ではない
・複雑さや難易度も同じではない
・1つのモノを複数人で作るにはコミュニケーションが必要
多くのプロジェクト管理者はこの計算を間違えます．ここでは正解が出せるかどうかが問題ではなくて，安易に「1日」と答えてしまうようなことは絶対に避けなくてはならないということです．
注2）この本ですが，なんと20年も昔から変わらず売られているそうです．凄いです．
●規模と複雑度の関係
規模が大きくなると複雑さが大きくなります．犬小屋を作るのと家を建てるのでは，規模以上に複雑さや必要となる知識も大きく違ってきます．この違いを安易に考えるとたいへんなことになります．
規模と複雑度の関係を図1に示します．規模が大きくなると複雑度が急激に上がりはじめます．『人月の神話』を読むと，ソフトウェア開発においては，昔から規模の問題に悩まされ続けていて，現在になってもその具体的な解決策は見つかっていないのだと思い知らされます．
●依存度を下げる
構造化設計で言われていたことですが，コード間の依存度（結合度）を下げようという考え方があります．これはオブジェクト指向全盛である現在でもあてはまる考え方だと思います．オブジェクト指向では「カプセル化」と呼んでいますが，コード間の依存度を下げる目的は同じだと思います．規模が大きくなると，コード間の依存度が増え，絡み合い，複雑度が増します．よく乱雑で複雑なコードのことを「スパゲッティなコード」と呼んでいましたが（最近はあまり言わなくなりました）まさに複雑に絡み合っている状態を的確に表現した言葉だと思います．
このような複雑さには何のメリットもないので避けるべきです．その1つの方法としてコードを短く切るというのがあります．短くしてお互いに絡み合わないようにしようという方法です．スパゲッティの麺を短く半分に切ればたしかに絡みにくくはなります．絡まないというのはコード同士の依存度を下げることに繋がるので良いことなのですが，依存度を無視して「単純に短いコードが良い」と邁進してしまう人もいるようです．しかし，コードが短いということは必要な情報まで削ってしまうこともあるので，本来の目的である「依存度を下げる」ことを見失わないように気をつけるべきでしょう．
●2つの依存度
コード間の依存度には大きく2種類あると思います．それはプロシージャの依存度と，データの依存度です．プロシージャの依存度とは，あるコードがほかのコードの固まりを「関数として呼び出す依存度」と言えます．この関数の数が多くなり絡み合っていると複雑であるということになります．
もう1つのデータの依存度ですが，こちらはあるコードがあるデータを「参照／更新している依存度」になります．こちらも数が多くなったり参照する距離が長くなり絡み合っていると，複雑であると言えるでしょう．どちらの場合でも，依存する数や距離を減らすことで，依存度を減らせると思います．
多くの人は「プロシージャの依存度」については気をつけて設計しているようですが，筆者は「データの依存度」についても，もっと気を配るべきであると思っています．
ここで，依存度と複雑さを表す図2を見ていただきたいのですが，はコードの固まり，線は依存関係を表しています．の数や線の数はAもBも同じです．それでも，皆さんはAのほうが複雑だと感じるでしょう．複雑度というのは単純には数値化できないことを理解していただけるでしょうか．しかし，数値化できなくても，複雑かどうかの判断は，誰でもできることだと思います．
|
|
|
●●デスマーチを防ぐ |
|
|
●デスマーチとは
大規模なコードを書くときによく起こるのがいわゆる「デスマーチ」です．参考までに筆者のデスマーチの定義はこうです．まず残業，休日出勤，徹夜が増えます．そして，チームの誰かが働きすぎによる過労で倒れたならそれはデスマーチです．原因として無茶な日程管理や，規模の見積もりの甘さ，管理者の怠慢などなど，いろいろ考えられますが，全体としては「デスマーチを避けようとしない体質」があると思います．そういう開発スタイルが染みついてしまっているのでしょう．どんな問題に対してもその場しのぎで取り繕っていると，その歪みがたまり，結局は自分を苦しめることなるのです．
しかし，それが理解できずに「自分はがんばっているのに，なんでこんなに苦しいのだろう？きっと上司が悪いんだ，営業が悪いんだ，顧客が悪いんだ，この社会そのものが悪いんだ」などと違う方向に考えてしまう人もいるようです．問題の根本はその表面ではなく内部にあり，その根本を直す必要があると思うのです．
●コミュニケーションを
問題の根本とは，ピラミッドの問題でも出てきましたが「コミュニケーション」だと思います．大規模になり，複数人で1つのモノを開発するには，人のコミュニケーションが重要な要素になります．ここが個人で開発する小規模なコードとの大きな違いなのです．
たとえば「できないことはできない」と言い，なぜできないのかという情報を，顧客にまでしっかりと伝えるというか，伝わるような雰囲気作りをするスタンスが大事であるということです．無茶な仕様や納期の要求はデスマーチを呼び，そのプロジェクトに関わる全員が困ることは必至です．
とくに，バグなどの品質の低下で一番困るのは顧客であることを認識してもらわなければなりません．不幸への一歩はそこから始まるのです．コミュニケーションはそれを防ぐための最初の一歩だと思います．「上司がバカでどうにもならん」と言う前に，その上司と情報の共有（コミュニケーション）をする努力（ぶっちゃけた話）をしてみましょう．
解決の糸口がつかめるかもしれません．
ウォーターフォールモデルでは，この問題が露呈することがよくあります．ウォーターフォールモデルでは，すべての情報が正しく伝達することを前提にモデル化されているようです．しかし，実際の現場では，最初にすべての情報を揃えることは不可能ですし，途中でふくらんだ追加情報を次の工程に正確にしかも漏れなく伝えなければならないことも，事実上不可能であったりします．情報が上から下への一方通行では伝わる情報も伝わりません．
情報のやりとり（コミュニケーション）が大事なのです．そういった意味ではウォーターフォールモデルよりもスパイラルモデル（図3）のほうがコミュニケーションに関しては良いようです．さらに筆者の意見を言わせてもらえば，XP（エクストリームプログラミング）はこのコミュニケーションを重視した開発モデルのように思えます．
●テストを重視する
デスマーチに陥る原因として，もう1つ考えられます．それは見積もりです．見積もりが甘いのです．
そもそもコード量を見積もりの基準にしているところがヤバイと思うのです．コードが書けてもそのプログラムが動くわけではありません．ちゃんとテストする必要があります．テストが終わってはじめて完成したと言えるわけです．
要するに，見積もりにはコードではなくテスト数を使うべきと思うのです．何件のテスト数があり，何件のテストが通ったから，何％進捗しているという具合に計算するのです．テストというと「コードを書いたおまけの作業としてしかたなくやっている」という風潮があるように思えます．そのように考えるのではなく，テストのコードを書いて，テストを実行するのが我々プログラマの主な仕事であると考えるべきです．
今までの傾向として，ソフトウェア開発の作業配分の中ではテストの比率が低かったと思います．今後はこのテストの比率を一番に持ってくるべきだと思います（図4）．
テストの比重を全体の半分くらいに高め，さらには，実装と比べて設計や要求定義の比率も上げるべきでしょう．この段階から顧客とコミュニケーションを取り，何をテストすべきか？最終時のテスト方針やテスト項目を決めておくべきだと思います．
ここを決めればあとはそのテスト項目を達成すべく進んでいくことができると思うのです．コミュニケーションを重視しろというのは，仕様を明確にすることでもあるのですが，仕様が決まることは「テストの仕方を明確にしろ」と言っているのと同じだと思います．
こうすれば，プログラマの主な仕事は実装からテストに移ることになるでしょう．いや，本来プログラマとは動くものを作り上げるのが仕事なのですから，テストをしないプログラマはプログラマとは言えないと思うのです．テスト作業といっても，退屈な紙を何枚も書いて，その紙のとおりにデータを入力して結果を確認するといった人海戦術のような作業ではなく，テストコードを書くべきです．
簡単に言えば「テスト用のスタブを書く」ことになります．とにかく紙でテストするよりも何倍も効率が良く正確にテストできるのでお勧めです．プログラマなら「紙に書く」より「コードを書く」ほうが何倍も楽ですしね．
|
|
|
●●現場百遍 |
|
|
●ソフトウェアは現場で使う
ある日本の映画に
「事件は会議室で起きているんじゃない！現場で起きているんだ！」
という科白（セリフ）があります．これはソフトウェアの開発でも言えることだと思うのです．筆者にはできることなら，快適な自分の机ですべての開発作業を済ませたいという想いはありました．しかし，その想いへの挑戦は，実際にはそれは不可能であることを証明してしまうという皮肉な結果に終わったのです．その映画の科白を借りると，
「ソフトウェアは会議室で使うのではない！現場で使うんだ！」
となるでしょうか．
とにかく，開発者や開発にかかわる人は，現場に集まって顔を突き合わせていないとダメです．電話による言葉や，メールによる文章では，伝わらないモノが多すぎるのです．現場で顔を突き合わせていれば数秒で済む作業も，メールなどでは数日経っても解決しないということが頻繁に起こるのです．問題を解決するにはとにかく現場に行かなくてはダメです．現場に行って問題を解決する．刑事ドラマではありませんが，どうやらこれがキホンのようです．
やはり，情報の伝達速度は重要なのです．コミュニケーションです．方法論とか，理論とか，戦術がどうのとか，道具がどうのとかいう以前から戦いは始まっているのです．「情報戦」と言っても良いでしょう．より広い視野を持って，より多くの情報を集め，正しく分析できれば，問題のレベルを下げることができるのです．
●実環境を揃える
筆者は職業プログラマのころ，最終的な顧客の環境のことを「実環境」と呼んでいました．この実環境をいかに手に入れるか？動作確認を実環境で行えるのか？実環境でコードの修正はできるのか？などなど，といった項目が開発の速度，いや開発そのものがうまくいくのかどうか？を決める大事なポイントとなると思います．漁師プログラマであればコードの書き方がどうとか，仕様書の書き方がどうとかにこだわるよりも，この実環境の入手にこだわるべきです．その実環境をいかに素早く手に入れられるかで，プログラマの腕が判断されると言っても良いでしょう．
筆者はよく「理論と実践は違う」ということを体感するのです．「理論的にはこれで動くはず」とどんなに強く思っても「実際に動かしてみないとわからない」という経験を何度もしています．とにかく環境の些細な違いによって何が起こるのかは人の想像をはるかに超えます．事実は小説より奇なり，ということでしょうか．
「環境を揃えるのはマネージャの仕事だろ」と言いたいのはわかります．でも，そのマネージャに催促するのはプログラマの仕事なんです．「言わなくてもわかるだろ」という言葉は間違っています．言わなければ伝わりません．
どんな環境がいつまでに必要なのか，必要なことはハッキリ言ってください．「環境が揃わなかったのでできませんでした」というのは「寝てしまったので宿題を忘れました」と言っている小学生と大差ないと思います．ここでも重要なのはコミュニケーションということなのです．
|
|
|
●●オブジェクト指向は難しい？ |
|
|
●何のためのオブジェクト指向？
「オブジェクト指向プログラミングは難しい」という話をよく耳にします．オブジェクト指向の概念が割合に曖昧であるし，覚えるべき項目も多く広範囲です．人によって解釈の違いや詳細な方法論の違いがあることも「難しい」という考え方に拍車をかけているように思えます．
難しいと思わせる1つの要因として，個人で開発する程度の数千行という小規模なコードでは「オブジェクト指向の効果を十分に発揮しきれない」ということもあると思います．このような小規模なケースでは，オブジェクトの数も少ないし，数が少ないということはオブジェクトを利用したときのメリットも少ないでしょう．
要するにオブジェクト指向のメリットを感じる前にプログラムが完成してしまうわけです．やはり，1万行を超える中規模から10万行を超える大規模と呼ばれるレベルになってやっと，オブジェクト指向のメリットも効いてくるとも思うのです．
●使ってみるしかない
それなのに「勉強すれば理解できる！勉強の仕方が悪い！」と言い切るのは少し強引かもしれません．やはり，理論と実践は違うわけですし，理論的には「大規模は小規模とは違う」と理解していても，実際の問題として何がどんなふうに違うのかというのは，実際に体験した人でも理解して感じとるのは難しいと思います．ましてや他人にそれを伝えるのはもっと難しいとも思うのです．
筆者が一番良いと思う学習方法は「虎穴に入らずんば虎子を得ず」ではないのですが，実際にやってみることではないかとも思います．
●失敗は悪？
ただ，今現在の資本主義の社会で，失敗を（とくに新人に対して）何度も経験させてくれる会社は珍しいでしょう．逆にそういった会社は危なくて顧客も離れていってしまう可能性も高くなります．そうなってくると，せいぜい1回の失敗でどれだけの経験を感じとり，修正／改善することができるかが勝負になるわけです．そこを意識している人と意識していない人の成長の差は開く一方だと思います．ある種の想像力の勝負だとも思うのです．
少し脱線するのですが，今の日本の社会はどうも「失敗＝悪」であるとか「失敗＝避けるべき行為／恥ずべき行為」とはじめから決めつけているところがあるように思います．1度や2度の失敗に対してはもっと寛容であっても良いとは思うのですが，日本の社会は失敗に対して厳しすぎます．
●失敗から学ぶ
具体的な話には枚挙にいとまがないので省略しますが，「人は失敗をするから前進できる」のであって，失敗しないから優秀というわけではありません．
その失敗しないという行為からはなにも学べないわけですから，実は「その場で停滞している」のと同じだと思うのです．
これから先，何がどうなるなんて誰にも予想はできません．どんなに優秀な人であっても生まれてきたのは初めてなのだし，すべての人が初めて経験することだらけなのに，まったく失敗せずに前進できる人なんているのでしょうか？たしかに失敗から何も学ばない人はまた同じ失敗をするでしょうが，何かを学べば前進できると思うのです．
『失敗学のすすめ』（畑村洋太郎著／講談社／ISBN：406210346X）という本に「失敗＝悪であるという考え方が逆に多くの失敗を生んでいる」と書かれています．要するに失敗を隠して揉み消してしまうことで，同じ過ちをする人が減らないということなのです．コミュニケーションや情報の伝達能力が低いことが原因であるということです．
この本では筆者も重視している「学習で得た知識と体感で得た知識は違う（理論と実践は違う）」とも書いています．ソフトウェア開発の話はありませんが，とくに分野に偏ることなく応用できる多くの事例が詳しく載っているので，プログラマにも（とくに管理者クラスの人に）お勧めできる本です．
|
|
|
●●問題を小さく分けて解決する |
|
|
●オブジェクト指向も考えは同じ
筆者は大規模コードを開発するのに，現在もっとも有効と思われる方法はこれしかないと思っています．大きな問題は小さく分割するのです．これができるかどうか？が最大のキモであると思います．3本の矢を一度に折ることはできなくても，1本ずつであれば簡単に折ることができるということです．
大規模なコードの開発にはオブジェクト指向などが有効であるという話はよく聞きます．オブジェクト指向というアプローチの中に「データ抽象化」という考え方があり，これはまさに「問題を小さく分割する作業」そのものと言えます．この小さく分割する作業が正しく行われることで，カプセル化や単体テストも容易になるわけです．そしてその分割を繰り返すことで，最終的には大規模なコードを容易に開発できるようになると思うのです．
●オブジェクト指向を道具として使う
筆者はオブジェクト指向は1つの道具に過ぎないと思っています．万能薬ではないということです．
大きな問題を解く場合にはそのメリットが活かされますが，小さな問題を解く場合にはとくに必須であるとは思っていません．道具は所詮道具なのです．
道具を揃えるだけで誰もが上手くなるわけではないし，道具の力によってどんな問題でも解決できるわけではないのです問題を小さく分けて解決するオブジェクト指向が難しいと思っている人も少なからずいると思いますが，おそらく「小さく分割する道具としてオブジェクト指向を使う」といった使い方が明確になっていないために「難しい」「理解できない」と感じてしまっているのではないでしょうか．たしかに，オブジェクト指向は今までになかった多くの概念が入っていますが，その中でも「データ抽象」や「カプセル化」のみを重視することで，そこから突破口を開き，メリットのある「使える道具」とすることは比較的に簡単なことと思っています．
まずは，問題を小さくするために「データ抽象」や「カプセル化」の概念を使い倒すと良いと思います．この「問題を小さくする」ことができるようになれば，どんなに大規模なコードであっても最終的には解決できることでしょう．大きな問題は小さく分割して解決するのです．十分に小さな問題になるまで，繰り返し小さく分割していくのです．
●各個撃破
筆者はミリタリーマニアではないのですが「各個撃破」という言葉は知っています．戦略の基本の概念だと思うのですが．要するに「数の多いほうが勝つのなら，そういう状況で戦え」ということでしょう．
ソフトウェアの開発においてもこの戦略は有効で，自分の戦力（能力）と相手の戦力（解決しようとしているシステムの問題の大きさ）の比率を考えることが重要なわけです．自分の力量より大きなシステムを一度に完成させるのは至難の業です．もしかしたら完成しないかもしれないと何度も思うことでしょう．
ここで各個撃破の戦略を利用します．敵（システムの問題）を小さく分割して，その小さな単位ごとに撃破（解決）していくわけです．問題が小さいのであれば余裕を持って解決することができます．戦力の差が2倍以上あれば容易に敵を制圧できることを考えると，システムの問題が自分の能力の半分以下の単位に分割できれば，余裕をもって解決できるわけです．それをシステム全体に対して繰り返し行っていくのです．
●いかに分割するか
ここで重要になるのが「いかにして分割するか」という問題です．スパゲティの麺を切るように，単純に分割すれば良いというモノではありません．分割の仕方にプログラマの力量が問われるのです．うまく分割できれば撃破することも容易です．逆に，分割に失敗すると問題は解決しません．
システムの分割は管理者（マネージャ）の仕事ではないか？という意見もあるでしょうが，現場を知っている人間のほうがより効率的な分割方法を見つけられると思うので，筆者はプログラマがするべき仕事であると思っています．
システムの開発の単位を分割できるということは，そのままテストの単位も分割できるということに繋がります．筆者は以前から「単体テスト」の重要性を説いていますが，単体テストを容易に進める意味でも，問題の単位を小さく分割することが重要であると言いたいわけです．
|
|
|
●●戦術と戦略 |
|
|
●戦略は戦術よりマクロな視点
簡単に書くと「この戦術は正しい（成果が上がる）ので，この戦術を選択した戦略はつねに正しい」という間違いをソフトウェアの開発ではよく犯してしまうということです．戦略とは戦術を選択可能なより高いレベルにあるマクロな視点だと思います．プログラマは日々，プログラムを完成させるという戦いに対して，どういう戦略でアプローチするのか悩んでいることでしょう．
この戦いには，いくつかの戦術の選択肢があると思います．どう攻めるのか？それとも攻めずに退くのか？どういう情報があるのか？支援してくれる味方はいるのか？どの道を通るのか？どの橋を渡るのか？人材は適当か？資材は十分か？などなど，多数の選択肢があります．
ソフトウェア開発にあてはめても，オブジェクト指向を使うのか？構造化設計までを使うのか？OSは何を選択するのか？言語は何を使うのか？誰を何処に配置するのか？などなど，こちらも同様にたくさんの選択肢があります．
●結論はすぐには出ない
たとえば，オブジェクト指向を戦術として選択して成果の出たシステムがあったとします．しかし，これと同じように「どのようなシステム開発においても，戦術としてオブジェクト指向を使えば成果が出る」と言い切るのは問題です．
それはやはり，そのときそのときの状況によって選択すべきであり，ときにはオブジェクト指向を使わないほうが成果が上がるようなケースもあるわけです．とくにチームの大半が初心者であり，オブジェクト指向を理解していない人が多い場合などは，無理にオブジェクト指向を通すとかえって効率が落ちるという話はよく聞きます．
Javaを選択すれば問題は必ず解決するわけではないし，C++を選択しても，C#を選択しても同じでしょう．問題なのは，その戦術を無条件に決定してしまったり，戦術の選択肢を増やそうとせずに選択自体ができなくなってしまうことなのです．戦術そのものが重要なのではなく，戦術の幅を広げることが重要であると思うのです．
また，戦術と戦略の違いをつねに意識することも大切だと思います．
|
|
|
●●最後に |
|
|
どうでしょう？皆さんには大規模なコードに対する考えかたというか，何か心構えのようなモノは残ったでしょうか？小規模なコードであればどんな方法を使っても力任せにできあがってしまうモノだと思います．プログラマの腕が問われるのはやはり大規模なコードを上手く仕上げたときだと筆者は思います．
次回は近ごろ話題の「XP（エクストリームプログラミング）」について書いてみたいと思います．お楽しみに．
|
|
大規模なコードと小規模なコード