  |
はてなキーワード:リグレッションとは
IEEEがコードレビューに関する論文を出していて、それを読む限りではコードレビューはバグの検出にはそれほど効果がないとのことでした。
（品質の維持／向上やレビュー者間へのシステム理解速度に対して好影響を与えているとのこと）
過去システムリリース時や変更時にテストケースが記録されていないことによる不完全なリグレッションテストが行われていることやシステムの仕様を誰も管理出来ていないことが問題なので、増田自身には問題はなかったんだがね。
失敗しちゃったからそういうところをしっかりやっていきましょうと言って組織を引っ張っていけるぐらい図太くなれればよかったんだけど…
学歴がよくなくて、就職が困難だったので中小SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力してもAtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) →PM (御用聞き) →プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果のWBS に合わせないと、顧客からDM で瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していないWBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事がDM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて24/365 で停止しないWebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事でmalloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊なPCI Express のカードからベンダーが用意しているSDK でデータ引っこ抜いてWebAPI へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。SQL を直書きするのはシンドイ。
結局SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外はフレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript でPrisma 使うのが、型安全でよさそうだなと思っている。
デプロイをEC2 直でやったりECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング,Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今はGithub Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由でAzure Pipelines でCI/CDフローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline がGUIからしか設定できないのが辛みだった。
これを知らずに、コンソールでポチポチしていたので、IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
最初は腹抱えて笑ってたけど、ふと周りを見たら笑えなくなった。
多分、分かってる技術者もいっぱい居たと思うんだけど、複数の企業とか絡んでて仕様変更出来なかったんじゃないかと思う。
上司、自部門、自社トップ、他社、セブンのシステム子会社、セブン本体・・・俺だったら絶対何もしない。中途半端に対策案とか出してこのカオスに何回も相手に合わせた説明資料作ってとかできない。
これで間に合わなかったら分かってて対策案出さなかったとかで責められるのが目に見えてるからだ。
セキュリティって簡単に見つかったりするくせに直そうとするととんでもなく苦労する。仕様変更だからリグレッションテストとか発生する。その工数誰が出すんだ。保守費でよろしく。いや、想定外に高くなります。そんなの仕様が書いたおたくが悪いんでしょ・・・
日本じゃ金出した奴が偉いんだ。お客様は神様です。フランチャイズだけは金を取ってる方が偉いけどな。
はっきり言うと、ちゃんとしたベンダーじゃない限りIDを使ったサービスなんて自前でしない方が良い。個人情報を扱うならなおさらだ。
どうしろと？firebase使えよ。
