アカウント名:
パスワード:
「もうやらなくてもいい昔のコーディング規約」かと。
ええ、もちろん大昔の話ですよ?
自分が何時代に居るのか最近判らなくなってきています。
新人が「フローチャートの書き方がよく分からなかったのでもう少し勉強して書けるようになりたいです」という日々の報告を上げてくるような組織のそばで働いています。やめさせた方がいいですか?いや、直接教育担当ではないので、口出ししないように言われているのですが。
もちろん、オブジェクト指向だ何だといっても、中では順序だって処理する部分が絶対にあるわけで、その部分の処理の流れを図で示せる能力は必要だと思いますが....新人が悩んで自信を無くしかけるほどまで深く掘り下げる場所じゃないとおもうんですよね。
同意
フローチャートなんて無くても困らない必要になるのは、やたらとフローチャートに拘る年代の方に見せる資料を作成する時かなー。
最近の開発環境でフローチャート書けるだろうか。並列処理は書けないのよね、あれ。
> プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
御意。居りますなあ。一年位でアプリからカーネルまで出来る様になって欲しいのですが、前途遼遠・・・
> でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
NSチャート、PAD位しかチャートを知らないのですが、どれも一長一短がありますね。しかし本来はコードを書く前にチャート等で論理構造を検討する必要がある人達も時代の流れでチャート等を書かなくなり、その帰結として「なんじゃ?こりゃ?」なコードの大量生産、これが近年の傾向では無いでしょうか。もっとも、チャート等で論理構造の検討を行うとか、エレガントなコードが書ける人も求めると言うのが(特にお金の面で)難しくなっている事も理由だとは思いますが。プロジェクト管理で品質について考える場合でも、通常は表層的なバグ数のカウントに終始している訳で、コードの安定性の様なものはバグの原因にさえならなければ無視、無視出来ない場合は大炎上ですね(少なくとも僕が絡んでいる所ででは、ですが)。
ルータ構成ツールにステートチャート(UMLのではなくて、ステートマシンの記述の方)の作成がプログラミングになるものがあります。エレガントなコードを志向するのが死に筋なら、その様なアプローチもありなのかな、と思っています。
>でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
UMLのシーケンス図はどうかしら
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
てっきり (スコア:5, おもしろおかしい)
「もうやらなくてもいい昔のコーディング規約」かと。
ええ、もちろん大昔の話ですよ?
Re: (スコア:0)
自分が何時代に居るのか最近判らなくなってきています。
新人が「フローチャートの書き方がよく分からなかったのでもう少し勉強して書けるようになりたいです」という
日々の報告を上げてくるような組織のそばで働いています。やめさせた方がいいですか?いや、直接教育担当では
ないので、口出ししないように言われているのですが。
もちろん、オブジェクト指向だ何だといっても、中では順序だって処理する部分が絶対にあるわけで、その部分の
処理の流れを図で示せる能力は必要だと思いますが....新人が悩んで自信を無くしかけるほどまで深く掘り下げる
場所じゃないとおもうんですよね。
Re:てっきり (スコア:1)
#フローチャート書いてる暇があったら、なんでもいいから動くもものを作った方が勉強になると思う。
Re: (スコア:0)
同意
フローチャートなんて無くても困らない
必要になるのは、やたらとフローチャートに拘る年代の方に見せる資料を作成する時かなー。
Re: (スコア:0)
最近の開発環境でフローチャート書けるだろうか。並列処理は書けないのよね、あれ。
Re: (スコア:0)
並列処理云々という前に、プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
雛形(#include <stdio.h>~int main(...){...})だけとりあえず与えて、中に必要な流れを書いていくということをやらせると、
どういう手順でやっていったらいいかまるで考えられないというのがごろごろと。
だからとりあえず必要なことを列挙させ、線でつなげさせて必要なロジックを埋め込んでいってフロー化させる。
「いらないだろう」という人たちは、半ば無意識にでも「どういう手順でやっていったらいいか」がつなげられる人たちなんです。
並列云々へ行く前に、思考力を鍛えるためにはなんらかの形での目で見える形にするのが必要だと思います。
でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
Re:てっきり (スコア:2)
> プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
御意。居りますなあ。一年位でアプリからカーネルまで出来る様になって欲しいのですが、前途遼遠・・・
> でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
NSチャート、PAD位しかチャートを知らないのですが、どれも一長一短がありますね。しかし本来はコードを書く前にチャート等で論理構造を検討する必要がある人達も時代の流れでチャート等を書かなくなり、その帰結として「なんじゃ?こりゃ?」なコードの大量生産、これが近年の傾向では無いでしょうか。もっとも、チャート等で論理構造の検討を行うとか、エレガントなコードが書ける人も求めると言うのが(特にお金の面で)難しくなっている事も理由だとは思いますが。プロジェクト管理で品質について考える場合でも、通常は表層的なバグ数のカウントに終始している訳で、コードの安定性の様なものはバグの原因にさえならなければ無視、無視出来ない場合は大炎上ですね(少なくとも僕が絡んでいる所ででは、ですが)。
ルータ構成ツールにステートチャート(UMLのではなくて、ステートマシンの記述の方)の作成がプログラミングになるものがあります。エレガントなコードを志向するのが死に筋なら、その様なアプローチもありなのかな、と思っています。
Re: (スコア:0)
Re: (スコア:0)
>でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
UMLのシーケンス図はどうかしら