完璧なコーディング規約を定めて、メンバー全員がその規約に忠実に従っていれば、プロジェクトのコードは無駄の無い美しいものになるでしょうか？ 必ずしもそうとは言えません。むしろ、厳しすぎるコーディング規約は逆効果になってしまう場合もあります。 そもそも、コーディング規約は美しいコードを書くためのものではありません。 プロジェクトのメンバーというのは通常、経験年数も育ってきた環境も最初に覚えた言語もバラバラです。 そのような集団がそれぞれ自分の書きやすい書き方でコーディングを進めたら、同じプロジェクト内、下手をすると同じファイル内でも全然違う書き方が混在してしまいます。 コーディング規約というのは、メンバー間のコードの差異をできるだけ無くし、プロジェクト全体の統一感を出すために必要不可欠なものです。 キャメル記法を使う、メソッド名は動詞から始める、インデントは半角スペース4文字、etc… では、
よくごっちゃになってしまうので、Java と C# の命名規約をざっとまとめてみました。 種類JavaC#(.NET) クラスPascalPascal インタフェースPascal （例：List）"I" + Pascal （例：IList） パッケージ / ネームスペースCamel （例：java.net）Pascal （例：System.Net） メソッドCamel （例：toString()）Pascal （例：ToString()） ローカル変数CamelCamel メンバ変数Camel （例：Calendar.isTime）Pascal （例：Calendar.IsReadOnly） 定数Snake （例：Integer.MAX_VALUE）Pascal （例：Int32.MaxValue） 列挙定数Snake （例：State.RUNNABLE）Pascal （例：ThreadS
qsonaです。今回はコードを安全にこの世から抹消していく の実践編ということで、7,600行のコードを削減してデプロイした話を書きます。 7,626行削減しているPull Request経緯「ランキング」のマイクロサービスを作った話 でも登場した、ランキングサービスでの話です。APIは一度リニューアルし最新はv2でした。 その後、新しい形のランキングを実装することになり、同時に、いままであった形式のランキングはなくなり、リプレイスされることになりました。そのため、新規の実装をするとともに、新しくバージョンを上げてv3のAPIを新設することにしました。 コアなロジックやデータストアにアクセスするコードについては、大部分を使い回すことができ、無事に本番リリースを行いました。 一方で、古いランキングはもう開催しないため、v2以下のAPIやそれに紐づくコードは実質的に不要になりました。そのコード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く