はじめに
チーム開発未経験から今の会社で働かせてもらって、半年以上が経ちました。
今回はチーム開発未経験者が初めてチームで開発する際に使えるテクニックを紹介します。
実務で開発を始めた人向けの記事となってます。
すでに開発をされている方は、
他にも使えるテクニックをご指摘いただけると幸いです。
ショートカット
Visual Studio Code
Mac OS | Windows OS | コマンド |
---|---|---|
⌘O | Ctrl+O | フォルダーを開く |
Visual Studio Codeを開いた後に有効。
最初の画面でいちいちマウス操作をするのがめんどくさいため使える。
Mac OS | Windows OS | コマンド |
---|---|---|
⌘F | Ctrl+F | 一致する文字の検索 |
実務で一番使うコマンド
基本的には他人が書いたコードをチェックすることになるので、
まずは検索コマンドを使って目星をつけることが多い。
これは、自分一人で実装する時にはあまり使わないが、実務では必須。
Mac OS | Windows OS | コマンド |
---|---|---|
⌘P | Ctrl+P | ファイルの検索 |
似たような使い方ではあるが、こっちはファイルの検索ができる。
開くべきファイルがわかっている場合は、こちらが有効。
Mac OS | Windows OS | コマンド |
---|---|---|
⌘D | Ctrl+D | 同じ文字を探す |
開発時に必要なくなったコードを一括で編集できるため、便利。
場合によっては、何百ものコードを編集することを考えると非常に使える。
その他で使えるショートカット
Mac OS | Windows OS | コマンド |
---|---|---|
⌘Tab or Control+↑ | Alt+Tab | 画面の移動 |
画面の移動もよく使うコマンド。
実務での開発になるとファイルを跨いで開発することが増えるため、
ショートカットキーで移動できると時間短縮につながる。
シェル操作
code .
当該フォルダーをVisual Studio Code上で開ける。
手作業で開くよりも断然早い。
デバッグ方法
こちらの記事を参照してほしい。
おすすめシェル
昔、「出来るエンジニアとそうでないエンジニアを見分けるテクニックは?」
とX界隈で話題になっていました。
自分は、使ってるシェルを聞くのが1番じゃないと思ってる民です。
『Readable Code』を読んでるか聞くのは、
読んでなくても一回は話題になるので、意味ないと思ってます笑
ともあれ、おすすめの個人的におすすめのシェルは fishです。
brewさえ入っていれば、
$ brew install fish
$ curl https://raw.githubusercontent.com/oh-my-fish/oh-my-fish/master/bin/install | fish
$ fish
⋊> ~ omf install z
上記のコマンドを打つとインストールできます。
ついでに、oh my fishをいれてzを使えるようにしています。
zを使えると、ディレクトリ間の移動が楽になります。
⋊> z sample
と押すだけで、ディレクトリを跨いでsampleディレクトリに移動してくれます。
(一度行ったことのあるディレクトリのみですが)
CSS
レスポンシブ対応(スマートフォンでも見れるようにすること)は必須。
px表記で画像や文字の大きさを定義していると、
スマホ版では酷いデザインになっていることもある。
上記はスマホサイトであるのに、広告のサイズがデカすぎてサイトの中身を確認することができない。
このようなことにならないためにも、開発者ツールを使うか、Simulatorを用いてスマホのデザインも確認すべし。
コードについて
学校での課題のように何でもかんでもコメントはするべきではない。
基本的にはコメントがなくても分かるようなコードを心がけるべき。
しかし、コードの欠陥や返ってくるデータ構造がわかりにくい場合、
書いた方がベター。
例:
NG
# ハローワールドを出力している。
printf("Hello World")
OK
# ["ume", "tuna"]のように具材名がリストで返ってきている
printf(Onigiri)
OKコードの場合も、本来は変数名で具材名だとわかるようにするべきだと思います笑
サンプルなので、大目に見てください。
質問
開発作業をし始めた時は分からないことだらけで、質問をしに行く機会が多いでしょう。
しかし、なんでもかんでも聞いていると上司の仕事を止めることになってしまいます。
分からなかった時にはやるべきことがあります。
① エラーを確認
何行目で起こっているのか、どういうエラーなのかくらいは確認する。
例:
Unsupported environment (bad pnpm and/or Node.js version)
Your Node version is incompatible with "/sharp/0.33.2".
Expected version: ^18.17.0 || ^20.3.0 || >=21.0.0
Got: v18.15.0
② エラーの文章を調べてみる。(GPTなどに聞くのもよし)
例の場合は、pnpmかnodeのバージョンが合っていないことを示している。
つまり、開発環境でnode -v | pnpm -v をやってみて、実際と乖離がないのか確認をする必要がある。
この場合は、簡単なエラーだったが、全く関係ない行をエラー対象として出してくる場合もある。
20分考えてもわからない場合は聞きにいくと良い(考える時間は会社やタスクによる)
ここまでやっても全く分からなければ、聞く。
聞く時も、自分なりにエラーの原因を話してみる。
お金を貰って仕事としてやっているため、これくらいはやるべきでしょう。
今後もその他追加していく予定。