バックエンドやってる期間が長くて「まあ基本こんなAPIあればフロントどうにかなるやろ？」という第六感(？？？)が働いてバックエンドのコードはスッラスラ書けるけど、フロントエンドは実は全部デザインが反映されたコードにAPIだったりtRPCを後でぶち込むくらいのことしかやったことがないので、vimを前に唖然としてしまう。
それもそのはず、サイトが取るべき大体のノード構造は把握できるけどどうすれば上手く見せられるかが謎。そして、サイトの見た目と挙動を同時に考えて一気にフロントを実装するとなると流石に俺の浮世離れしたスーパー脳みそでもどうにもならない。
※エンジニアの活きる知恵:
他の人に話すときも、自分でコードを書くときも基本的に自分は「圧倒的な才能と知能を持っている」って考えよう。異世界転生してきたチート主人公に自分を重ねて、それでもブチ当たる壁だと考えれば、自分のやっていることが常人には出来ないことだということに気づく。
実際、そうである。みんなは地獄から這い上がってきた鬼畜(狂人としても良い。実際、私を含めた経営陣は皆バケモノとしか言いようが無い)を上司に抱えているので、普通に取り掛かろうとしたら絶望する内容であるのは決まってる。
そこでみんなが正気を保ちながら生きるためには、うまく仕事をこなす為の工夫をすることが必要になる。私達が振った仕事をそのままコードにするなんて到底不可能なのである。
プログラム書き始めたばかりの社員にもアドバイスしたのでみんなにもアドバイスすると、「コード書けないな、と思ったらまずなんのコードを書けばいいかわかるまでペンを握って振られた仕事を処理可能なステップに分けて見ると良い」。またさらに言うと、僕の机の隣に置いてある本を何でもいいから手にとって見てパーッと見てみたり、公式のドキュメンテーションをラテでも飲みながらゆっくり読んでみると良い。そこに答えはないけど、答えにたどり着くヒントはどこかに隠されていることが多い。
ここに書いた知恵を活かすと、まずすべきなのは 「フロントエンドをどうするか決める」ことである。
ここに関しては天才デザイナーマンがfigmaを丁寧に作ってくれてるので、どうやるかはさておき終わったことにする。詳しくは彼に聞いてくれ。俺は一生figmaイジるのに時間を使いたくない。
次は「フロントエンドに関する決定に基づいて適当にノード構造をはっきりさせておく」ことだ。
IDEはエラーを吐きまくるけど、コンポーネントなども後で実装するつもりでとりあえず「こんな感じのコンポーネント入れるだろうな」というガバガバの想定でいいし、もはやインポート先も架空のものでいいのでとりあえず書いておく。こうしてると、とりあえずコンポーネントで何を実装しないといけないのかがハッキリわかるし、そこになんのロジックを組むかもだいたいこの時点でよく分かってくる。無論ここでUIデザインを参考にして「多分ここらへんにdiv置いて箱みたいなの書くんだろうな」
次は「とりあえず今の時点で分かってる挙動やロジックなどをデザイン無視で実装」する。
デザインなんてのは正直後付でいいものだ。テストを回すときも結局挙動やロジックがしっかりしてればエラー出ないし、実装環境で何かがバグることも少なぐなる。
最後に「見た目を良くする」である。
この作業は基本、マジでダルい。というのも私はあくまでエンジニアであり、顧客に便利なサービスを提供したいという動機はあってもその見た目がいいとかどうでもいいのである。一体誰が見た目の良さを必要としているのか知らないけど、流石に阿部寛みたいな見た目のプロダクトを顧客に納品したくはない。ただし、逆に何が良いのかもわからないのでかなり行き詰まると思う。逆にこういうの向いているフロントエンドのことやりたがる人に任せればいいと思います。
とりあえずこんな感じに分けて、今は「ノード構造をはっきりさせておく」作業に取り掛かろうかな。今日はそれを終わらせることをゴールにしよう
※エンジニアの活きる知恵:
毎日ダラダラコード書いていてもつまらないので、「今日はここまでやる」というのを決めてそれを時間内にクリアできるかどうかを考えてからタスクに取り組むといい。「とりあえずやればいっか」ではなんとなく退勤時に虚無感をすごい感じることになるので、あまりおすすめではない。
毎日「今日はオフィスに行ってこれを終わらせるんだ！」とはっきりとオフィスに来る自分の動機づけがしっかりしていると、退勤時がめちゃくちゃ気持がいい。というか、僕はその達成感があまりに好きなのでプライベートそっちのけで友達との予定をブッチしても目標達成に動く。逆にその達成感を感じてしまうと「今日は終わり！！！」ってなるのでそこからは働かないし、もう一つ目標を設定してそれを達成できるほどの時間がないと判断したらすぐ帰ってしまうことが多い。毎日働いていく中で自分がどれくらいの作業を一日でこなせるのか、現実的な目標設定はどんな感じになるかを（もはや感覚ベースでいいので）掴んでいこう。プロジェクトマネジメントやプリセールスに必須な「第六感」だよね。 プロジェクトの見積もりの席にいても、紙さえあれば大体自分一人で実装して何がどれくらいで終わるか、チームに任せたら自分がやるよりもどれくらいの時間がかかるかが分かってくるのでとても仕事が楽になる。