「デグレード」を含む日記 RSS

はてなキーワード: デグレードとは

2020-10-22

anond:20201021210748

若い女性の脳内ロジックに「不甲斐ないおっさんを余すところ無く喜ばせる」ってロジックを組み込むと、デグレード起こすぞ。

次元DRYだし、SOLIDだし、いいことづくめだぞ。

生身の女を欲しがる気持ちYAGNIを!

脳内の「女児が好き」というロジックを消して、本人の脳のデグレードを起こしても、本人の責任だよな。

日本IT業界ブラックである理由

「赦し」がないから以外に何が考えられるのか。

しろコンピュータとは、人類の「赦し」を試すために生まれてきたのかもしれない。

バグが出ても「赦す」、デグレードしても「赦す」、納期が遅れても「赦す」だけでよい。

実は銀の弾丸はここにあり、これぞ唯一の銀の弾丸だ。

そんなことは絶対に無理だろうと皆思うだろう。

ここで陳腐な話ではあるが、解決策を示そう。

SIの客、ITゼネコンの客、ユーザー企業の客…というように辿ってゆくと、最終的には個人消費者に至る。

個人消費者はどうか。

ミスを犯した企業は全て「悪徳企業」で、叩こうが虐めようが全てが正義だ。

まりIT業界ブラックにしている責任は、IT業界の末端のエンジニアを含む日本人全員にある。

このような正義に疑問さえ持てば、技術負債などという言葉議論に登る必要性すらないのだ。

2020-09-11

価値観アップデートしたと思ったら~、

デグレードしてました~。

チクショー!!

2018-06-25

anond:20180625055126

いまちょうど最適化始める前と同じ機能が完成したからやっとデグレードしてないと言えるようになった

仕事にしてないからこんな調子でできるけど、仕事コード打ち込んでる人ほんと凄いと思う

2015-06-24

弊社(独立系SIer)の紹介

皆様の入社を、心よりお待ちしております

安心と信頼のウォーターフォール

設計3ヶ月、開発1週間

技術が育たない

→とにかく動かせ!の動けば良いの精神

試験修正に3ヶ月

ソーススパゲッティ化で可読性皆無

仕様変更設計からやり直し

→以下無限ループ

納期に追われて

命名規則?そんなのやってられっか!

ローマ字メソッド名多発、日本語でおk

効率の良いコーディング?知るかんなもん!

ソーススパゲッ(ry

→誰だこのコードを書いたやつ、ぶっ殺してやる!

あなたです

現調でてんやわんや

→あれ?動かねぇぞ・・・

ソースを見るもスパゲッティイミフ

→とりあえずの応急措置ソースさらゴミ

デグレード発生

→とりあえずの応急措置でs(ry

→以下無限ループ

そもそもの発端は

経営陣「利益上げろ!とにかく働かせろ!」

デスマ危険を察し退職者急増

→少ないメンバで多くの案件を処理、追いつかない、フリーズ

デスマ突入ハイパー残業タイム

経営陣「(数字だけ見て)利益出てねぇぞ!働かせろ!」

さら案件を受注

デスマカンシーズン突入ハイパー徹夜タイム

経営陣はホビロン

営業「言語VB.NETでよろしいでしょうか」

→みんな大好きVB

技術が育たない

→そもそも多言語学習する意欲を持っていない

この先生きのこれない

新人派遣

OJT?そんな余裕はねぇよ

新人入社1週間で派遣先

→1ヶ月も経たない内に追い返される

2014-03-28

下請け底辺泥臭Webアプリデバッグ手法

次々とやってくるさまざまな環境で色々がんばる人のためのノウハウを集めてみよう。

必ずしも綺麗な環境で開発できる人ばかりじゃない。スパゲッティを手渡されラーメンを作れといわれる。

所詮下請けなので、そもそもこうした方がいいよとか軌道修正すらできない環境で足掻くために何ができるのか。

今回はみんな大好きPHPを使った場合の話をしましょう。

1. なんだよこれどこの処理通ってんだよわけわかんねぇよ。

朝はCakePHP、昼はsymfony、右向きゃ独自FW、左向きゃ素php

こんなこと、よくありますよね!

いろんなFWを使ってるとFW固有の機能とかもう何がなんだかわけがからなくなります

FW機能を使ってデバッグなんてやってられません。一番信頼できるデバッグ方法とはなんでしょう。

・・・うprintデバッグです!!!printデバッグこそ神!PHPならprint_rを使おう。

ただし出力バッファ捕獲したりするFWもあったりするのでprintだけだとどこの処理通ってるかわけわからんときがあります

そんなときはこれ!

exit

exitだけは何者にも犯せない最強の関数言語構造)なので確実に処理がとまってくれます。なのでわけわからんことになったら真っ先にexitしましょう。

2. ローカル環境作りたい?むぐぐこの定数とか関数とかローカルじゃうごかねぇよ

世の中には開発者PC環境ローカル環境)を作るのが困難な場合があります。例えば設置できたはいいが、ローカルでこの関数が動かないor動いたらまずいだとか

