技術選定において「今だったらもうちょっとこう作れたな」というエピソードを教えてください!

技術選定はプロジェクトの成功に大きく影響します。過去のプロジェクトで採用した技術やツールについて、現在の知識や経験をもとに「もし今だったらこのように選定・実装していた」と感じるエピソードや学びがあれば教えてください。具体的な技術名や状況、そしてその時の判断基準と現在の考え方の違いなど、詳しくお聞かせいただけると幸いです。 (編集済み)
2年前
view数 205

    回答を投稿して企業にアピールしましょう!

    Q&Aで投稿された回答は、
    企業側に表示されるプロフィールにも投稿履歴として表示されます。

    Offersにログイン・新規登録して、気になるテーマやトピックを話してみよう!

    \回答があります!/

    • Offers(オファーズ) 公式

      エンジニア

      1年前

      ※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント(https://offers.connpass.com/event/287192/)」における、フリーランスエンジニア 竹端 尚人氏の回答内容を元にしています。

      Javaっぽい書き方がちょっと残ってしまったかなというのは結構ありました。

      MyBatisというJava製のO/Rマッパーを使っていて、フレームワークで自動生成してくれるデータベースのテーブルに紐づいたデータオブジェクトなどが当時はJavaでしか生成できず、そこの部分はJavaで使っていた影響もあります。

      今は同じMyBatisでも対応してKotlinのコードを生成してくれるようになったので、もう少しすっきりかけるかなと思います。
      view数 41
      • takuya327

        エンジニア

        2年前

        技術選定の評価軸が整理されていないと、まず後悔が生まれるでしょう。
        あと、コミュニティが弱いライブラリとかを製品に組み込んでしまうと後悔が生まれやすいと思います。

        たとえば、CoffeeScriptはRailsでもサポートされていたけど、企業のバックアップがなく、ほぼ有志の努力によってのみ開発されていたはず。
        https://github.com/jashkenas/coffeescript/

        こういった技術はどこかで息切れしやすく、ライフサイクルも短くなってしまう。
        ※もともとフロントエンドのライフサイクルは短いけども。

        そのため後悔しないためには、技術選定の評価軸として、その技術はあと何年くらい持ちそうか?という視点が必要ですね。
        view数 49
        • 4
        • 3
      • Offers(オファーズ) 公式

        エンジニア

        2年前

        ※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント(https://offers.connpass.com/event/287192/)」における、Chatwork株式会社 テックリード 加藤 潤一氏の回答内容を元にしています。

        関数型プログラミングになれていない頃はvarを使ったよく手続き型でコードを書いてしまっていました。でも学ぶ段階ではある程度は許容したほうがいいです。今はGithub CopilotもあるのでAIの推薦もうまく使って学べば、効率的だと思います。
        view数 28