ヒーロー開発者の5つのトップスキル(レゴブロックを含む)

プログラミングは、レゴブロックを作るようなものです。すべての開発者は、新しいレゴセットを選び、指示に従って作成できます。これはとても簡単です。学校の課題のコーディングや入門レベルのチュートリアルと考えてください。

実際のソフトウェアプロジェクトは異なります。それは非常に大きな城のセットを建てるようなものです。それが過去にすでに建てられたことを除いて。それから誰かが野蛮なキックでそれをバラバラに引き裂いた。大きな部分は一緒に残っていました。小さな部品は完全に押しつぶされました。一部の要素がウィンドウから外れました。

が届きます。この箱には、残っているものだけでなく、他のセットの何千ものピースが入っています。そしてもちろん、指示はなくなりました。城がどのように見えるかを知るために、1枚の写真だけに頼ることができます。

これは興味深いことです。この環境で効果的に作業する方法を見てみましょう。

1。未知のものを受け入れる

開発タスクの最初のステップは、何をする必要があるかを理解することです。当たり前のようです。それでも、タスクが大きいほど、未知の変数が多くなります。これは明確な期待を設定する瞬間です。

開始方法がわからない場合は、考えたり概念化したりするのに時間がかかりすぎても意味がありません。始めて、必要な重要な要素について頭を悩ませてください。その後、もう一度考えてください。誰かが見積もりや期限を前もって求めてきた場合は、率直で正直になりましょう。あなたが知らない、または理解できないかもしれないシステムのいくつかの部分。そしてそれは大丈夫です。

Facebook、Netflix、Oracleなどのプラットフォームを考えてみてください。または、そこにある大規模なエンタープライズソフトウェア。全範囲を把握できる人はほとんどいません。それを構築したか、それを使って何年も費やした人。だからまず第一に、すべてを知らないために自分自身に休憩を与えてください。さらに重要なことは、すべてを知っているわけではないことを受け入れることです。

経験豊富で生産的な開発者は優れたコーダーではありません。彼らは彼らが何をする必要があるかを評価するのに優れています。そして、未知のものに対処するための適切な戦略を選択する際に。

レゴの例え:再構築したい城のセットを考えてみてください。誰かがあなたに城と箱の写真を渡して、「城を建てるのにどれくらいの時間が必要ですか?」と尋ねるとします。 「まだわからない」以外に良い答えはありません。始めて、1日か2日後に自分がどこにいるか見てみましょう。」

このタスクに対する究極の「未知のものを恐れる」アプローチは、床のボックスからすべての要素をレイアウトすることです。色と形に基づいて、それらを属するセットに分けてみてください。次に、写真を見て、レンガの組み立て方法に関するメンタルマップを作成します。

このアプローチは2つの理由で間違っています。まず、城が大きすぎると、おそらくそこにたどり着くことはありません。次に重要なのは、進捗状況を評価できないことです。あなたは正しい方向に進んでいるか、まったく進んでいない可能性があります。フィードバックループはありません。

別のアプローチは、城の建設を開始することです。あなたが行くにつれて、あなたはあなたが必要とする部分を見つけるのが簡単であるかどうかを学びます。写真がすべての詳細を示しているのか、それとも構造が見た目よりも複雑なのかがわかります。

これらの情報に基づいて、仕事をするのにかかる時間と労力について、より知識に基づいた推測をすることができます。そして、それがやる価値があるのなら。明日の朝に建てる必要がある場合は、店に行って同じ城をもう一度購入する方が良い解決策かもしれません。それはあなたの決断ではないかもしれませんが、問題の解決策は必ずしもより多くのコードによってもたらされるとは限りません。

2。妥協を受け入れる

開発者はしばしば「細部への細心の注意」を称賛し、評価します。そこにあるすべての求人には、これが何らかの形であります。それはすべて良いことです。ただし、細部への注意と頑固さを混同しないでください。すべてを完璧にすることができます。

大きなタスクを開始するときは、その2つのバージョンを定義する必要があります。最初のバージョンは、物事が思ったとおりに機能することを確認するために必要な最低限のものです。

それは私が「水平に働く」と呼んでいるものです。あなたのより大きな仕事の各部分は垂直です。最初の結果を得るために深く掘り下げる必要はありません。最初に主なユースケースまたはシナリオに焦点を合わせます。そしてそこからそれを取りなさい。

最初のバージョンで残すことができるもの:

そのすべてを考えずに、必要なコードを指から流れるように記述してください。すぐに高い機能カバレッジに到達するはずです。確かに、この最初の単純なバージョンから最後のバージョンに移行するには、かなりの時間がかかります。では、ポイントは何ですか?

それがより安全な進歩の方法です。あなたはあなたの仮定を検証したいです。あなたができる限り賢くて有能であるとしても、設計と概念化はあなたをそこまでしか連れて行けません。手を汚してください。それはあなたに「それを考え抜く」よりも多くの知識と洞察を与えるでしょう。

