すべてのプログラマは#TAYに分類されます

匿名の開発者が、Netologia向けに、プログラマーとは何か、彼らはどうなるのか、そしてすべてのプログラマーが自分のタイに入る理由についての記事を書きました。 もちろん、読み取り可能なコードを記述することを条件とします。







プログラマーになるのは簡単だと思うなら、あなたは間違っています。 難しいと思うなら、あなたも間違っています。 だから、誰がプログラマーなのか、クールなコードを書く方法、そしてタイで良いトーンと悪いトーンを区別するもの、またはそれなしで匿名で対処します。

プログラマーが生まれる

誰が言っても、人がプログラミング言語を習得する前に、潜在的に優秀なプログラマーを特定することができます。 プログラマーは、まず第一に、非標準的で柔軟な思考を持つ人であり、プログラミング言語を習得することは時間の問題です。



特定の会社のチームを集めるとき、私はしばしば、その人が彼にどんな知識をもたらすかではなく、その人の考え方に正確に依存していました。 一連の知識の一部は、ソフトウェア製品のニーズ、技術スタック、および機能に基づいて、チーム内で伝達されると想定されていました。 考え方を決定する方法 かつてインタビューで私に尋ねたいくつかの問題の例を挙げ、その後私は尋ねました。



あなたが自分自身をテストしたり、インタビューで尋ねられた質問のパレットを広げたいなら、私はそれらが役に立つと思う。 結局、これらの各タスクは、「分解」、「アルゴリズムのエラーとループの検索」、「単純な要素で操作する能力」、「抽象的思考」など、専門家を選択するための個々の重要な基準を決定する方法です。



1. 2つの変数AとBがあります。A= 7、B = 8であると想像してください。これらの変数の値は、古典数学のみを使用して場所を入れ替えてください。 3番目の変数は使用できません。また、既知のプログラミング言語の関数を使用することもできません。 古典数学のみを適用するようにしてください。 そして、はい、ソリューションはプライベートであってはならず、どんな数字でも動作するはずです。



2.あなたが世界のある地点に立っていると想像してください。 手にコンパスがあります。 私はあなたに言います：「北東へ行きなさい。」 あなたの旅は、実際には無期限に続くことができますが、特定のポイントで終了します。



3. 2つの煙突掃除人がパイプから出てきます。 逆説的なように、一方にはきれいな顔があり、もう一方には汚れた顔があります。 どちらを洗うのですか？ この問題に対する唯一の解決策はないことを知っておくことが重要です-いくつかの解決策があります。 そして、それらのそれぞれは正当化することができ、正当化されるべきです。



4.古典的な問題「オオカミ、ヤギ、キャベツ」。 非常に簡単なタスクですが、本当に気に入っています。 こんな感じです。 あなたは船頭です、あなたは反対側に上記のオブジェクトを輸送する必要があります。 しかし、いくつかの条件があります。 ボートに複数のオブジェクトを持ち込むことはできません。また、オオカミとヤギを一緒に残すことはできません。 どうぞ！



5.あなたは科学者です。 これは非常に危険な種類のバクテリアがあるペトリ皿です。 バクテリアの数は2回ごとに増加していることを知っています。 12時になると、この非常に活発な種類のバクテリアでカップが完全に満たされることを確信しており、急ぐ必要があります。 質問に答えてください：カップはいつ半分になりますか（または、好きなように半分は空になりますか）？



6.丸めのタスク。 小売業で働く企業向けのシステムを開発しているとします。 彼らのモットーは「ノーセント」です。 しかし、私たちの仕事は、数十ルーブルに丸めるのではなく、50ルーブルに丸めることです。 つまり、130ルーブルは150ルーブルで丸められ、115ルーブルは100ルーブルで丸められます。 この原理で丸める方法は？



*回答は記事の最後に書きます。 今のところ考えてみてください。

どこへ、どこへ

プログラミング言語の選択は完全にあなた次第です。 しかし、Web開発について話しているので、 フロントエンドとバック エンドの選択を検討します。



