パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

もうやらなくていい昔のコーディングテクニックあれこれ」記事へのコメント

  • てっきり (スコア:5, おもしろおかしい)

    「もうやらなくてもいい昔のコーディング規約」かと。

    • まずは詳細なフローチャートを作成し、上司のレビューをうけてからコーディングに入ること。
    • 変数の型が分かるように、変数名の先頭にはintならI、クラスならCのように決められた文字から始めること
    • 変更した部分はコメントアウトして残すこと。
    • メソッド名や変数名を変更する場合には変更許可申請書を提出し、上司の印鑑を貰うこと。

    ええ、もちろん大昔の話ですよ?

    • by Anonymous Coward

      自分が何時代に居るのか最近判らなくなってきています。

      新人が「フローチャートの書き方がよく分からなかったのでもう少し勉強して書けるようになりたいです」という
      日々の報告を上げてくるような組織のそばで働いています。やめさせた方がいいですか?いや、直接教育担当では
      ないので、口出ししないように言われているのですが。

      もちろん、オブジェクト指向だ何だといっても、中では順序だって処理する部分が絶対にあるわけで、その部分の
      処理の流れを図で示せる能力は必要だと思いますが....新人が悩んで自信を無くしかけるほどまで深く掘り下げる
      場所じゃないとおもうんですよね。

      • by komakisakio (33768) on 2009年05月04日 20時44分 (#1559201)
        「フローチャートが書けなくて死んだ人間はいない」と言っておく、とか。

        #フローチャート書いてる暇があったら、なんでもいいから動くもものを作った方が勉強になると思う。
        親コメント
        • by Anonymous Coward

          同意

          フローチャートなんて無くても困らない
          必要になるのは、やたらとフローチャートに拘る年代の方に見せる資料を作成する時かなー。

          • by Anonymous Coward

            最近の開発環境でフローチャート書けるだろうか。並列処理は書けないのよね、あれ。

        • by Anonymous Coward
          教育業界に微妙に身を置く人として。

          並列処理云々という前に、プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
          雛形(#include <stdio.h>~int main(...){...})だけとりあえず与えて、中に必要な流れを書いていくということをやらせると、
          どういう手順でやっていったらいいかまるで考えられないというのがごろごろと。

          だからとりあえず必要なことを列挙させ、線でつなげさせて必要なロジックを埋め込んでいってフロー化させる。
          「いらないだろう」という人たちは、半ば無意識にでも「どういう手順でやっていったらいいか」がつなげられる人たちなんです。
          並列云々へ行く前に、思考力を鍛えるためにはなんらかの形での目で見える形にするのが必要だと思います。

          でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
          • by cassandro (6035) on 2009年05月06日 20時12分 (#1560075)

            > プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。

             御意。居りますなあ。一年位でアプリからカーネルまで出来る様になって欲しいのですが、前途遼遠・・・

            > でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…

             NSチャート、PAD位しかチャートを知らないのですが、どれも一長一短がありますね。しかし本来はコードを書く前にチャート等で論理構造を検討する必要がある人達も時代の流れでチャート等を書かなくなり、その帰結として「なんじゃ?こりゃ?」なコードの大量生産、これが近年の傾向では無いでしょうか。もっとも、チャート等で論理構造の検討を行うとか、エレガントなコードが書ける人も求めると言うのが(特にお金の面で)難しくなっている事も理由だとは思いますが。プロジェクト管理で品質について考える場合でも、通常は表層的なバグ数のカウントに終始している訳で、コードの安定性の様なものはバグの原因にさえならなければ無視、無視出来ない場合は大炎上ですね(少なくとも僕が絡んでいる所ででは、ですが)。

             ルータ構成ツールにステートチャート(UMLのではなくて、ステートマシンの記述の方)の作成がプログラミングになるものがあります。エレガントなコードを志向するのが死に筋なら、その様なアプローチもありなのかな、と思っています。

            親コメント
          • by Anonymous Coward
            PAD
          • by Anonymous Coward

            >でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…

            UMLのシーケンス図はどうかしら

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

処理中...