この定数はローカルだと微妙、書き換えたいとか。

こんなこと、よくありますよね!

そんなとき僕達がよくやる対策としてはソースコードを直接書き換えることですね!呼ばれたくない関数は中身をコメントアウトしたり、定数はローカル用の値に書き換えたりするわけです。

しかしこのやり方は少し問題があるのです。

例えばSVN等を使っている場合、常にこれらのファイルが変更状態のままになってしまます。間違えてコミットしちゃった!なんてこともあります

そして更にそのファイルに何か変更があった場合とても面倒です。関数コメントアウトを外し、定数は本番環境用に戻してからコミットする、なんてことになります。まぁ確実にいつか人的ミスが入るでしょう。

そこで僕が推奨するのはファイルを直接書き換えずに書き換えろ。ということです。

まりrunkitを利用するのです。

通常PHP関数や定数などを動的に上書きすることはできませんが、runkitを使えばそれができてしまうのです。このようなローカル環境を無理やり構築したい場合にはとても使える機能です。

もちろん本番環境においてrunkitを使うのはご法度だと思います伝家の宝刀馬鹿と鋏は使いよう、です。

3. 今何が最新なの?ねぇねぇ?もう僕わかんない

こんな経験はありませんか?

「ここを改修して欲しい」

「わかりました、じゃあSVNをUPDATEしてから改修しますね。」

「いや、今はステージング環境にあるファイルが最新なのでそこからダウンロードしてから作業してほしい」

「あ、そうなんですか、じゃあステージングから持ってきて対応します」

「改修完了しました。コミットしてステージングにアップします」

「動作問題無いので次は本番環境にアップしますね」

「あれ、なんか本番の動作がおかしい!デグレードしてますデグレードしてます!」

「どうやら本番環境のみに誰かがファイル書き換えていた模様」

「誰だrsync使わずアップしたやつわッ」

コミットもされてねぇ!」

「競合!競合!」

「うわああああああ、今何が最新なの?ねぇねぇ?もう僕わかんない。」

増税前にdiffすれば良かった」

こんなこと、よくありますよね!

この後の担当者の作業はこうです。

ローカル環境ファイルSVNdiffステージング環境diff。本番環境diff

改修対象ファイルが複数ある場合diff作業の大変さと言ったらもう筆舌に尽くし難いものとなります

僕は思いました。ローカル環境ファイルと、SVNステージング環境と、本番環境diffワンコマンドでさっとできたらどれだけ楽か・・・

そして作りました。それができるdiffコマンドを。

もちろん探せばそういったツールを見つけることは可能だとはおもいますが、探すのが面倒だったので自作しました。

そのツールをここに晒す事もできなくはないですが、この余白はそれを書くには狭すぎるので今回はそういうアプローチがあるということだけを書いて終了します。

とりあえず僕が自作したのはローカル(windows)とhttp(SVN)とftpssh対応した相互diffツールです。全ての環境の組み合わせでdiffをして差分を表示したり、特定環境だけをdiffしたりできるので開発効率アップです。

何より気軽にdiffしようという気が起きます

4. 見なかったことにしよう

タイトルで言ってしまった感がありますが、下請けで改修作業をしていると既知バグ発見してしまうことがあります

これは非常に難しい問題です。もう完全にクライアント次第としかいいようがないんですが、クライアントに報告すべきかしないべきかは慎重に考える必要があります

バグを報告するとちょちょっと直してよ、とかいクライアントもいますし、何よりクリティカルバグ場合見積もりしてくれと言われたとしてもとてもじゃないけど責任を請け負いたくない場合もあります

なので見なかったことにする。

む、ちょっと眩暈が。最近寝てなかったし。とか言いながら缶コーヒーでも飲んで一服しましょう。

するとどうでしょう、さっきまでバグを見過ごさないのはプログラマ矜持だとかなんとか言ってたのにあら不思議、とりあえず今改修対象のところだけ直そう。となります

・・・こんなこと、よくあります、よね?とほほ。

5. うん。もうない。

20個くらい書くつもりで見切り発車してみたものの、もうない。泥臭い作業にノウハウなんてないのだ。