これは、ビジネスにおける新製品または新機能のMVPに適用されるのと同じ原則です。このアプローチには、最初のバージョンを表示してフィードバックを得ることができるという利点もあります。または質問をします。図面や概念よりも既存のコードについてブレインストーミングする方が簡単です。

レゴの例え:あなたは城の塔を建てています。写真では、高い塔の壁は灰色と白のレンガが織り交ぜられています。塔にはお姫様が閉じ込められ、屋上には竜がいます。

あなたは王女とドラゴンを見つけますが、必要な灰色と白のレンガを見つけるには何年もかかります。正しいアプローチは、レンガを使用して壁を構築し、王女とドラゴンを配置することです。 「壁のレンガを改善する」のようなTODOを残すことができます。

問題を特定したという考えです。完璧な壁を作るのは難しいでしょう。それを受け入れて、私たちがまだ知らない他のすべての障害を発見するために進みましょう。妥協を受け入れることで、行き詰まるのを防ぐことができます。

TODOにたどり着いたことがない場合でも、顧客に次のように伝えることができます。塔の壁を改善する必要があることはわかっていますが、それは構築されています。」これは、「タワーに適したレンガを見つけるのに何年もかかったため、大幅に遅れています。しかし、見てください、塔は完璧で、あなたが私たちに送った写真とまったく同じです。さあ、城の残りの部分に行きましょう。」

重要:妥協と怠惰を混同しないでください。

塔の重要な要素は王女とドラゴンです。農夫を塔に、猫を屋根に置いてはいけません。それは問題ない妥協案だと思います。動作しません:)

3。外の世界から始める

制御できるものはたくさんあります。そして、あなたができないこと。私は、10年前の開発者としての最初の任務の1つでそれを困難な方法で学びました。タスクは、外部APIを統合し、データを処理することでした。一週間ありました。私のような経験の浅い人にとっても、それは非常に合理的なタイムラインでした。

これが私がしたことです(そしてあなたはすべきではありません)。

月曜日の朝です。 APIドキュメントを10分間読みました。とても簡単そうです。テストデータセットを作成し、それを処理するコードを記述します。完了したら、実際のAPIでテストします。

水曜日の朝、もうすぐ終わりです。私のコードはクリーンでうまく設計されていて、すべてがうまくいったと思います(そうではありませんでした)。これで、APIを統合する必要があり、おそらく前もって終了します。 「私はすごい」と思わずにはいられません。

私はすぐにAPIの部分にたどり着きます。私は自分のコードでそれに到達しようとしています。私ができないことを除いて。何かが間違っている。私は一日中すべてを再確認するのを無駄にします。さまざまなAPIクライアントを使用する。進展はありません。日が点滅し、今は水曜日の夜です。

行き詰まっていて、すごいのとは正反対だと感じています。

木曜日に仕事に取り掛かり、同僚に助けを求めます。彼は、APIへのアクセスがIP制限されている可能性があり、IPをホワイトリストに登録するために会社に連絡する必要があると言っています。よし、私には前進する方法がある。

APIを所有している会社にメールを送信します。午前8時のようです。私は愚かなことに、数分以内に迅速な回答と解決を期待しています。私は朝中汗をかき、正午にようやく電話を取り、サポート番号に電話します。私は自分の問題を説明し、それがどれほど大きな「緊急事態」であるかをできる限り強調しようとしています(そうではありませんでした)。

反対側の人は、ホワイトリストへの登録期間は通常1日か2日だと説明しています。今、私は落ち込んでいます。 1日か2日?これはどのように可能ですか?私の仕事は世界で最も重要であり(もちろん私だけに)、彼らは私に「1日か2日」と言っていますか?

突然、私はもう先に進んでいません。私は遅刻だ。私は失敗しました。私は上司のところに行き、めちゃくちゃだと言います。月曜日の朝にAPIをチェックすべきだった。その場合、同じ日にアクセスを要求し、その間にコードを記述していました。彼はただ「はい、持っているべきです」と微笑んでいます。

私はついに金曜日にアクセスできるようになり、仕事を終えるために非常に遅く滞在しなければなりません。 APIデータがもたらす多くの驚きにコードを適合させます。さようならよく設計されたクリーンなコード。後で「そのための時間がなかった」と言って正当化します(ありました)。

当時の私の素朴さの中で、アクセスのことや間違ったドキュメントは非常に不運だと感じました。これで、通常どおりのビジネスであることがわかります。

レッスンは、制御できないものから始めることです。あなたが環境について持っているすべての仮定を確認してください。手動で低コストの方法を使用して、できるだけ早く試してみてください。

レゴの例え:城を建てていて、物事が順調に進んでいると想像してみてください。これで、ボックスを約100回混合してピースを探しました。 「写真の塔に座っているあの巨大なオレンジ色のドラゴンに出会ったことは一度もない」と思わずにはいられません。

