リクエストにお応えします。
「一般的なのか?」という質問には、「その通り」と答えます。ただし、「業界の悪い慣習」だとも思います。
引き受ける前から『工数が莫大になる割に予算が少ない』というプロジェクトは様々な分野であります。要領の良い会社やエンジニアはそういうプロジェクトから逃げ回ります。他者に弱みを握られているような立場の弱い会社が押し付けられるパターンが多いですね。しかも押し付ける側は、プロジェクトの問題点についてはわざと黙っています。
俗に言う「貧乏くじをひかされる」状態です。
一般的だと思います。。
ユニットテストをどのくらい入れ込むか、はたまた、E2Eテストをどこまで入れるか、クラスから関数コンポーネントにどう置き換えるのか、
なかなか楽しい考え事が多くてやりがいありそうじゃないですか！
経験値をたくさん積み重ね、腕が上がれば工数は減らせるはずだし、
また、工数がかかる事、予測がうまくいくかどうかわからないけど金を出せ、という事を周囲に納得させるのもビジネススキルをあげますよね。
ピンチな状況にはチャンスがあるので、頑張ってください。
やりこなしたとしても誰も認めてくれないかもしれませんが、自分の自信はつきます。
また、やりこなせなくても、もとから困難なんだから、まあ、仕方ないわけですし。
あ、そういえば、reactのレンダリングのユニットテスト、enzymeとかテスティングライブラリとか、なんかは、自明なものも多いので、必要ないと思いますよ。storyBook くらいは載せてからリファクタリングするのがよいと思うけど。
そういう加減も経験値つむとよいんでは？
知らんけど。
まかされた保守の内容にもよります。現状機能を維持する為のサポートを定額／月で請負い、修正や機能追加に関しては個別に見積りを提示して対処するというので有れば、今の会社でとある業者さんと推進しようとしている内容なので有り得ます。現状オンプレミスなので、近々クラウドに移行してオンラインメンテナンスを容易にする段取りで現在進行中です。この手の契約は割と良くある内容で、特に中小規模 SIer がしっかりとした社内 SE の存在しない企業に対してよく行っています。併せてハードウェア保守契約も取り交わす事が一般的です。
お問い合わせ内容から見ると、他社（者）が作成したものが対象だと思われますので、改修等に関してははっきりとサポート対象か対象外かを明示しておく方が、双方にとって良い関係が構築できます。一定の期間を経過させる間に業務概要を把握し、最終的にユニット・テスト等の必要なものを追加する提案を有償で取り交わす事は可能だと思いますが、ユーザー目線からするとテスト環境を構築する為に費用が発生するというのは決済出来ないと思います。
ユニット・テストが実装されていないシステムはテスト用プロジェクトを複製し、実際に動かしつつ動作確認が取れますが、コーディングの癖が読めた段階でコード・リーディングして処理を追っかける事が割と容易に出来る様になります。演算エラー発生時等には割と効率的に対応が出来ます。可能ならば
… (もっと読む)低予算あるある。
しくじったら、首になる、あるある。
私はしくじって、首になりました。
一般的ではない筈です！一般的であってほしくない！
所謂、炎上プロジェクト、要救助の現場です。満足しない報酬であれば、あなたは搾り取られます。工数が概算できれば、洗い出した詳細なタスクを報告したほうが良さそうです。解決できるか出来ないかは別にして、優先度が高いタスクで相応の報酬は確保しましょう。難易度が高いタスクは諦めましょう。学習コストもあります。
炎上案件は実態を絶対に説明しないです。完了できそうにないであれば、延長してもらいますか、やるしかないです。やらなければクビになります。仮に成功してもあなたの有能さが嫉妬されて手柄横領、社内政治、責任転嫁でクビされます。もしくは成果を上げて、結局、前任者と同じ理由で転職してしまいます。企業のやらかしニュースを見ればわかります。どの会社でも同じですが、一般的に都合の悪いニュースは公開しないです。蓋を開けて中身を見て初めて分かります。会社組織は奴隷を搾り取る仕組みです。
- simpleでありeasyではない
- イノベーターであり続け、優れた人材、ツールやエコシステムを作る人材含め惹きつけ続けた。
- UIライブラリに徹し、機能が厳選され、陳腐化しやすい機能が本体に組み込まなかった。これは判断として一番でかい。
- 実用に徹した。登場前の最初から一貫してバトルテステッドだった。関数型プログラミング信奉者の説伏に耐え、複雑さを抑え、実用性を常に優先した。
- hooksを讃えよ！
- 後方互換性がとても大事にされた。関連し、コンポーネント単位の再利用性がちゃんとあるし多数流通している。
- 独自テンプレート構文がないので、最新ES仕様やTS仕様に常に追随できる。(JSXはBabelとTypeScript側の標準機能になっているし、なんとなればJSXは使用しなくてもいい)
- 最新版TSとその強力な静的型の恩恵をvscodeの補完含めて最大限享受できる。
参考：
やはり会社としては「コスト」が気になりますね。
vueを習得するのに1週間必要な場合、1週間 x 人数 のコストが必要になります。
そのコストをかけるだけの価値があるか？というのを会社はまず考えます。
ですので貴方がすべきことは「それだけのコストを払っても会社にメリットがある」ことを熱弁するべきだったのです。
「君以外メンテできなくなる」と言われて引き下がるのではなく、みんながvueを使えるようになることのメリットや、vueを採用した場合のメリットなどを熱く語るのです。
魂から声を絞り出して会社に話すのです。
あなたはまだ話しただけで具体的なものを提示出来ていないだけで、これからの進め方次第ではいくらでもvueを採用させるルートがあるのです。
道のりは険しいかもしれませんが、プログラムをやっているといつかは通る道です。
これはチャンスです。
むしろコーディングより上のことを学んで実践するまたとない機会なのです。
あなたのプログラム人生が良い方向へ進むことを祈っています。
質問者さん自身の経験値が上がったためです。
名前だけ見ての、完全な当てずっぽうですが・・・（笑）
JSONを介さない、旧来のバックエンドとの親和性を高めるためのものではないでしょうか？
Djangoで標準的なバックエンドを構築すると、Formオブジェクトを扱ってサーバー側バリデーションやCRUDなどを処理する方法になると思いますが、その場合フロント側からFormを流し込んでほしいという要求になるように思います。
全くの的外れだったら、ごめんなさい（笑）
一人で続けるという前提であれば、React Native版、Flutter版どちらもとりあえず試してみて、イケると自分で判断した方を採用するというのはいかがですか？
Reactに明るいのであればReact Nativeは少なくともFlutterより近い技術でしょう。Flutterは独自技術だけあってイチから覚える必要はありますが、覚えた後はOSのUIにも引っ張られない自由があります。
プログラミング言語で考えた場合JavaScript、さらにTypeScriptでガリガリコード書いていると、Dartは昔のJavaっぽくて時代遅れと感じてしまうかもしれません。Dart側はそれは狙ってやっていて、UI向けに進化させているのだと主張しています。
Optimized for UI
- Mature and complete async-await for user interfaces containing event-driven code, paired with isolate-based concurrency
- A programming language optimized for building user interfaces with features such as the spread operator for expanding collections, and collection if for customizing UI for each platform
- A programming language that is easy to learn, with a familiar syntax
私は過去にこんな回答をしているぐらいなのでFlutter推しです。
ReactではなくFlutterを選択する理由は何ですか？に対するDaisuke Sawadaさんの回答
でも一人ですべて決められるなら、自分で試すのが一番だと思います。
そのコンポーネント集をオープンにしてはいかがでしょうか？全てとは言わず、半分程度でも。
有益なフィードバックが得られると思います。
0 件のコメント:
コメントを投稿