所詮泥は泥。ドロドロ。細かいコードの書き方まで言い出せばいくらでもあるけど「些末なコードレビュー」の話したところで泥で足掻いてる人にとってはなんら救済にならないし別に必要ないよね。

さてここからは他にも泥臭い作業をしている人たちでノウハウを構築しようではないか。6番目以降を書く同志達を僕は待ち望んでいるッ!

2010-12-18

http://anond.hatelabo.jp/20101218200647

それは時計の針をさかのぼらせてもかまわないという風にも聞こえるけど、それで本当にいいんだろうか?

過去の問題を解決すべく何かしたら問題は解決したしかし新しい問題が出てきた、また何か対策考えるぞ、というのが人類歴史進歩であって(進歩主義者は馬鹿にされるが、じゃあ進歩が全くないとか言い出すと事実と合わなくなる)、抑圧したデグレードしたりすると、人類歴史暗黒時代になるぞ。

2009-10-11

http://anond.hatelabo.jp/20091010235215

IDとかコテハンのない増田では議論しにくいですねorz

多分http://anond.hatelabo.jp/20091010232609

でいっている元増田トラバ元のあなたです。

システムテストに関してはhttp://anond.hatelabo.jp/20091010210506

で書いている通り

その修正が呼び出してる20機能に必要な修正なら、20機能全部でデグレード試験し直しは必要。

1機能にしか影響しなくて他の19機能のロジックを変えたくない(デグレード試験したくない)なら、

共通関数コピペして&修正して、修正が必要な該当1機能は新規にコピペ&修正した関数呼び出す

で、修正が必要な1機能しかデグレード試験しなくてよいと思っています。

私が言いたいのは

どのような共通化を行うか(共通関数をつくるか)内部設計書に宣言させて(して)、

責任者(そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間)とレビューして、

そのプロジェクトではどのような共通化が適切であるか合意をとるべきだということです。

合意とった内部設計書とおりに実装していなければ(勝手に新たな共通化関数つくっていれば)、

実装担当者責任ですし、

そもそも内部設計書に誤りがあれば、

どのような設計が、適切に共通化した設計か判断できる人間責任だと思います。

2009-10-10

http://anond.hatelabo.jp/20091010194703

逆 20機能で同一関数を使っているとその同一関数を1行修正すると20機能全部デグレード試験し直し。

逆に20機能を20関数で使っていると、1つの関数を直しても19機能のデグレード試験は不要。

その修正が呼び出してる20機能に必要な修正なら、20機能全部でデグレード試験し直しは必要。

1機能にしか影響しなくて他の19機能のロジックを変えたくない(デグレード試験したくない)なら、

共通関数コピペして&修正して、修正が必要な該当1機能は新規にコピペ&修正した関数呼び出すではダメなの?

http://anond.hatelabo.jp/20091010180917

逆 20機能で同一関数を使っているとその同一関数を1行修正すると20機能全部デグレード試験し直し。

逆に20機能を20関数で使っていると、1つの関数を直しても19機能のデグレード試験は不要。

よって、機能の共通化は必ずしも、トータルでの工数を減らしたりはしない。どころか、増やしたりもする。

結局、共通化する関数に求められる品質依存。その関数に求められるクオリティーが高い・技術的難易度が高い場合上位者が作って、下位作業者に呼ばせるだけのブラックボックス化したほうが良い。でないと、作れないし、まともな速度が出ないとか、全体が動かない。

とくに、普通関数の場合は、担当者オリジナルで作らせても問題ない。むしろ、オリジナルで作らせておいた方が勉強になるし、上記のように仕様変更による試験工数の影響が少ない。

その辺のバランス取りが設計力。設計力に、こうなるみたいな王道はなくて、チームメンバー他 状況次第の水物。それがわかっていないと、デスマするような無茶な設計したりする。そいうことだと最近思う。

2008-12-06

プロジェクトビルド手順が手動だった。別れたい。

手動でビルドする方式だと、なんか恥ずかしいww

下向いちゃうしww

男にはせめてMakeくらい使って欲しい・・・

ビルド手順すっ飛ばして、デグレード起こしたら・・・・もう最悪ww

せめて普通antrakeぐらいは使って欲しい。

常識的に考えて欲しいだけなんです!

手動のビルド手順を引き継ぐ時の恥ずかしさとか分かる?

あのね?たとえば10??20人ぐらいで徹夜してバグ修正とかするでしょ?

それぞれ修正後のソースコードコミットするわけじゃない?

みんな普通MavenHudsonContinuumCruiseControlとか期待してるわけでしょ?

手動でノコノコビルドしてたら大恥かくでしょうがww

 
ログイン ユーザー登録
ようこそ ゲスト さん