概要
特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ15本目
Qiitaまとめシリーズ
- 4年目プログラマが参考にしたQiita記事まとめ⑱
- 3年目プログラマが参考にしたQiita記事まとめ⑰
- 3年目プログラマが参考にしたQiita記事まとめ⑯
- 3年目プログラマが参考にしたQiita記事まとめ⑮
- 3年目プログラマが参考にしたQiita記事まとめ⑭
- 3年目プログラマが参考にしたQiita記事まとめ⑬
- 3年目プログラマが参考にしたQiita記事まとめ⑫
- 3年目プログラマが参考にしたQiita記事まとめ⑪
- 3年目プログラマが参考にしたQiita記事まとめ⑩
- 3年目プログラマが参考にしたQiita記事まとめ⑨
目次
PHPを使いもせずDISってる君達へ
PHPの擁護記事かと思ったらボロクソ行ってて笑えた。と同時に、PHPのドハマリしそうなポイントを抑えることができた。
なぜ仮想DOMという概念が俺達の魂を震えさせるのか
Reactを必死に勉強してた頃に目を通して意味わからなかったけど、今ならそれなりに理解できる。何でReactがここまで成り上がったか、やっぱり仮想DOMの影響が大きいんだと言うことがわかった。今はReactよりVueのほうが使ってるけど、Vueも仮想DOMなのでこの記事の内容はそのまま使うことができる。
ハッシュをソートしてハッシュで返す(Ruby)
痒いところに手が届いた。ハッシュは本来順番を持たない概念だからこういうことをやろうとするのがミスだと思うけど、今のRubyのハッシュは順序をしっかり持ってるので捗る。
フロントエンドエンジニアが暇なときにやると良いかもしれないこと
情報収集が受け見ガチなのでより能動的に情報拾いに行きたいね。少なくとも言われたから調べるとかは辞めたい。
カオスになりがちなCSSと向き合ってみた
あるある。スタイルをABC順で統一するの良いなぁ。自動化できると尚良いけど、組織レベルでやるとしたら何らかの気風が必要そう。ビルドツールでまとめて行えるのが一番いいけど。
最近Webサイトやアプリを使ってイラッとしたUI/UX
SPAはこれが難しいなぁ。しっかりエラー対応付けないと、ブラウザレベルでユーザにエラーの報告してくれないからわけわかんない感じになる。
pry-byebugでrubyをデバッグする
この記事読んでpryデビューした。ずっと素直にirb使ってきたけど、pryは素で便利。もっと早く乗り換えておけばよかった。
[Vue.js] フォームの多重送信を防止する
防止用のボタンをコンポーネントで切り出す考えは良いな。これは率先して使っていきたい。
一つ上のチームメンバーのそだてかた
コーチングは将来役立つものだろうし覚えておくとして、エンジニアのレベルの評価方法は参考になった。紙に書いた適当なスキルシートとか、面談通して口頭でエンジニアのレベルを測れるはずがない。やっぱりエンジニアに求められるのは何よりアウトプット。
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話
テストもだけどレビューに関しても結構振れられててソッチのほうが参考になったりした。
今までのレビュー目的は「バグを減らすため」でしたが、再整理の結果、「知識共有と可読性の検査」へと変わりました。
人のコードを積極的に読まないと知識は偏るし、人に読ませるようにコードを書かないと保守性の悪いコードが生まれる。互いにもっとコードを読み合うような仕組みが合ってしかるべきなんだけど。
今回は、自動テストの狙いを「開発速度を上げること」に絞り、手動動作確認よりも自動テストの方が素早く確認できる箇所にのみ自動テストを導入することに決めました。
誤解されがちだけど、自動テストはコードの品質を高めるとかじゃなく(それもあるけど) 最終的な開発速度を上げることが目的。長期的な視点の場合、テストを書くことで工数が増えるというよりはテストを書くことで工数が減るはず。まともな設計がある前提だろうけど。
まぁ自動テストにしろコードレビューにしろ、コードは疎結合に書こうねというのは共通してる。