それでもまだわからない場合は、簡単な言葉で言えば、フロントエンドはWebリソース、ユーザーインターフェイス、およびリソースの技術的な部分との対話のレバーに表示されるものです。 そして、バックエンドは、ユーザーとしては決して見えないものです。



フロントエンドは、あなたがいるウェブリソースのロジックの全力を隠します。 車を例にとると、フロントエンドは車の内部であり、バックエンドはボンネットやスキンの下に隠れているものです。 もちろん、ロジックのほとんどがフロントエンド開発者の肩に正確に置かれているリソースがあります。 ただし、ほとんどのWebリソースでは、バックエンドがロジックを担当しています。



あなたがどちらの側の力を取るべきかの選択に直面しているなら、私はあなたが開発の両方の面で自分自身を試すことを勧めます。



「タッチ」し、すでにあなたの心に近いものを決定すると、多分あなたは両側で高品質のコードを書くことができるジェネラリストになるでしょう。 ところで、私はあなたと私の観察を共有します。 多くの場合、バックエンド部分を書く人はフロントエンドも書くことができます。 ただし、このルールが逆方向に機能することはほとんどありません。



フロントエンド開発者の大勢を怒らせたくありません-これは単なる個人的な観察です。 また、バックエンドの開発は常にウェブリソースに関連しているわけではないことを理解することが重要です。多くの場合、モバイルアプリケーションや高度に専門化されたさまざまなサービスに隠れています。

練習のヒント

あなたがまだ開発者になることに決めた場合、私はあなたと私の経験からいくつかの観察、間違いといくつかの物語を共有したいと思います。



症候群「ナターシャ・ロストフ」



この定義は、プログラマーの日常生活についてのジョークがインターネットに登場したときに私のサークルに現れました。



「あなたが作家であり、プロジェクト「戦争と平和」を支援していると想像してください。 あなたはTKを持っています-ナターシャ・ロストワが雨の中で公園を歩いた方法に関する章を書きます。 あなたは「雨が降っていた」と書いて保存すると、エラーメッセージが飛び出します：「ナターシャ・ロストヴァは死にました。継続は不可能です。」 なぜ彼女は死んだのですか？ あなたは理解し始めます。 ピエール・ベズホフのつるつるした靴、彼は転落し、銃は地面にぶつかってポールを撃ち、柱からの弾丸はナターシャに跳ね返ったことがわかりました。 どうする 銃をアイドル状態に充電しますか？ 靴を交換しますか？ 柱を取り外すことにしました。 「ルジェフスキー中Liが死亡しました。」というメッセージが表示されます。 次の章では、彼はもはやポールに傾いていることがわかります...



この話のポイントは何ですか、理解できたと思います。 システムのいくつかの新しいブロックを設計するとき、または古いブロックを編集するときは、正しい結論を引き出すことが重要です-より前向きに考え、あなたの改訂がもたらす可能性のある結果の包括的な研究に時間を費やすことを怠らないでください。 あなたは言う、これにはテスターがいます、そして、そのような失敗を見つけることは彼らの仕事です。 はい、その通りですが、微妙な違いがあります。



金融取引が行われるリソースをホット編集し、テスターがあなたと同じようにあなたの仕事を扱ったと想像してください。 リソースのユーザーである会社は金銭的損失のリスクがあり、これらの損失の理由はあなたです。 私の個人的な例では、開発者がIM（オンラインストア）で割引を導入した場合がありましたが、彼に知られている1つの理由で、彼はそれを逆にしました。つまり、製品の割引は5％ではなく95％でした。 当然のことながら、エラーをすぐに発見して修正しましたが、もっとひどいものだったかもしれません。



危険な世界



コードを設計するとき、および/またはプロジェクトの開発チームの会議に参加するときは、プロジェクトが敵対的な環境にあると事前に考えてみてください。 そして、それを使用する人の中には、あなたのプロジェクトを壊そうとするか、そこからデータを引き出そうとする人がいます。 前のケースと同様に、私は自分の練習からいくつかの例を挙げます。



かつて、私たちにBitrix 1Cを積極的に課そうとしているマネージャーが私たちの会社に来ました（コンピューター用語でAIDSである理由についての議論をスキップし、私たちの会社に入れるべきではありません）。 このマネージャーは大きなプレゼンテーションを行い、デモサーバーに行くために特別なユーザー名とパスワードが与えられました。



