思いつくこと
- 人はぱっと見で判断するので、パッと見で変になりそうなことには警戒する
人はぱっと見で判断するので、パッと見で変になりそうなことには警戒する
- 耳栓を切って、見るからに耳栓してます、感を薄れさせる
- 仮に薬指使って食ってたとしても、人のものを汚すと相手に判断されないようにする
等。
鏡で見たりするのも良いかもしれない。 人はパッと見で判断したりもするので(深く考えないで)、パッと見で誤解されないのは大事
また、理論的には大丈夫かもしれないけど、相手に誤解されそうな事は避けるべき。
相手に誤解されないようにするのは大事。
技術について
ベーシックな構築力や理解力、提案力を上げること。 実装には根拠を持たないといけない。
エンジニアは負債を残さないようにプログラムを書いたり、データの永続化をしないといけないので。
仕様はどんどん変更されていく。 色んな形態でアプリを運営していたり、色んな接続端末がAPIを叩いている。
なので、ベーシックな能力は大事。
特に、テーブル設計のような、変えるのが大変で、今は良くても将来困る系は気をつけるべき。
下っ端の仕事 = プログラムの仕様変更や機能追加も大事
テーブルに影響を与えないようなプログラムを書くだけの仕事も大事。 プログラムも、色んなケースを想定して書くべきだし、人が読んで保守するプログラムになるので、リーダブルで保守しやすいものにしないといけない。
- リクエストを1回にして、state等でデータを保持しておく
- 変な処理がないか考える
等。 読み解くのが大変なのは保守するのが大変。
先輩のコード読むの良いかも
先輩の処理読むの勉強なるかも。 今求めている情報と近しいことをやっている処理を見ると勉強なるかも。 他の人はどういう処理書いて解決したか、とか。
梓さんの場合は単純に経験値があったのかも。 経験の中から、近しい処理をやったことがあって、引っ張ってきたのかな？
優先付け
- アルゴリズム構築力(手続型発想だけでなく、必要な部品を作って、くっ付けていく方式)
- テーブル設計の提案力 -> 低い？
- vue or nuxt系？
アルゴリズム構築力(手続型発想だけでなく、必要な部品を作って、くっ付けていく方式)
手続型思考だと、テストが書きにくいコードを書いてしまいがち。 しかし部品思考だと、単体テストは書きやすいし、それを組み合わせて結果を出す、統合テストみたいなのが書きやすくなる。 モデルに紐づいたインスタンスメソッド、みたいな書き方をすると、テストしやすいコードが書ける。
それだと、ロジックを変更する際も、リファクタして動作が壊れていないか簡単にテストできる。
何とかメソッドを呼ぶとどうなるか、をコンソールから確認できて楽。
オブジェクト指向では、データとそれを操作するメソッドを近くに置くことで、色んな箇所に同じようなのが書かれるのを防ぐことができる。
名前でスコープを限定的にすれば、巨大なクラスが出来上がるのを防ぐことができる。
テーブル設計の提案力 -> 低い？
新しい新規機能を作ったり、データ構造の事考える際は役立ちそう。 しかし、データ構造の変更がない系だと出番がない可能性もある。 が、データの作り方の参考になるし、本質的な所だと思う
vue or nuxt系？
ちょっとやって見ても良いかも。 色んなのを試して、機能を使って遊ぶ的な。
compositionが良いけど、2系でも基本を学ばせてくれる系ならokかも
fbc生のやつはパフォーマンスとかは微妙だと思う。 現場の人が作ったプロダクトの方が役立つと思う。
自分がレビュー受けるのが効率良い気がする
