難しく考える開発者(ＰＧ)について

投稿者

投稿内容

どせい: 大ベテラン; 会議室デビュー日: 2006/10/25; 投稿数: 145

投稿日時: 2006-11-25 12:58

未記入です。

問題を私なりに、簡潔に整理してみました。

要するに「わけ分からない事ゴチャゴチャ言ってないで俺の言うことを聞け」

という判断が、問題(トラブル)を起こす原因の様に思います。

無理やり職制で通すのも対話し理解しようとするのもお前さん次第だろ

[ メッセージ編集済み編集者: 未記入編集日時 2006-11-25 13:00 ]

冬寂: ぬし; 会議室デビュー日: 2002/09/17; 投稿数: 449

投稿日時: 2006-11-25 13:09

>未記入さん
GJ!

# 自分としては、

引用:
Practical SEさんの書き込み (2006-11-24 16:58) より: 本人に聞きましたが、教科書ではこうしているとの回答でした。なぜこうするのかは説明してもらったのですが、論理ばかりで理解できませんでした。

この時点で、終わってる気がする。
（「論理ばかりで理解できない」あたり、S氏っぽいのは気のせいだろうか？）

あしゅ: ぬし; 会議室デビュー日: 2005/08/05; 投稿数: 613

投稿日時: 2006-11-25 20:04

「if文追加するだけ」
「そういうデータは絶対ない」

非常に胡散臭い言葉です。

その言葉が覆されるのは数年後かもしれませんし、
開発中のシステムであれば、結合テストフェーズかもしれません。

仕様詰めの段階では現実味がなくて想像できていなかった問題が、
実装フェーズ以降で露見することは頻繁にあります。

一般的に後の行程になればなるほど、手戻りのダメージは大きくなるので、
多少の手間がかかったとしても、スキーマやプログラムを正しい姿に保つ事は、
後々の災厄を防いだり、軽減させるためにはとても有効な方法です。

＃経験上、平和だった案件の大半はまともな姿を保っていました。

見方を変えると、汚いシステムを作っておいた方が、後々の仕様変更時に
見積もりを高くできるわけで、開発を請け負う側にもメリットはあります。
多くの場合は個々の開発者にしわ寄せが行くだけかもしれませんが。

・・・とりあえず、短絡的にならない方がいいですよ。

加納正和: ぬし; 会議室デビュー日: 2004/01/28; 投稿数: 332; お住まい・勤務地: 首都圏

投稿日時: 2006-11-25 22:06

コミュニケーション的なところは、協力会社とかの関係があるから
必ずしも従業員が制御できないので、それはおいといて。
純粋に技術的なところだけ。

引用:
Practical SEさんの書き込み (2006-11-24 17:05) より: なぜ、ソースに直接書かないでテーブルを用意してマッチングをかけたほうがよいのか具体的に教えてもらえませんか？ソースに商品コードを書くのはセキュリティ上の問題なのかなとおもいますけど。

そもそも、DBをなぜ使用するのでしょうか。
通常、検索処理にプログラムを使うのは、設計上はおかしいことになります。
#よくやるんですけど。
なぜなら、通常DBサーバの方が良いマシンを使用します。しかもDBMS
は、検索が得意です。だからソースに記述しないでDBにやらせる方が高速処理
できるに決まってます。

それに、DBはコーディングを減らすためにあります(という考え方も出来ます)

また、技術的には、「データ」を制御するのが
「DB」か「プログラムコード」なのかは常に議論があります。

普通は設計上、データ制御は、DBに任せる方がいいはずです。
ビジネスロジックそのものは、プログラムコードの方なのでしょうけど。

しかも、最近はDBにストアドプロシージャとしてロジックが記述できてしまうので
さらに分からなくなりますが。。。本来はそこら辺も含めて設計するのが
正しい方向だとは思います
#テスト工程時には出来たためしがないが。

ognac: ベテラン; 会議室デビュー日: 2005/06/21; 投稿数: 65

投稿日時: 2006-11-27 14:20

出遅れましたが一言。 Practical SE氏の泣き言はさておき, SEの役割が仕事になっている以上、言い訳はいかがなものでしょうか?
多くの人がコメントされているように, 商品群に除外商品が発生した時点で,システムの再検討するのは当然の流れだと思います。
(コストの兼ね合いで.妥協点として、ハードコーディングで対処することもありえます。)
システムに除外商品の処理が考慮されていない状態で,除外商品が発生したら, SEが第一に考えることは, 「除外識別項目の追加とSelect文の見直し」ではないですか。
　Select文の箇所があちこちに点在していて煩雑だというのはシステムが不味いからです。select文などは頻繁に変更されることを前提に作られている筈です。
　DBの見通しがスッキリしていれば, 識別項目の追加は軽いものだと思います。
ここから先は想像でしかありませんが、SE氏は, DB構造に手を加えるのが怖い, select文がどこに散らばっているか把握できない。識別項目追加に伴なう影響が想定できない。
それ由に, if 商品code <> 除外商品 then 集計処理の1文で済ませたい.....これが本音だと感じました。
　　この対処は　局所的な絆創膏です。　絆創膏はシステムを悪化させます。この時点で　PGさんに賛同します。
商品マスターに商品属性項目を持たせていない時点でシステム欠陥という気もしますがどうでしょうか。
Practical SE氏は SE職にある以上, SE力向上努力も仕事だと思います。
少しキツイ文になりましたが, 雑感まで。

_________________
ognac＠わんくま同盟

狂: 会議室デビュー日: 2006/10/17; 投稿数: 13

投稿日時: 2006-12-09 16:39

すでに、閉じている問題ですけど。

引用:

Practical SEさんの書き込み (2006-11-24 17:16) より:

補足します。
当該システムは、チェーン店の商品管理システムです。
いままで店ごとにバラバラだった商品コード体系を統一しました。
しかし、お客様の都合でどうしても旧コード体系で管理したい商品がひとつだけありました。
いままでは、この商品も同一処理で集計していましたが
この商品は仕入れ対象からはずす（仕入先が倒産かつ個別清算済み）ので、
今期末の締め日処理からも除外してほしいとのことです。
今後、入力されるコードは新コードのみです。
ＤＢをつくるまでもありません。

現実社会を無視してませんか。
システムの運用期間内に、仕入先が倒産かつ個別清算済みになる確立は、０％でしょうか。
こればかりは、顧客も断言できないと思われます。

仕入先がつぶれれば、除外する商品コードが増えると思われますが。

判断する情報が少ないので、これぐらいしか推測できません。

«前のページへ 1|2|3|4|5|6

難しく考える開発者(ＰＧ)について

スキルアップ／キャリアアップ（JOB@IT）