マネージャーは、それが健全な製品であるというガイドを耳にすりこみましたが、新しい製品を追加し、その説明にJSスクリプトへのリンクを含めました。 そして1分後、私たちは皆、製品カタログのページで蛇を演奏しました。 私はそこで止めず、すぐにJSスクリプトを作成しました。数分後に彼にBitrixへのログインを強制し、ユーザー名とパスワードを受け取りました。



もちろん、この後、プレゼンテーションは最終的にイライラし、非常に思慮深い表情のマネージャーはなくなりました。 当然、その後、会社の経営者は、製品の説明に埋め込まれたそのようなスクリプトの1つが、ユーザーがデータを盗み、当社に多大な損害を与える可能性があるという疑問を提起しました。



同様の状況は、請負会社が私たちの地域の医療機関に導入する予定の製品のプレゼンテーションでもありました。 プレゼンテーションには保健大臣のみが出席し、結果は請負業者にとって悲しいものでした。プロジェクトは非常に長い間やり直さなければなりませんでした。



したがって、いつでもそのような穴に遭遇する可能性があるという事実に備えてください。 httpsと言いますか 安全な接続？ 私を信じて、この種の悪用質問の価格は、システム全体で少なくともいくつかの修正を行うことができる人への賄briの価格です（タイトルのテキストの通常の編集でさえ）、結果は予測できません。



ゼロで割らないでください、若いパダワン



多くの場合、プログラマは、開発されたシステムが動作するときにサーバーが生成するエラーログの詳細な分析を無視します。 「まあ、通知と警告は害を及ぼさない」と言う人もいれば、間違っている人もいます。 各通知または警告では、インタープリターがエラーログに書き込む必要があるためです。 したがって、1つのエラーのみを生成するサイクルがあり、このサイクルで400回の反復がある場合、そのようなサイクルを1回「回す」とログに50キロバイトのゴミが発生し、さらにスクリプトの実行時間の約3分の1がかかります。



経験からの例：ある情報システムには多くの分析レポートが含まれていましたが、そのうちの1つでは、ゼロで除算できる操作があり、このエラーを排除し、レポートの生成を数倍高速化しました。 また、マルチユーザーシステムがあるとしますか？ この場合、エラーログファイルの外観は判断の対象となります。恐れて、発生するすべてのエラーを常に修正してください。



あなたの兄弟のようなgitが大好き



最初の日から、バージョン管理システムを使用します。 これは、すべてではないにしても、適切で正しいプログラマの99％が使用する重要なスキルです。 制御システムはたくさんあります-選択はあなた次第です。 理解すべき主なことは、非常に良い習慣です。 バージョン管理システムを使用する能力の重要性を説明する写真があるのも不思議ではありません。





「火災の場合：フィードして実行します。」



私の経験では、GitHubとHerokuの2つのシステムに決めました。 前者が非常に有名な場合、後者はほとんど知られていない。 主な利点は次のとおりです。無料のプロジェクトプライバシーとプロジェクトへの一意のhttpsリンク。 ところで、Telegramボット用のWebhookを開発する際の非常にクールなソリューション。



JSONの友達



開発のどちらの側面をとったかは関係ありません。データを転送するときにJSONを使用してみてください。 ポジティブな感情以外は何も得られない作品から、非常に便利で便利なもの。



あなたが大規模なWebプロジェクトのバックエンド開発者である場合、小さな兄弟（フロントエンド開発者）にJSON形式のデータを提供することを考える必要があります。



また、フロントエンド開発者がランダムにデータを提供する場合は、この形式を使用するように彼に教えてください。 私の経験を信じてください。これにより多くの問題が軽減され、フロントとエンジン間のデータ転送がより柔軟になります。



オードjQuery



