yuri memo

コーディングとかのメモ帳

React を理解するだけではなく、自分の役割を理解することが重要だった転職1年目

フロントエンドエンジニアに転職してあと数日で1年経ちます。
この1年間はすごくあっという間でした。
7割くらいは初めてのことだった気がします。
以下は思い出せる限りで雑めな初めてリストです。

  • GitHub(個人では使ってましたが仕事では初めて)
  • レビューする/される
  • Zeplin
  • Storybook
  • React
  • React + TypeScript
  • jest
  • LTで話す
  • 英語でコミット/PR

英語は最初すごい時間かかって悲惨でした。
今は一旦雰囲気で書いて Google 翻訳して調整して、という流れにも慣れて多少マシになりました。(かかる時間が)
英語がマトモかどうかは自信ないです。でも抵抗は少なくなりました。

この1年で1番多く書いたのは JSX かな?という気がします。あと CSS かな。
React 触る時期が2回あって、1回目のはあまり記憶が定着してないです。
それですっかりリセットされて2回目。
これは、書けるようになる日が来るのか...?という心境でなんとか書いてました。
教えてもらってもすんなり理解できない時も多々あり...
一応形にしてから、もっとマトモに書きたいんですけど。。ってレビューしてもらいたいのに、そこにすら辿り着けないとか。
自力で解決するのも必要なんだけど、時間を超使ってしまったらそれはプロジェクトの進捗的にどうなの?という気持ちとか。
どう進めたらいいの?とかもいろいろ悩んだなぁと。

まぁこのあたりは過程で、どうしてくのが良さそう?ってなった時に、
“自分ができるタスクを着実にこなしていく” ことが必要だと教えていただきました。
書ける・書けないの前に。

  • できる・できないを見極める
  • 最小の単位までタスクを分解する
  • 自分のできる範囲で成果を出す
  • できないことはできる人にお願いする・相談する

自分はこのプロジェクトでどういう成果を出すべきか?どの部分で貢献できるのか? を考える必要があったんですね。
この話をしてからは考え方もシンプルになって、まずはできることを着実にやっていこう。という気持ちで取り組めました。
これ、「え?そんなの当たり前じゃない?それ考えないで仕事できんの?」って思う人もいるかもしれません。
今でこそ、そういうの考える必要あるよねって思いますが、当時は書ける気がしない、、分からない、、のプレッシャーで考える余地もなかったです。
とにかく目の前のことで精一杯!
そんな時だからこそ、一度冷静になって整理するというのはとても重要だったなと思います。

今ではなにかと「自分のできることを着実にこなす」と心の中で唱えながらやっています。
まずはそれができてから、できないこと・できるようになりたいことにチャレンジしていく。
少しづつできることを増やしていくのが次の1年の目標かなと思います。

あと、記事メンテナンスしてなくて大変申し訳ないです。今度ちゃんとします。

ちょうど良い場所が茨城にはある - スダ シュウゴ

※ この記事は スダ Advent Calendar 2017 - Adventar 12日目の記事です。
普段の内容とは異なりますがご容赦ください。

f:id:yurixxx8:20171212201713j:plain

スダさんとの出会いは2016年のWordCamp Tokyo
当時、スダさんはフリーランスになって3ヶ月目くらいでした。
Twitterやブログではユニークなキャラクターで、なにかと注目されがちなスダさん。
ですが、会ってみると「意外と真面目な人・・?」と思った方もたくさんいるのではないでしょうか。
今回はそんなスダさんに、仕事のことやこれからのことなどをインタビューしてきました。

ところで、スダさんって誰よ?何してる人?と疑問に思われた方は、
コソアドデザインについて | コソアドデザイン|茨城県日立市のホームページ制作・出張カメラマンD.A.LOG » ウエキバチくんと考える「ともだち」のこと をご一読ください。

続きを読む

GitとGitHub初心者が最初にメモしたこと

f:id:yurixxx8:20170918234801j:plain

初心者の気持ちを忘れる前に一旦メモっ。

Gitとは

一言で雑に言うとバージョン管理システムです。
変更を記録してくれて、その変更履歴を管理できます。
変更の記録・管理ができると「この前の状態に戻したい」という事が簡単にできたり、「どれが最新のファイル・・?」といった事が減ります。
誰が・いつ・どのファイルの・どこを・どのように変更したかが分かります。

GitHubとは

GitHubとは、Gitをさらに便利に使うためのwebサービスの1つです。
私は最初GitとGitHubの違いってなんなの?となったのですが、最終的に「リモートリポジトリの置き場+プルリクエスト(PR)やIssuesが使える便利なやつ」という解釈をしました。

これに関しては検索すると記事がいろいろ出てきますが、まだ触った事ない人は実際にやってみると更に理解できるかと思います。

