新しいまたは非標準のソリューションを作成するとき、アーキテクト/開発者は通常、与えられた制約を考慮して、彼が望むものと必要なものとの間の妥協点を見つけます。そして、最終的に期待されたことを実行しなかったり、最適なソリューションから遠く離れたりする可能性は常にあります。
そして、「最善を望んでいたが、いつものように判明した」ということが、説明されていない要件や変更された要件のために発生した場合、少なくともこれは説明できます。しかし、時々老婆に穴が開いて、目のかすみやファッショナブルなテクノロジーの実際の使用の落とし穴のために、子供の間違いを見逃すのは面倒になります。
そして、そのようなエラーの可能性を最小限に抑えるために、多くの企業では、新しい大規模プロジェクトの直接開発を開始する前に、アーキテクチャソリューションを保護する慣行があります。これは、会議、アーキテクチャのレビュー、または単なる喫煙室のディスカッションとして編成できます。それはすべて、スタッフの構造と会社の規模、および設定された開発プロセスに依存します。
しかし、会社に1人または2人の開発者がいる場合、または彼らの経験が提案されたソリューションの専門家による評価に十分でない場合はどうすればよいでしょうか。それとも、他の人の困難を掘り下げる時間や欲求が不足しているだけですか？
知識のある人から本当の助けを得ることができるプラットフォームとしてHabrを使用することについて話していることをすでに推測しているでしょう。
確かに、パブリックコメントを通じて素晴らしいフィードバックを得ることができます。さらに、Habrの記事を書くことは、建築委員会で防衛の準備をするよりもはるかに簡単で便利です。メインプロセスから人々を連れ去ることができる日時について合意する必要はありません。そして、詳細の議論に参加できるようにするために、それらをすぐにコンテキストに含める必要はありません。
「やがて」大企業の建築委員会の仕事に参加する機会がありました。そして、各会議の終了後の気持ちは常に2つありました。一方では、新しい経験としばしば本当の助けを得るのは素晴らしいことです。しかし、一見ささいな問題についての通常の議論が口頭での戦いに変わり、その反響が数日後に達したということも起こりました。
特に、使用するコンポーネントの統合プロセスに参加した経験を覚えています。 1つの小さなライブラリのインターフェイスと実装を調整するのに1年半以上かかり、実装全体を何度か完全に書き直す必要がありました。その結果、すべての消費者を満足させるようなコードを使用可能な状態にするために多くの無駄な時間が費やされ、そのようなことをもう一度やりたいという欲求が完全に燃え尽きました。
この点で、Habréに関する記事は、会社が複雑な問題の議論を組織する能力を欠いている場合に、理想的な選択肢になります。そして最も重要なことは、記事のディスカッション中にどのような解決策やアドバイスを受け取ったとしても、誰もあなたにそれらに従うように強制することはありません！