おそらくjQueryは、フロントエンド開発者にとって最も有名で人気のあるライブラリです。 多くのライブラリが無視され、ライブラリなしで動作する場合、jQueryはあなたの忠実なツールです。 jQueryで書かれたものはすべて純粋なJSで書くことができると言って、誰かが私に反対するかもしれません。 これは本当に頭痛からあなたを救い、あなたの問題の多くを解決します。 これはJSライブラリの世界では「スイスナイフ」であり、多くの人がこれに同意するでしょう。



フレームワークとOOPについて一言



OOP-オブジェクト指向プログラミング。 開発者の進化の非常に正確で必要なコンポーネント。 そして、進化がチェーン全体に沿ってあなたを導くことを覚悟してください：純粋な手続き型→機能型→オブジェクト型、このチェーンの最初または途中で停止すると、業界は生きていない生き物としてあなたを破壊します。 しかし、初心者と経験豊富な開発者の両方が考慮すべき点が1つあります。OOPは必要な場合に適切です。



私の実践では、どのような状況でも、この分野で知識を活用しようとする同僚に何度も会いました。 以下に簡単な例を示します。 サポートされている情報システムの1つに、会社のアプリケーションのユーザーにPUSH通知を送信するモジュールがありました。 したがって、7000ユーザーの場合、手続き型コードは5〜6分で配布を行いました。コードがイデオロギー上の理由でOOPに書き換えられたとき、配布には10〜15分かかりました。



私たちの多くは外国語を知っていますが、どんな状況でも外国語を話しません。 必要なときにだけ話します。 このルールは、OOPとプロジェクトのフレームワークの選択の両方で機能します。 これらを無視することは不可能です。どちらも特定の状況で特定の問題を解決するように設計されており、不必要に使用する必要はありません。



私はすでに、フレームワーク愛好家の巨大な軍隊がホリバーを手配したいという欲求から燃え上がっていると感じています。 落ち着いてください、これは悪いことではなく、必要でもないとは言わなかったので、すべてがその場所にあると言いました。 また、フレームワークを使用しない高品質のテンプレートプログラミングの経験は非常に高価であり、その重さは最新のラインを知ることとまったく同じです。 そして、私自身の経験から、次のフレームワークになる可能性のある小さな修正を加えたプロジェクトに繰り返し出会ったことがあります。



繰り返しになりますが、開発者の進化的開発におけるこの重要なポイントを要約すると、次のようになります。



OOPとフレームワークの高品質な使用方法を学習します-これは重要ですが、どこでも、特に実際には必要ない場合は、それらを使用する必要はないことを覚えておいてください。



良いツールキットを持っている



プログラマは、技術専門家と同様に、特定の問題を解決するのに役立つ優れたツールのセットを持っている必要があります。 これは、コードを記述するIDEと、データベースで管理するDBManagerの両方に適用されます。 さまざまな開発ツールの長所と短所のトピックについて延々と議論することができます。したがって、この場合、私は私の経験に依存します。



PHPで開発するための最も優れたIDEはPhpStormであり、それらのほとんどはおそらくそれに精通しており、これまでのところ、私は自分の手でこれ以上良いものを持っていません。 そして、SQLデータベースでの作業で見た中で最高ののはHeidiSQLです。 ここで、喘鳴まで議論する準備ができています。 データベースにリモート接続する機会がある場合-phpMyAdminを永遠に忘れて、そこで行うすべてのことを5分かけて、HeidiSQLで1分でできます。



さまざまな種類のユーティリティツールについては、ここですべての専門家が時間の経過とともに独自のパレットを取得します。 上記では、ほとんどの専門家が使用する基本セットのみを推奨しました。 もう一度、私はあなたが私と議論したいという願望を持っていたのを見ます。 答えます。



スペシャリストは、慣れているものだけでなく、時間、神経、体力を節約できるものも使用する必要があることを理解することが重要です。



すべてコメントする



同僚によるコードの分析を大幅に簡素化するか、しばらくしてからこのコードを見るとメモリを高速化するため、コードのほぼすべての部分にコメントすることに慣れてください。 これは非常に正しい習慣であり、最初の日から開発する必要があります。 私のためにすべてを言う素晴らしい写真があります。



もちろん、常にプロジェクトに取り組むとは限らないことを念頭に置いておく必要があります。そのため、読み取り可能なコードは優れていますが、コメントの形でフォロワーの良いトーンを忘れてはなりません。