参考:
エンジニア必須の知識! GitとGitHubの違いとは? | Webデザイン・Webデザイナースクール

GUIでもCUIでも使える

Gitを使うときは主にコマンドラインツール、いわゆる黒い画面を使います。
が、SourceTreeなどを使ってマウスでポチポチすることもできます。
コマンドラインツールを使うと勉強にもなりますが、普段から触っていないと敷居が高く感じられるかもしれません。
私も最初はSourceTreeを使っていました。
(最近になってコマンドラインから操作し始めました)

よく使うワード一覧

GitやGitHubを使い始めると以下のワードがよく出てきます。
一度に全部理解するのは無理なので、最初のうちは「そういうのがある」くらいに思ってました。

[ branch ]
履歴を枝分かれさせて記録する機能

[ clone ]
リモートリポジトリの複製を自分のPCにダウンロードし、ローカルリポジトリとする

[ Hunk ]
編集個所の一つのこと

[ fetch ]
リモートリポジトリに関する情報を更新

[ merge ]
ローカルの状態を、取得した最新のリモートリポジトリの状態に合わせる(統合)

[ pull ]
fetchとmergeを合わせた操作

[ origin ]
リモートリポジトリの場所(URL)の別名

[ master ]
リモートリポジトリのブランチの名前

[ checkout ]
作業対象となるブランチ(コミット)を切り替える

参考:
Gitが、おもしろいほどわかる基本の使い方33

複数人での開発

複数人での開発時に気をつけるポイントを上げてみました。

  • 作業開始時点で必ずプルするように習慣づける
  • プッシュする前にもプルする

この2つは主にコンフリクトの発生率を下げるために気をつけています。
コンフリクトについては後述します。

  • マージ済みや、不要になったブランチは削除する

作業が完了してマージしているにもかかわらず、そのブランチを削除せずにそのまま置いておくのはあまりよくありません。
削除せずにブランチが増え続けると、全体の見通しが悪くなり、混乱の元となります。

コンフリクトについてざっくり話すと

  • Aさんがmain.jsの28行目を変更し、コミット→プル→プッシュまで完了
  • Bさんもほぼ同時に作業しており、Aさんと同じくmain.jsの28行目を変更
  • Bさんがコミットしプルしようとしますが、エラーが起きてしまう

同じファイル(main.js)の同じ行(28行目)を修正しているため、どちらの変更が正しい変更なのかGitでは判断できず、コンフリクト(変更の衝突)が起こります。
コンフリクトが発生した場合は手動で修正する必要があります。

極力コンフリクトを回避するために、作業開始時にプル→作業→コミット→プル→プッシュを心がけています。

参考:
git mergeでの競合(コンフリクト)の解決方法のまとめ。 | WWWクリエイターズ

プルリクエス

プルリクエスト(PR、プルリクとも言います)とは、自分の行った変更について他の作業者(レビュワー)に、
「コードをこのように変更しました。コードレビューをお願いします。」というリクエストを出すことです。
他の作業者にコードレビューをしてもらうことで、見落としていたミスを修正できたり、「こういう書き方もできるけど、どうかな?」とアドバイスをもらえたりします。
このようなコミュニケーションが、ソースコードのクオリティアップに繋がります。

参考:
GitHubでのプルリクエスト活用方法まとめ - ICS MEDIA

コミットするときのポイント

これは私が実際にいただいたアドバイスですが、

コミットログの並びを見るだけで、ある程度環境構築の手順を再現できる(もしくはかつて何をやっていたかが分かる)

ということを意識してコミットすると、cherry-pickでコミットの流用がしやすくなったり、他の作業者はもちろん、自分で後から見返した時にも分かりやすくなります。

cherry-pickとは、他ブランチの特定コミットのみを反映することができるコマンドです。

例えば、ちょっと雑な例ですがこんな感じでしょうか。

  • 環境構築に必要なファイルの追加

↓ 前述のことを意識してコミットすると

  • node-version の指定
  • .gitignore の作成
  • package.json の作成
  • css-loader, node-sass の追加

”環境構築に必要なファイル” だけでは、どこまでの環境構築?なにが入れてあるの?となってしまいますが、分けてコミットすることで、ある程度何が行われたかが分かります。

ソースコードはもちろん、コミットログも自分や他の作業者が理解しやすいよう心がける事が大切だと学びました。

Gitを使い始めた頃はいまいちピンとこなくて、記事をたくさん読んだり本を買ったりしましたが、使えば使うほど便利だなぁと感じています。
これから入門するのであれば、[わかばちゃんと学ぶ Git使い方入門]や[Gitが、おもしろいほどわかる基本の使い方33]などがいいかもしれません。
どちらも書籍です。

またメモが溜まったらブログにまとめます。