競技プログラミングの強みと「典型力」について - chokudaiのブログ
「典型問題」という言葉。競技プログラミングにおいて、皆さん絶対聞いたことがある単語だと思います。少し長くやっている人であれば「典型とか言われているけど全然わからない」みたいなことも、よくあるんじゃないでしょうか？ そこで、今回は、「典型問題って何なのか？」みたいな話を、ちょっとしっかり書いていこうかな、と思います。 誰もが「典型問題」と疑わない問題について 例えば、こんな問題が出たら、誰もが「典型問題」という言うでしょう。 N個の地点があり、M本の道路で結ばれている。各道路には、反対側の地点に行くためにかかる時間が与えられている。 A地点からB地点に行くまでの時間を出力しなさい。 これは、最短経路問題そのままですし、ダイクストラ法などのアルゴリズムをそのまま適用して解くことのできる問題です。これが、一番分かりやすい典型問題です。 まとめ：「名前をついているアルゴリズムをそのまま実装」が、一
14-コードレビュー - やさしいデスマーチ
「プログラマが知るべき97のこと」の14個目のエピソードは、コードレビューに関する話です。コードレビューの目的は「コードの品質を上げ、欠陥を減らすため」と考えがちですが、それと同じ程度に「チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立すること」が大切であると書かれています。 残念な事に、誰もがコードレビューが重要なことを理解している一方で、適切な形で開発プロセスにコードレビューが組み込まれているケースは希です。全コードをレビューしたとしても、バグが発生した時の言い訳にはなりますが、非常に時間を使うことになり通常は費用対効果は低くなります*1。また、レビューを組み込まなければ、各プログラマが好き勝手に実装することになります。それはそれで１つのスタイルかもしれませんが、コーディングスタイルを揃えて可読性を高める事はできませんし、経験の浅いプログラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.google.com/url?sa=t&rct=j&source=web&q=&url=https://dev.classmethod.jp/etc/3-reasons-we-love-aws/&usg=AOvVaw2U5KFxDghntfxSO8vPkgDK
