Semantic Versioningの闇 - knqyf263's blog
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約（と可能なら余談）だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"（>= 2.1.3みたいなやつ）の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
19歳で転職した私が気づいた、すれ違わないチーム開発をするために必要なこと - SMARTCAMP Engineer Blog
こんにちは！！！スマートキャンプ、エンジニアの吉永です。 私は8月にスマートキャンプに中途入社し、今月で3ヶ月目となります。 前職では受託開発を主にした小さな企業に未経験で入社し、そこで一年間フロントエンド、バックエンド問わず開発したり、テックリードのような業務も行ったりしていました。 小さな会社なので部署というような区切りはほぼ無く、社長含め全てのメンバーがエンジニアといったようなエンジニア集団の環境で、日々開発タスクをこなしていました。 しかしある時期をきっかけに、外部の方と協力する機会が増え、エンジニアだけがいる環境から様々な人間が関わる環境へと変わっていき、とあるプロジェクトを進めている最中、私達エンジニアサイドと、企画サイド、デザイナーサイドでうまく噛み合わず、スケジュールが大幅に遅れてしまいました。 そして、このことをきっかけに私自身がエンジニア以外の人間に対して苦手意識を持っ
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
