「優先順位」「優先順位」「優先順位」「優先順位」、もう「耳タコ」ですね（笑）
「プログラムもバッチリ」「データベースもバッチリ」「ドキュメントもバッチリ」「何もかもバッチリ」、
うん「不可能」ですね。
なので、以下の記事を参考にして、ちょっと考えてみようかなと。
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
あと、↑の記事を引用している、以下の記事も。
あと、以下の大事な前提ですね。
以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。
どうせ新規事業なんてほとんど当たらないんだから。
これなんですが、「いや、この事業は普通"じゃない"ので、気にしなくて良い」と考えていそうな方（目標が現実離れしている）に対しては、
「競合の有無」のお話をすれば良いと思いますね。認識しているのか、調べていないのか。
競合がいない（か少ない）んなら、普通"じゃない"も説得力が出てくるので、
↓に書く優先順位の、少なくとも下の方については、無視してもあまり問題にならないと思いますのでね。
だから、競合不在（真似したくても出来ないなら尚更）って、考えている以上に「強い」と思いますよ。
という所で、そろそろ本題に入りたいと思います。
上の、２つの記事を読んだ上で、というかそうじゃないなら読まない方が良いと思いますね。
あと、優先順位を決める基準として、
下に書いてある事を「しなかった」時に起きる問題を考えてみると良いのではないかと思いますね。
１．システムが動くコードを書く
これをしなければ・・・何も成立しないですね。
なので、問答無用で１番上。
２．パフォーマンスチューニングをする
３．セキュリティ対策をする
これは、やらなかった時に起きる内容によって、前後するかなと。
パフォーマンスだと、「動くけど、１分以上レスポンスまで時間がかかる」だと、流石にでしょうし、
「２０秒→３秒」ぐらいのチューニングでも、優先的にやった方が良いでしょうし。
でも、「３秒→２秒」とかぐらいなら、やらなくても問題にならない可能性が高くなるので、
それなら、優先順位を下げても良いと思いますね。
あと、どうしても時間がかかる処理もありますが、どれだけ長くても・・・「５秒」以内ぐらいじゃないですかね。
「１処理で沢山の処理をしない様に分ける」ってのも、一つの考え方ですが。
セキュリティは、対策しなかった時に「"任意"のスクリプト（or コマンド or SQL）実行」がどうかと。
任意って、「そのスクリプト言語（or コマンド or SQL）で出来る事なら、"何でも"」なんですが、怖くないんですかね。
逆に、任意じゃないのだとCSRF（存在する機能の悪用なので）ですが、いやCSRFをしなくて良いという意味ではなくね。
あと、脆弱性によりますが、CSRFやファイルアップロードのファイルの中身のチェックの様に、
対策が、１００％は不可能（か極めて困難）なケースもあり、
そういう時に、例えば対策率を９５→９９％にするのに、異常に時間をかけるのは？とは思いますね。
「時間」って書いている以上、実装者に依存するので、すぐ出来るならした方が良いわけですが。
１００％に中々ならない一例として、CSRFだと推測困難とはいえ「トークンが"偶然"一致する」可能性があるので、
トークンのチェックに「加えて」、パスワードも入力してもらう。
でも、パスワードも「"偶然"一致する」可能性があるので、
CAPTCHAのチェックも追加する。
でも、CAPTCHAも「"偶然"一致する」可能性があるので、
二段階認証も追加する。
でも、二段階認証も「端末が盗まれる」可能性があるので、
指紋認証（誤検知しないか、人によって"絶対に"指紋が異なるのなら１００％？）もする・・・
「オンラインバンキングの送金」とかでも、ここまでするかレベルな気もしますが、
中々、１００％にするのは大変ですね。
ファイルの中身の方も、関数１本で殆ど検出は出来るわけですが、
あれ、ホントに１００％になります？
「同じxlsファイルじゃないのか？」ってのを、過去に見た事があるので。
ただ、だからといって、ここでギャンブル脳全開？で、
「１００％にならないなら、０％と一緒」としてしまうのはどう見てもなので、
「重要な処理"毎"」にセキュリティレベルを決めておけば良いと思いますね。
「送金はガチガチに対策だけど、ログアウトは何もしなくて良いや」とか。
セキュリティは、方程式じゃないですが、
「事故が起きる確率」×「事故の際の想定被害額」とか出来ればとは思うんですが、
数値化が困難なのがねぇ・・・出来たら天才でしょうけど。
４．綺麗なコードを書く
強いて言えば４番目なんですが、
でも、綺麗なコードにしなければ、↑の２と３をするのに時間がかかるという話も。
どこまで綺麗にするんだい？ってのは、
クラス設計だと、「親クラスの充実」が最優先かと。
だから、以下なんかは良いと思いますしね。
CakePHP3のbakeによるコード自動生成のプラクティス - Qiita
子クラスは、その子クラスに「しかない」処理とかは、
そんなにムキにならなくてもとは思いますね。
綺麗に「しなかった」時でも、その子クラス「しか」問題にならないわけですし。
逆に、親を綺麗にしてないと・・・ですね。
要するに、共通化なわけですが、これ「だけ」でも「全然違う」ので、最低限ならコレじゃないですかね。
あと、テーブル設計ですが、プログラム以上に「リファクタが大変」と思うので、
少なくとも、↑の子クラスの処理を綺麗にするよりは優先した方が良いと思いますね。
いや、むしろ全般的に、こっちの方が優先かも。
で、テーブルについても色々と考えられますが、
「主キーの決め方が雑」、正確には「どの単位で"一意"にしたいの？」って所でしょうか。
ユーザーテーブルというのがあったとして、
「連番の数値のユーザーIDで一意」
「システム側で自動発行した文字列のユーザーIDで一意」
「メールアドレスで一意」とか、候補キーが色々考えられるわけで。
あと、複合主キーに多いんですが、カラムAとBで一意になるとして、
「カラムAが1で、カラムBが1」、「カラムAが1で、カラムBが2」って当然入るんですが、
これが想定通りか？複合主キーが３つ以上じゃないと、あまり間違えないかもしれないですけどね。
あと、「過去データは入らない」と思っていたテーブルが、「過去データも入る」となると、
場合によっては「１件取得の所を、複数件取得に変更」する必要がありますね。
なので、「このテーブルは、履歴テーブルなの？そうじゃないの？」って所ですが、
そのテーブルの「性格（という言い方を思い付いただけですが）」を決めるのも大事だと思いますね。
「命名」や「データ型」や「制約」とか、他にも色々あるわけですが、
まず、どういうデータ（これは間違えないと思いますが）が、
どういう形で入るテーブルなのかって所が、やらなかった時に一番大変じゃないかと。
５．定数を整備する
６．コメントを書く
７．テストケースを書く
この３つ辺りで、また前後する様に思いますね。
で、定数は↑の綺麗なコードに入れても良いのですが、
定数って、処理と違って「移動が簡単」なので、
少し下げても良いのではと。
特に「エラーメッセージ」なんかは。
ただ、過去に消費税率の数値が「0.08」とか「8」とかで散逸していたケースもあったので、
「移動するのに、手間がかからない定数かどうか？」で検討してみるのが良いんじゃないかと。
コメントも、例えば「isset」と「array_key_exists」を、
やりたいことに応じて、適切に使い分けられれば「コメント不要」と思いますけどね。
え？ダメですか？
ただ、「何で、SQLで書かずに、プログラムで処理しようとしてるの？」みたいなコードには、
「パフォーマンスの為、プログラムで処理している」とかは書いた方が良いと思いますけど。
テストケースは・・・テストコードじゃないけど、排他制御のコードはテスト目的で書いたりしますけどね。
いや、画面の操作じゃテストしにくい（出来ない）ですし。
なので、「複雑な処理」の方が優先ですかね。
８．ログ出力するコードを書く
９．例外処理を整備する
１０．エラーページを整備する
１１．コードレビューをする
この辺でまた、前後する感じですかね。
「いや、ログは無いと、運用が大変」なのは確かですが、
でも↑の７つをしなかったのに比べれば・・・
全く書かないというよりは、
「ログ・例外処理・エラーページ」って、仕様が「決まってないか無い」ケースが殆どだったりするので、
「決まっていない所に、異常に時間をかけるのは」ってニュアンスの方が強いですけどね。
決まっているなら、「サッと書いて終了」で良いわけですし。
コードレビューは、この記事の前のダイジェストにも書かれてますが。
↑の記事の、特に「文脈によるレビュー内容の変化」ですかね。
だから、レビュイーは、
「こういう機能なので、この辺を重点的にお願いします」
って感じで依頼すれば良いんじゃないですかね。
１２．会議をする
これは作業じゃないわけですが、
なんか、会議が「多過ぎる or 少な過ぎる」ケースがあるので、
最低限だと、２週間に１回以上は、とは思いますね。
会議の内容は、まさにこの記事の各項目について話をすれば良いんじゃないですかね。
もう少し正確だと、「複数人がいないと出来ない」内容について会議で話をすると。
といっても、チャットで済むケースもあるので、
この辺はコミュニケーションデザイン（プロジェクトによって変わる）を構築するのが先だと思いますけど。
１３．ドキュメントを書く
「なんで、一番下なんだよ！一番上に決まってるだろうが！」ってのは極端としても、
ドキュメントが「無い」時に、↑の項目に比べて起きる問題が上回るかどうか？
とすると、「例外処理を作り込まない」よりも「ドキュメントが"全く"無い」方がマズいってケースもあり得るので、
どうしても、多少は前後もしちゃうもんですけどね。
ドキュメントは、
「そのドキュメントは、リバースが出来るかどうか」
「書く内容は、重要な処理かどうか」
って辺りがポイントなんじゃないかと思いますね。
なので、考察元の以下の内容も、
「内部の処理フローもリバース出来るなら、ドキュメント化しても良いのでは」と思いますけどね。
必要なの？と聞かれたら、う～んですけど（笑）
ただし、APIインターフェース/データベーススキーマ/認証フロー 等は最低限書いておくのを勧める。ここで言ってるのは、内部の処理フローを完全に書くとかそういうレベルの話だ。ドキュメントは100点を求めようとすると途端に運用上のコスパが悪くなる。最低限書くべきことを決めて、50点でもいいから運用可能なレベルで妥協すること。
認証フローも、「重要」だから書いておいた方がって事じゃないですかね。
リバースといえば、APIインターフェースは、そういうツールって・・・あぁ「Swagger」ね。
「大変」というのだけ覚えてるので、ホントに大変なのかって所でしょうかね。
１４．おまけ
雑談をする
帰る前に話す
なんだこりゃですが（笑）
これらは、「しなかった時に、どういう問題が起きるか」と言われても困るわけで（笑）
「雑談をする」については、急に文脈が変わってしまいますが、一つの指針としては、以下がありますかね。
ぞろぞろみんなでうろつくことない uh…
わざわざ知らん顔することもないB'z drive to MY WORLD 歌詞
http://j-lyric.net/artist/a00067d/l000d42.html
だから、「毎日、きちんと挨拶をしましょう！」と言われても「軍隊？」って思うので違和感感じますし、
だからといって、わざわざ知らん顔しなくても良いのでは？って思いますね。
「帰る前に話す」は「帰る」とあるので常駐前提なのですが、こちらも同じですね。
別に、ルール化する必要など全くないと思いますし。
こんな所でしょうか。
そもそも、項目自体が不足しているかもしれないですが、
どうやら、こうして書いてみると、
最初に書いた「しなかった時に、どういう問題が起きるか」ってアプローチで、
比較的スムーズに決めれそうに思いますね。
