07/09/21 23:36:37
>>858
派遣元に文句言えば？
866:基本設計書
07/09/22 00:22:34
大阪の堺筋にある株式会社●ィッツ。ここだけは就職やめとくべし。
Ｉ次長。こいつバカ。沸点30度くらいで、すぐ茹蛸みたいに切れる上に、
仕事もいい加減。自分を棚にあげて部下に八つ当たり。出向先の人も
やりにくそうだよ。自分もこいつとは仕事したくないｗ
867:仕様書無しさん
07/09/22 00:25:04
そこまで言ったならばｋｗｓｋ
868:仕様書無しさん
07/09/22 01:04:59
沸点30度くらいという事は夏だと突沸が起こりやすいのかも
もう少し温度が低くなると昇華するかも
869:仕様書無しさん
07/09/22 01:07:28
>>868
30分ほど外に出しときゃ消えてなくなるだろ。今年の夏はチャンスだ！
870:仕様書無しさん
07/09/22 01:57:46
>>858
4日聞いてみてから決めたら？辞めるんはすぐできる。
なんとなくいけそうな気がする。4日もあれば。
前任者がウンコならムリかもしれんが。
871:860
07/09/22 04:30:10
>>861-864
あ、ごめん。
VistaじゃなくてCore2Duoがもっさりだったんだ。
872:仕様書無しさん
07/09/22 18:39:51
さらに訳がわかんねぇ
873:仕様書無しさん
07/09/22 18:52:39
C2Dをもっさりに動かしてるならアホとしか言いようがない
874:仕様書無しさん
07/09/23 14:44:55
キャッシュ効率が落ちるようなメモリアクセスパターンをしているとか？
875:858
07/09/23 16:12:42
前任者はウンコでした。Excel VBA(Office 2003)なんですが…
・メソッド1つが400行ぐらいあったりする
・If文の山
・エスパーにしか分からない変数の命名
という特徴がソースから読み取れました。
あと、Date型から日付をフォーマットして文字列を返す処理にformat関数を使わずに
何か年・月・日・時・分・秒の文字列を生成し、それを & 演算子で繋いだり、
VBAの知識も浅いのが散見されたり、"のエスケープを知らずにChr(34)を延々と繋いだり…。
見てて痛々しくなってきました。
直属の上司はVBAを知らないので、内部のソースにノータッチです。
ｽﾚﾘﾝｸ(tech板:863番)
ｽﾚﾘﾝｸ(tech板:865番)
ｽﾚﾘﾝｸ(tech板:866番)
みたいな状態ですかねぇ。
機能拡張を求められていますが、そのためにはリファクタリングするしか無さそう。
「クラスモジュール」同士の結合が密なため、疎結合にしないとエライことになりそう。
少なくとも、入力→処理→出力という、構造化プログラミングの王道は知らない模様ですね。
まぁEUC-JPな出力をするために、ADODB.Streamを使っているので、逐次出力は出来ないんですけど。
（ていうかVBAでEUC-JPを出力するのに他の「容易に実装可能な」方法があれば教えて欲しいっす）
あ、私自身はPerl畑出身で、OOPについての理解が浅いのは自覚してます。
片手間でリファクタリングできるか自信は無いですね、はい。
やっつけで、該当する処理部分にIf文を追加して、出力部分に反映させるとか
バータリー指向プログラミングで対処するぐらいしか思いつかない…。
876:858
07/09/23 16:15:41
"のエスケープを知らずにChr(34)を延々と繋ぐというのは、
文字列リテラルで、たとえば
strA = "<input type=""hoge"" nantoka=""fuga"">"
などで済むものを、全て
strA = "<input type=" & Chr(34) & "hoge" & Chr(34) & " nantoka=" & Chr(34) & "fuga" & Chr(34) & ">"
という風に書いてあるというものです。
877:870
07/09/23 16:21:46
>>875
この期間でそんだけ解析できる内容なら超余裕。
878:仕様書無しさん
07/09/23 16:23:49
>>876
それは文法的に間違っていないし、私は良いと思いますけど。
VBAだと速度的に遅くなるのかな？
リターンコードを vbcr (だったっけ？)で書くのも自由。
書かぬのも自由かと。
まぁ、可読性は悪くなるか。
879:仕様書無しさん
07/09/23 16:24:41
>>875
>ADODB.Streamを使っているので、逐次出力は出来ない
使用方法のサンプルコード見て、Streamて名前に違和感を持った。
880:仕様書無しさん
07/09/25 01:11:59
派遣なんでしょ？
機能追加の指示でしょ？
しかも工数掛かるならレスポンス改善は不要とまで明言して貰ってる。
言われた事だけやればいいじゃん
そんで派遣元のコーディネーターに文句たれたらいいじゃん
プロパーで後任になって今後も長期保守する案件なら
あんたの考え方は正しいだろうが
一人月超えたらどんなに改善されても採算合わないんだろうし
レスポンス悪いならリプレースかけて金取る口実になるじゃん
クレームになってないなら尚の事あんたの自己満足でしかないでしょ
881:仕様書無しさん
07/09/25 01:27:19
そういうソースを引き継がれる身になれっての
882:仕様書無しさん
07/09/25 01:39:48
>>879
まったくもってそのとおり。
言われたことを約束の納期までに仕上げてくれればOK。
ムリなら最初にムリと言ってもらえれば助かる。がんばるとかいらないから。
で、違和感感じた技術者>>879
職人として生きてくなら違和感を感じるその感性は大事だと思う。
理想があっての現実解。理想なき妥協には技術的進歩はない。
883:880
07/09/25 08:18:36
例えば機能追加だけして、
納品時に顧客からもっと速くならん？と聞かれたら
Vista対応でも2007対応でも素人ウケする適当な名目で
それはちょっと大変なんでと工数ふっかけて
金と工数をぼったくった上で直すなら理解できる
客なんて解ってないから頼みもしないのに処理が速くなったら
今まで不良品を宛がわれてた事に気付いてクレームになる
それでバグがでたら目も宛てられん
884:仕様書無しさん
07/09/27 02:11:34
>>880
仕様書・設計書の無いスパゲティに機能追加する恐ろしさを知らないな
何処に影響が出るか分からないんだぞ
まぁ派遣だし、いざとなったら脱走すればいいさ
885:仕様書無しさん
07/09/27 08:16:07
>>884
ウチの場合、
スパゲッティの機能追加は危険だから受けないのが基本。
要望がきたら
このバージョンには難しいので作り直さないと無理です
とか言って新規受注を促す。
すると諦めて金出すか、諦めて現状機能で我慢するか、
怒って他社に鞍替えになる。
法令改正などで変えざる得ない場合でも極力断るし
やるにしても最小限に留める(買替えの動機付になるから)
保守しない方針だから汚くても安全ならコピペ修正を選ぶ
派遣君のとこは会社としての対応方針どうなってます？
少なくとも採算とれない改修はしないという方針では？
そしてプロパーの開発力をそんな所へさけないから
あなたが雇われたのではないでしょうか？