なぜ＃THAI？

短くて明確。 そして悪。 これは私が自分自身に言うことです。 または自分自身に。 プログラマは、テラリウムの条件を必要とする「動物」です。 それらを人工的に作成する方法はたくさんあります。 「バルマーピーク」、グーグル、そしてはい、これはドーピング刺激因子であり、グーグルのようなイデオロギーインキュベーターで終わると思います。 その中で、開発者は会社に住んでおり、したがって、定期的に「コーディング攻撃」に陥り、適切なタイミングで適切な場所にいることに気づきます。 そして、これは会社に非常に高い効率をもたらします。



しかし、他の畜産と同様に、無料の牧草地にある動物からより多くの利益を得ることができ、私にとっては、タイはこれに非常に適した場所です。 私はそこに行って現在この暑い国で働いている多くの同僚を知っています。 そしてその中でも、私も。



人事マネージャーや企業幹部の誰かがこの記事を読んだ場合、10〜18のオフィスに座っているプログラマーは人為的に低い効率のプログラマーです。



私の実務では、会社の所有者の1人がこれを理解し、プログラマは10から14で働いていました。オフィスで時間がかかるときではありません。 しかし、これは私の意見と私の練習からの経験です。 たぶんあなたの場合、あなたは10から19までの蒸し暑いモスクワのオフィスが好きです。これはあなたの選択です。



プログラマーを愛し、それらの世話をしてください。そうすれば、あなたの会社はより良い製品を受け取り、「Huyak-huyak and production」のような練習はなくなります。

記事の冒頭の質問への回答

1.多くの人は、学校や大学の数学コースでこのタスクを覚えています。 2つの解決策があり、それらは非常に簡単です。 A = 7、B =8。3番目の変数なしで値を交換するには、何らかの方法で現在の値の「メモリ」を保存する必要があります。これにより、加算または減算が可能になります。



最初の反復：A = A + B（7 + 8 = 15）、A = 15、B =8。2番目の反復：B = A-B（15-8 = 7）、B = 7。 A =15。3番目の反復：A = A-B（15-7 = 8）、A = 8、B = 7。 乗算と除算を使用しても同じことができます。



2.このタスクでは、地球はテーブル上の平らな地図ではなく、球形の幾何学的図形であることを理解することが重要です。 次に、この球体の主要なポイントを比fig的にマークします。 私たちはコンパスを取り、道を行きます。 コンパスに沿って北東方向にのみ進むと、遅かれ早かれ北極点に到達します。これが問題の状態で示された旅の終点になります。



3.ここではすべてのソリューションを説明しません。これには非常に長い時間がかかるためです。 煙突掃除のたとえを読むことをお勧めします。 Googleには「ラビと煙突の掃除」または「ソクラテスと煙突の2つ」と書いた名前がたくさんあります。 一般的に、読むことを強くお勧めします。



4.このタスクでは、両方向にオブジェクトを運ぶこと、つまりそれらを取り戻すことができないという点で、条件があなたを制限しないことを覚えておく価値があります。 したがって、まずヤギを拾い、反対側に運びます。 私たちは戻って、例えばオオカミを取り、それを運び、植えてヤギを取ります。 ヤギを返し、キャベツを拾ってヤギを植えます。 キャベツを輸送してヤギに戻ります。 すべてがシンプルです。



5.ここでも、簡単です。 問題の状態では、細菌の数は毎分2倍になり、12：00にはペトリ皿一杯になると書かれています。 したがって、11：59にカップが半分いっぱいになると簡単に言うことができます。



6.私たちはタスクからの最小請求書を持っているので-それは50ルーブルであるので、この数値に依存します。 130ルーブルを最も近い50に丸めるには、次の手順を実行します。

130は50で除算され、最も近い整数に丸められ（130/50 = 2.6 = 3）、結果に50が乗算されます（50 * 3 = 150）。 できた



115ルーブル（115/50 = 2.3 = 2）（2 * 50 = 100）で同様の操作を実行します。 できた 他の番号で確認できます。



がんばって。