アカウント名:
パスワード:
コードかけないやつが幅きかせすぎってとこだと思うんだけど。
コード書けない奴が偉そうにするのが問題なのではなくて、設計できない奴が設計してるのが問題なんだろう。経験的にも、コード書けないけど、設計は出来るってのは多いし、コード前提で考えないから設計がしっかりしてることも珍しくない。逆に、コード書けるからといって、そいつが必ず設計できるってわけでもないしな。
＞ 経験的にも、コード書けないけど、設計は出来るってのは多いし、
俺の経験と違う…
プログラム設計は無理かも知れないけど、設計は出来るよ。出来ること出来ないことや実装の難易度があるから言語は知ってた方が良いけどね。
設計のレベルによるかなぁ。
基本設計ならアーキテクチャを押さえてれば言語の詳細など開発そのものの知識はなくて大丈夫。詳細設計は無理かな。逆に詳細設計できるなら手が遅くてもその人は実装できる。
むしろこんな巨大で金にストレートに繋がる案件で、下っ端プログラマが直接設計なんてしていたら、その時点で怖いわ。いや足並み揃わずリリース出来ずにかえって傷が浅かった可能性も有るのか。
出来るのはユーザーサイドでも出来るような、簡単な要件定義やUIの設計だけでしょ。ネットワークに繋がるのがあたりまえの時代に、通信プロトコルの設計や、セキュリティーへの配慮など、根本的に大事なことを理解するにあたってコードが書けないなんてことは普通はありえない。
「そんなつもりじゃなかった」「想像していたのと違う」って最終的な要件定義やUIの設計はユーザーから出そろうと思うよ。(無限の時間がかかったり、個々の要件が相互矛盾を起こしてたりするけど)
大きなプロジェクトではそこをキッチリまとめられるかどうかが成敗を決めると言っても良いのだが。特にここで言及しているのはウォーターフォールでの開発だろ？その辺りはキッチリ出来る前提でしか成り立たん様な物だ。
そして世の中、その辺りの網羅が全く以て出来ていないって事例が多々あるのが、動かないプロジェクトの発生する大きな理由の一つだ。
＞ネットワークに繋がるのがあたりまえの時代に、通信プロトコルの設計や、セキュリティーへの配慮など、＞本的に大事なことを理解するにあたってコードが書けないなんてことは普通はありえない。その辺りの上流設計に必要なのはワークフローやデータフローだけだろ。実装レベルの設計なんぞ担当の取りまとめに任せれば良いってか任せられることになって居るからウオーターフォールでやれるんじゃん。
で、実際のところ、通信や暗号やセキュリティーへの理解が深く、それに関連するデータフローを設計できるにも関わらず、何故かコードは書けないなんて奴を見たことあるのか？
一山いくら的な人の管理してるプロジェクトだと、設計もコーダーが担当してたりするからね。ロジカルに物を考える人は、コードも設計も出来る側になるし、ロジカルじゃない人はどちらも出来ない。
いわゆるホワイトなプロジェクトに行くと、コード書いたことないとか、趣味では書くけど仕事では書かないって人たちが設計してる感じになるよ。ロジカルに物は考えるにしても、設計でとコードのレイヤで考える物事が別物になるから、ほどほどに両方できるってレベルの人は設計に関わったりしない。
設計と言っても色々だからなたぶんアンタの言ってる「設計」と親コメントの奴の言ってる「設計」のレイヤーは別だろう上流レイヤーの「設計」だとそういう国語的（文系的な）仕事だったりもするし
テクニカルドキュメントを作るのは文系仕事じゃなくて技術職の仕事だよ。仕様書や設計書を文系的と称するならプログラムも言語で書かれるので文系的ってことになる。技術論文も文系的仕事って扱いになる。むしろ文書を書く行為はエンジニアリングの歴史そのものなのに「文書を書く行為は文系的」と考えてるなら思考停止過ぎる。要件定義や要求分析レイヤーが「システム化対象の人間活動に深くかかわる」からと言って「文系的」レイヤーとか考えてるならそれも間違い。非論理的な人間活動をシステムによって論理的に整理するのがシステム化なんだからアウトプットはロジカルに矛盾なく実装できる要求仕様に落とさないといけない。これは技術文書の書き方を習得したエンジニアの仕事。「国語的な仕事」では無い。
文系的な仕事「だったりもする」だから別に文系の仕事と限定していないな。上流になるほどテクニカルなドキュメント以外を作る必要は出てくる。最上流は技術者同士の話じゃなくなるしな。
「上流は国語的で」「上流は文系的で」って逃げてるだけでたとえ上流でも最終的に実装される論理層を理解している必要がある事実は変わらんけどね。最上流ってのが設計や仕様を切らないなら、まあそれは関係ない奴らが駄弁ってるだけでしょ。
PGM言語ってのは手段であって目的じゃないってこととここで言ってる設計っていうのはPGM設計じゃないってことだよあんたの経験してきたとこは ・小規模案件でマルチでやらされてきた ・設計者がプログラマー上がりばかりだった ・表面的にはアジャイル風の開発ばかりだったとかだったんだろ
俺の経験とも違う。レベル低いとこだと設計出来てないことに気づかれないのかも。可能性として
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
論点はそこじゃないのでは？ (スコア:0)
コードかけないやつが幅きかせすぎってとこだと思うんだけど。
Re: (スコア:0)
コード書けない奴が偉そうにするのが問題なのではなくて、設計できない奴が設計してるのが問題なんだろう。
経験的にも、コード書けないけど、設計は出来るってのは多いし、コード前提で考えないから設計がしっかりしてることも珍しくない。
逆に、コード書けるからといって、そいつが必ず設計できるってわけでもないしな。
Re:論点はそこじゃないのでは？ (スコア:1)
＞ 経験的にも、コード書けないけど、設計は出来るってのは多いし、
俺の経験と違う…
Re: (スコア:0)
プログラム設計は無理かも知れないけど、設計は出来るよ。
出来ること出来ないことや実装の難易度があるから言語は知ってた方が良いけどね。
Re: (スコア:0)
設計のレベルによるかなぁ。
基本設計ならアーキテクチャを押さえてれば言語の詳細など開発そのものの知識はなくて大丈夫。
詳細設計は無理かな。逆に詳細設計できるなら手が遅くてもその人は実装できる。
Re: (スコア:0)
むしろこんな巨大で金にストレートに繋がる案件で、下っ端プログラマが直接設計なんてしていたら、その時点で怖いわ。
いや足並み揃わずリリース出来ずにかえって傷が浅かった可能性も有るのか。
Re: (スコア:0)
出来るのはユーザーサイドでも出来るような、簡単な要件定義やUIの設計だけでしょ。
ネットワークに繋がるのがあたりまえの時代に、通信プロトコルの設計や、セキュリティーへの配慮など、根本的に大事なことを理解するにあたってコードが書けないなんてことは普通はありえない。
Re: (スコア:0)
そんなユーザーがいるなら設計は私がしますから屏風から出してください
Re: (スコア:0)
「そんなつもりじゃなかった」「想像していたのと違う」って
最終的な要件定義やUIの設計はユーザーから出そろうと思うよ。
(無限の時間がかかったり、個々の要件が相互矛盾を起こしてたりするけど)
Re: (スコア:0)
大きなプロジェクトではそこをキッチリまとめられるかどうかが成敗を決めると言っても良いのだが。
特にここで言及しているのはウォーターフォールでの開発だろ？
その辺りはキッチリ出来る前提でしか成り立たん様な物だ。
そして世の中、その辺りの網羅が全く以て出来ていないって事例が多々あるのが、動かないプロジェクトの発生する大きな理由の一つだ。
＞ネットワークに繋がるのがあたりまえの時代に、通信プロトコルの設計や、セキュリティーへの配慮など、
＞本的に大事なことを理解するにあたってコードが書けないなんてことは普通はありえない。
その辺りの上流設計に必要なのはワークフローやデータフローだけだろ。
実装レベルの設計なんぞ担当の取りまとめに任せれば良いってか任せられることになって居るからウオーターフォールでやれるんじゃん。
Re: (スコア:0)
で、実際のところ、通信や暗号やセキュリティーへの理解が深く、それに関連するデータフローを設計できるにも関わらず、何故かコードは書けないなんて奴を見たことあるのか？
Re: (スコア:0)
一山いくら的な人の管理してるプロジェクトだと、設計もコーダーが担当してたりするからね。
ロジカルに物を考える人は、コードも設計も出来る側になるし、ロジカルじゃない人はどちらも出来ない。
いわゆるホワイトなプロジェクトに行くと、コード書いたことないとか、趣味では書くけど仕事では書かないって人たちが設計してる感じになるよ。
ロジカルに物は考えるにしても、設計でとコードのレイヤで考える物事が別物になるから、ほどほどに両方できるってレベルの人は設計に関わったりしない。
Re: (スコア:0)
設計と言っても色々だからな
たぶんアンタの言ってる「設計」と親コメントの奴の言ってる「設計」のレイヤーは別だろう
上流レイヤーの「設計」だとそういう国語的（文系的な）仕事だったりもするし
Re: (スコア:0)
テクニカルドキュメントを作るのは文系仕事じゃなくて技術職の仕事だよ。
仕様書や設計書を文系的と称するならプログラムも言語で書かれるので文系的ってことになる。技術論文も文系的仕事って扱いになる。
むしろ文書を書く行為はエンジニアリングの歴史そのものなのに「文書を書く行為は文系的」と考えてるなら思考停止過ぎる。
要件定義や要求分析レイヤーが「システム化対象の人間活動に深くかかわる」からと言って「文系的」レイヤーとか考えてるならそれも間違い。
非論理的な人間活動をシステムによって論理的に整理するのがシステム化なんだからアウトプットはロジカルに矛盾なく実装できる要求仕様に落とさないといけない。これは技術文書の書き方を習得したエンジニアの仕事。「国語的な仕事」では無い。
Re: (スコア:0)
文系的な仕事「だったりもする」だから別に文系の仕事と限定していないな。
上流になるほどテクニカルなドキュメント以外を作る必要は出てくる。
最上流は技術者同士の話じゃなくなるしな。
Re: (スコア:0)
「上流は国語的で」「上流は文系的で」って逃げてるだけでたとえ上流でも最終的に実装される論理層を理解している必要がある事実は変わらんけどね。
最上流ってのが設計や仕様を切らないなら、まあそれは関係ない奴らが駄弁ってるだけでしょ。
Re: (スコア:0)
PGM言語ってのは手段であって目的じゃないってこととここで言ってる設計っていうのはPGM設計じゃないってことだよ
あんたの経験してきたとこは
・小規模案件でマルチでやらされてきた
・設計者がプログラマー上がりばかりだった
・表面的にはアジャイル風の開発ばかりだった
とかだったんだろ
Re: (スコア:0)
俺の経験とも違う。
レベル低いとこだと設計出来てないことに気づかれないのかも。可能性として