翻訳者のための序文 この記事を読んだ後、あなたは驚いたり、怒ったりするかもしれません。 はい、私たちも驚きました。著者はおそらくチーム内の階層について、「理由を付けずにすぐに実行する」というステータスのタスクを設定することについて聞いたことがなかったと思われます。 はい、そうです、これは少し奇妙なテキストです。 実際、著者はプログラマーがシステムアーキテクトの役割を担うことを提案しています。では、なぜアーキテクトが必要なのでしょうか? しかし、これらすべての反論によって、重要な点が見えなくなるべきではありません。それにもかかわらず、なぜ私たちがこのテキストを取り上げて翻訳したのかということです。 彼は役割について話しているのではありません。 このテキストは専門的なアプローチと意識について書かれています。 実は、自分の行動の意味を考えずに「言われたことだけをやっている」限り、優秀なプログラマーにはなれないのです。
不要なコードには「ノー」と言いましょう。 あなたがしなければならないのは、XNUMXつの文字を組み合わせて単語を言うことだけです。 一緒にこれをやってみましょう：「いやー！」
ちょっと待って。 なぜこれを行うのでしょうか? 結局のところ、プログラマーの主な仕事はコードを書くことです。 しかし、要求されたコードを記述する必要はありますか? いいえ！ 「いつコードを書いてはいけないかを理解することは、おそらくプログラマーにとって最も重要なスキルです。」 .
リマインダー： 「Habr」のすべての読者が対象 - 「Habr」プロモーション コードを使用してスキルボックス コースに登録すると 10 ルーブルの割引。
スキルボックスは次のことを推奨します。 実践コース .
プログラミングは問題解決の技術です。 そしてあなたはこの芸術の達人です。
私たちは、できるだけ早く仕事を始めようとして、目の前のタスクを完了すること以外何も考えないことがあります。 そして、これはさらに深刻な問題を引き起こす可能性があります。
プログラマーは何に目をつぶっているのでしょうか?
作成するコードはすべて、他の開発者が理解できるものでなければならず、テストおよびデバッグする必要があります。
しかし、問題があります。何を書いても、ソフトウェアが複雑になり、将来バグが発生する可能性があります。
リッチ・スクレント氏によれば、 。 彼は次のように書いています。
「コードが悪いのは、腐り始めており、定期的なメンテナンスが必要だからです。 新しい機能を追加するには、古いコードの変更が必要になることがよくあります。 値が大きいほど、エラーが発生する可能性が高くなり、コンパイルに時間がかかります。 別の開発者がそれを理解するにはさらに時間がかかります。 また、リファクタリングが必要な場合は、変更する価値のあるフラグメントが必ず存在します。 コードが大きくなると、多くの場合、プロジェクトの柔軟性と機能が低下します。 シンプルで洗練されたソリューションは、複雑なコードよりも高速です。」
コードを書いてはいけない場合をどうやって判断するのでしょうか?
問題は、プログラマーがアプリケーションに必要な機能の数を誇張することが多いことです。 その結果、コードの多くのセクションが未完成のままになったり、誰も使用しなくなったりして、アプリケーションが複雑になってしまいます。
プロジェクトに何が必要で何が不要かを明確に理解する必要があります。
例としては、電子メールの管理という XNUMX つのタスクだけを解決するアプリケーションがあります。 この目的のために、レターの送信と受信という XNUMX つの機能が導入されました。 メールマネージャーが同時にタスクマネージャーになることを期待すべきではありません。
アプリケーションの主要なタスクに関係のない機能を追加する提案には、断固として「ノー」と言う必要があります。 これはまさに、追加のコードが必要ないことが明らかになる瞬間です。
アプリケーションの焦点を決して失わないでください。
常に自分自身に問いかけてください:
――これから実装すべき機能は何でしょうか？
— どのようなコードを書けばよいでしょうか?
頭に浮かんだアイデアに疑問を持ち、外部からの提案を評価します。 そうしないと、余分なコードによってプロジェクトが強制終了される可能性があります。
不必要なものを追加すべきでない場合を知ることは、コード ベースをしっかりと管理するのに役立ちます。
パスの先頭には、プログラマが XNUMX つまたは XNUMX つのソース ファイルしかありません。 それは簡単です。 アプリケーションのコンパイルと起動には、最小限の時間がかかります。 どこで何を探すべきかは常に明確です。
アプリケーションが拡張するにつれて、より多くのコード ファイルが表示されます。 これらはカタログを埋め尽くし、それぞれが数百行あります。 これらすべてを正しく整理するには、追加のディレクトリを作成する必要があります。 同時に、どの機能が何に関与しているのか、またどのアクションがその原因となっているのかを思い出すことはますます困難になってきています。 虫の捕獲にも時間がかかります。 プロジェクト管理もますます複雑になっており、すべてを追跡するには XNUMX 人ではなく複数の開発者が必要になります。 したがって、金銭的にも時間的にもコストが増加し、開発プロセスが遅くなります。
プロジェクトは最終的に大規模になり、新しい機能を追加するたびにますます多くの労力がかかります。 たとえ非常に重要でないものであっても、数時間を費やさなければなりません。 既存のエラーを修正すると新たなエラーが発生し、アプリケーションのリリース期限を過ぎてしまいます。
今、私たちはプロジェクトの存続のために戦わなければなりません。 なぜ？
実際のところ、あなたは単にコードを追加すべきでない場合を理解しておらず、すべての提案やアイデアに「はい」と答えていたのです。 あなたは盲目で、新しいものを作りたいという欲求が重要な事実を無視させていました。
ホラー映画の脚本のように聞こえますよね？
あなたが「はい」と言い続けると、まさにこれが起こります。 どのような場合にコードを追加すべきではないかを理解するようにしてください。 プロジェクトから不要なものを削除します。これにより、作業が大幅に楽になり、アプリケーションの寿命が長くなります。
「最も生産的な日の 1000 つは、XNUMX 行のコードを削除したときです。」
— ケン・トンプソン。
いつコードを書いてはいけないかを知るのは難しいです。 しかし、それは必要なことなのです。
はい、あなたは開発者の道を歩み始めたばかりで、コードを書きたいと考えています。 良いことです。第一印象を失わないでください。しかし、熱意のせいで重要な要素を見失わないでください。 すべては試行錯誤の末に実現しました。 また、間違いを犯し、そこから学ぶこともあります。 しかし、上記のことから学ぶことができれば、あなたの仕事はより意識的になるでしょう。
創作を続けますが、いつ断るべきかを知ってください。
スキルボックスは次のことを推奨します。
- オンラインコースの申し込み .
- オンラインコース .
- 実践一年コース .
出所： habr.com