Размер видео: 1280 X 720853 X 480640 X 360
Показать панель управления
Автовоспроизведение
Автоповтор
ソースコードと同期が取れてる設計書があるなんてなんで素晴らしい現場なんだ
今回の動画はめちゃくちゃ優しいし、どのエンジニア転職話より中身ある内容
これが本来あるべき姿だけど、僕はいつも仕様書がない案件やらされたり、仕様書無茶苦茶だからリバースエンジニアリングで書き直してって言われてる。酷いのだとファイルサーバすらない。業務系は仕様書あるとこが多くて、WEB系は作る気ゼロのとこが多い。
理想では解決できない事も多いよね。いつか良い現場にいけますように
それはバグかどうかすらわからんのでは。。。?
うちも、ソースコードが仕様書なんだよなぁ…
@@warokihami ええ。だからクライアントが五月雨に修正依頼出してきますね。仕様書作りましょうって言っても人をアサインしてくれない。書いても読ませようともしない。目先の金にならない無駄な作業と思われてるんですよねー
@@marizotto540 で、あれば工数を金に化かすというのも有りだが、それは交渉できないのか?成功すれば椅子座ってるだけで金を生むから、他事やってれば良い。仕事してるフリで金を稼ぎつつ、腕を研いたり自社開発に動ける。状況わからないからなんとも言えないけど、事業としてやる以上金引っ張ったら正義だし。
どんな新発見あるんだろう!と思ってワクワクしてたら普段やってることばかりだった。どうやら間違いなかったらしい。
オンかバッチかでだいぶ変わってくるような気がします。オンラインだとアベンド(異常終了)となることは基本避けますよね。お客さん(顧客かは知らないが)が触るアプリだとエラーメッセージが出るように事前にプログラミングしておきますね。新規開発だと設計書が後回しになっている場合がありますね。そうなるとソースとログをあてにするわけなんですが...ログの見方もわからない人がテストやっているのはすごく不思議な感じがします。バグレポートくらい現場で書き方用意して書かせて欲しいと思う。
この動画の冒頭のソクラテスみたいな感じがクセになります😊❤
サイクロマティック複雑度、オーバー300 執行モード リーサル エリミネーター 慎重に照準を定め 対象を排除して下さい」とか言いたくなる現場に当たったことあるぞ。300は盛ったけど150はデフォルトで、要件定義は顧客の気分、設計書は過去の異物、コードはini参照する機能ON/OFFが乱舞するスパゲッティ。商用環境で絶賛稼働中。
仕様書が出てこないのに検証させられてるぜさて、仕様書書くか
質問する際は確認した仕様書のパスも添付するのだそしていつの間にか仕様が変わってたことに気づくのだ
unityとかスタックトレースとかちゃんとメッセージ出してくれてるのに、エラー内容読まない人多いよね
純粋に気になるんですけど、何で読まないんでしょうね。
現象、処理、仕様の理解。あと変数のオーバーフロー処理が正しく実装されているかも典型例ですね。16バイトのフィールド長で定義してるのに何故か17バイト以上入力出来ちゃってオーバーフローとか。
低レイヤー言語の話ですかね。Web系だとあまりないような…
ためになる....けどぼっちで働いてない自分には関係ない....
シーケンス図だいきらい……しかし必要なものだし……
この話は経験が足りてない人向けの話でしょうね。手段を目的にしちゃいけませんよ!という当たり前の話ですからね。工業系シーケンス制御の経験者としては「良品をサイクルタイム以内で作る」とはっきりした答えが大前提としてあるから、設計書なんてゴリゴリ変わるのは当たり前。サイクルタイム内で良品を作成できるようになってから設計書があってもいい。それくらい変わる訳で状況によっては仕様書も変わるかもしれませんwですがこういった大前提の答えが無いところ。解りづらい所では仕様書と設計書に従うしか出来ないでしょう。
仕様バグ、設計バグなんてぎょうさんあるけどな。
コード見りゃわかるんだから仕様書書かなくても良いよね?
それだと正解が解らんぞ?まあ正解なんて「金になる」事なんだけども現場でどうすれば金になるかなんて解るもんか?これが工業系のシーケンス制御とかになったらはっきり解るんだけどね。(良品を製造すればいいとなる。これもサイクルタイムの縛りがあるけどw)
ソースコードと同期が取れてる設計書があるなんてなんで素晴らしい現場なんだ
今回の動画はめちゃくちゃ優しいし、どのエンジニア転職話より中身ある内容
これが本来あるべき姿だけど、僕はいつも仕様書がない案件やらされたり、仕様書無茶苦茶だからリバースエンジニアリングで書き直してって言われてる。酷いのだとファイルサーバすらない。業務系は仕様書あるとこが多くて、WEB系は作る気ゼロのとこが多い。
理想では解決できない事も多いよね。
いつか良い現場にいけますように
それはバグかどうかすらわからんのでは。。。?
うちも、ソースコードが仕様書なんだよなぁ…
@@warokihami
ええ。だからクライアントが五月雨に修正依頼出してきますね。仕様書作りましょうって言っても人をアサインしてくれない。書いても読ませようともしない。目先の金にならない無駄な作業と思われてるんですよねー
@@marizotto540 で、あれば工数を金に化かすというのも有りだが、それは交渉できないのか?成功すれば椅子座ってるだけで金を生むから、他事やってれば良い。仕事してるフリで金を稼ぎつつ、腕を研いたり自社開発に動ける。状況わからないからなんとも言えないけど、事業としてやる以上金引っ張ったら正義だし。
どんな新発見あるんだろう!と思ってワクワクしてたら普段やってることばかりだった。どうやら間違いなかったらしい。
オンかバッチかでだいぶ変わってくるような気がします。オンラインだとアベンド(異常終了)となることは基本避けますよね。お客さん(顧客かは知らないが)が触るアプリだとエラーメッセージが出るように事前にプログラミングしておきますね。
新規開発だと設計書が後回しになっている場合がありますね。そうなるとソースとログをあてにするわけなんですが...
ログの見方もわからない人がテストやっているのはすごく不思議な感じがします。バグレポートくらい現場で書き方用意して書かせて欲しいと思う。
この動画の冒頭のソクラテスみたいな感じがクセになります😊❤
サイクロマティック複雑度、オーバー300 執行モード リーサル エリミネーター 慎重に照準を定め 対象を排除して下さい」とか言いたくなる現場に当たったことあるぞ。
300は盛ったけど150はデフォルトで、要件定義は顧客の気分、設計書は過去の異物、コードはini参照する機能ON/OFFが乱舞するスパゲッティ。商用環境で絶賛稼働中。
仕様書が出てこないのに検証させられてるぜ
さて、仕様書書くか
質問する際は確認した仕様書のパスも添付するのだ
そしていつの間にか仕様が変わってたことに気づくのだ
unityとかスタックトレースとかちゃんとメッセージ出してくれてるのに、エラー内容読まない人多いよね
純粋に気になるんですけど、何で読まないんでしょうね。
現象、処理、仕様の理解。あと変数のオーバーフロー処理が正しく実装されているかも典型例ですね。16バイトのフィールド長で定義してるのに何故か17バイト以上入力出来ちゃってオーバーフローとか。
低レイヤー言語の話ですかね。Web系だとあまりないような…
ためになる....けどぼっちで働いてない自分には関係ない....
シーケンス図だいきらい……
しかし必要なものだし……
この話は経験が足りてない人向けの話でしょうね。
手段を目的にしちゃいけませんよ!という当たり前の話ですからね。
工業系シーケンス制御の経験者としては「良品をサイクルタイム以内で作る」とはっきりした答えが大前提としてあるから、設計書なんてゴリゴリ変わるのは当たり前。サイクルタイム内で良品を作成できるようになってから設計書があってもいい。
それくらい変わる訳で状況によっては仕様書も変わるかもしれませんw
ですがこういった大前提の答えが無いところ。解りづらい所では仕様書と設計書に従うしか出来ないでしょう。
仕様バグ、設計バグなんてぎょうさんあるけどな。
コード見りゃわかるんだから仕様書書かなくても良いよね?
それだと正解が解らんぞ?
まあ正解なんて「金になる」事なんだけども現場でどうすれば金になるかなんて解るもんか?
これが工業系のシーケンス制御とかになったらはっきり解るんだけどね。
(良品を製造すればいいとなる。これもサイクルタイムの縛りがあるけどw)