SandBoxで開発している時は気づかないけど、本番運用後にエラーになってはじめて気付く制限があります。
SandBoxではデータのサイズ制限があるので、開発時には気付くことはできないという
事情はあります。
でも、事情は関係なしにエラーがでれば不具合扱いなので避けたいところです。
以下に今後気をつけたい制限のメモを３つ程メモしておこうと思います。
ApexClassで、100,000件以上のオブジェクトをインデックス指定無しで検索する
ほぼ開発時には気付きません。データが溜まって初めて気付く制限の典型です。
日付や電話番号は外部IDでインデックス作成ができないのですが、顧客の特定で生年月日や電話番号で検索しがちなので気をつけたいところです。
※日付や電話番号の項目のインデックスは、カスタムインデックスの作成をSalesforce社へ依頼することになります
Visualforceで、<apex:repeat>の繰り返しの上限が1000
SOQLの取得件数は1000以上ですが、Visualforceの画面表示の上限が1000までです。StandardSetControllerや、カスタムでページング処理を使って対処します。
Visualforceのビューステートの制限
このエラーが出た場合、対処は困難を極めます（そもそもある程度大きい件数で多くの項目を入力したいという要件でこのエラーがでます）
表示項目にはtransientを指定したり、入力項目を減らしたり、入力項目の桁数を減らしたり涙ぐましい努力が必要になります。
最初からJavaScriptベースでVisualforceの開発をすることで回避できる可能性がありますが、そこまで戻れないのが実状だと思います。
最後に
バージョンアップで制限も変更となっていくのですが、今時点(Winter18)では以上が気をつけたいなーと感じていることです。
もちろんToo Many SOQLの対処などもありますが、これは発生頻度が高く開発時で気をつけるのが習慣となりつつあります。
昔は、SOQLで、子リレーションの副問合せで取得した子オブジェクトのレコード数の200件まで 制限があった気がしますが、今はなくなってるようです。（気のせいかもしれません）
あと、ガバナ制限ではないですが、ファイルが格納されている、コンテンツバージョン(ContentVersion)オブジェクトは、システム管理者でも全てのレコードを取得できないようになっています。後からAPIで取得したくでもできなくなります。（画面からはすべて参照できます）
なので、コンテンツドキュメントリンク(ContentDocumentLink)にトリガでデータを作成しておくようにしておくと良いと思います。
例えば、トリガで特定のchatterグループに全てのファイルをひもづけておけば、そのchatterグループに管理者をメンバーとすることで管理者は全てのファイルをコンテンツバージョン(ContentVersion)オブジェクトから取得できます。
後で、ContentVersionをAPIで操作する要件が見えているなら、トリガをあらかじめ用意しておくのがいいかなーと思います。