あなたはその情報を無視して、あなたの良い進歩に焦点を合わせます。それは人間です。前進することは、問題に対処することよりもエキサイティングです。最後に、ドラゴンが行方不明であることを認める必要があります。そして、セットの大きな部分は存在しないことを非常に遅く顧客に伝えます。それは良くありません。

代わりに行うことは、そのヒントをフォローアップすることです:「ドラゴンはどこにありますか?」。そこにないことを100%確認するために必要な時間を費やしてください。すぐに問題を提起してください。 「ねえ、箱の中にドラゴンは入っていません。他のレンガでドラゴンを作ることはできません。何をしますか?」

人々は、十分に早く知っていれば、驚くほど問題に問題はありません。問題を早期に発見することで、より多くの可能な解決策が開かれます。 「ドラゴンがいないことを知り続けましょうか?」 「ドラゴンを一人で買えますか?」 「箱の中に恐竜が見えます。代わりに使用できますか?」

4。明確な線を引く

既存のシステムの新機能の開発を開始するときは、既存のコードとのインターフェース方法を定義することから始めます。もちろん、SOLIDの原則などに従う必要がありますが、重要な部分はそれよりも単純です。接触面をできるだけ低くするようにしてください。

カットを明確に定義する簡単なプロセスにより、ソリューションが向上します。それはあなたに重要な質問に取り組むことを強制するでしょう:ユーザーまたはシステムは私のコードをどのように使用しますか? どのような入力が得られますか?どのような出力を生成する必要がありますか?これは、ボールを監視するのに役立ちます。使用しているシステムについてまだよく知らない場合、これはさらに当てはまります。すでに知っていることに飛び込む前に、未知のものを探索する良い機会です。

また、機能のオンとオフを簡単に切り替えることができます。ブールフラグまたはより高度なフィーチャートグルメカニズムを使用できます。

レゴの例え:城の延長を建設する必要があるとします。要件はかなり高いレベルなので、創造性の余地は十分にあります。ただし、既存の城に触れることはできません。

城に取り付けるスペースがどこにもないことを知るためだけに、素晴らしい拡張機能を構築することができます。それは残念です。なんらかの形で収まるように、拡張機能をすばやく変更する必要があります。

正しいアプローチは、最初に接触面を考えることです。延長は城のどこにありますか。どのレンガに取り付けることができますか?彼らはどのような形をしていますか?それを城に取り付けるエクステンションのいくつかのレンガをまとめます。しっかりと接続されていることを確認します。そこから、必要な拡張機能をフリースタイル化できます。

5。乾きすぎないでください

DRYはDo n’t RepeatYourselfの略です。それはおそらく従うのが最も簡単なルールです。コードの重複行を見つけるとすぐに、抽象化を行います。基本クラス、ヘルパーメソッドなど、何でもかまいません。

それではどうなりますか?次の人が来て、より多くのケースをカバーするために共通コードを変更する必要があります。彼女または彼は、新たな複雑さに対処するためにパラメーターとifステートメントを追加します。すぐに、最初の5行と単純な行が30行になり、何が起こっているのかを理解するのが困難になります。

読みやすさの悪さは、コードの繰り返しの良いトレードではありません。

重複した行を保持する方がよいでしょう。その後、各インスタンスを自由に変更できます。

次に「繰り返しの抽象化」に到達したときは、自分自身に問いかけてください。誰かが抽象化から戻ってくるのを何回見ましたか。基本クラスを削除して、共通コードを継承クラスに戻すようなものです。答えは決してないでしょう。

その理由は、一般的に抽象化とデザインパターンがクールで洗練されているためです。そして、それが存在する場合、「正当な理由があるに違いありません」。したがって、抽象化を導入すると、それが永遠にそこにとどまる可能性が高くなります。

これは、抽象化を使用してはならないという意味ですか?いいえ。要件に適合する場合のユーザーの抽象化。のようなもの:

これらは抽象化の良い候補であり、他にも多くの例がありますが、要件がビジネス関連(ロギング、セキュリティ、分析など)よりも技術的であることに注意してください。抽象化に適した要件がビジネスドメインの一部になることはめったにありません。

なぜですか?ビジネスドメインが現実の世界に近いからです。そして、私たちが制御できないこと。プロジェクトの開始時になされた仮定は、すぐに不十分になることがよくあります。繰り返しを避けるためだけにコードを過度に設計しないでください。

レゴの例え:なし。レゴブロックにはDRYの概念はありません。

要点

スマートに作業することは、コードを改善することではありません。それは、何をする必要があるかを理解し、目標に向かって安全に前進することです。

大規模でやりがいのある開発タスクには未知数が伴います。それを受け入れます。それを扱うことを学ぶ。

物事をシンプルに保ち、結果に対する期待をチーム、上司、顧客、理想的にはすべての人と一致させると、生産性が向上します。

お読みいただきありがとうございます!

2020年1月15日に The FireCIブログ で最初に公開されました。