Clever Geek Handbook

Minifest（ミニマリスト開発者のマニフェスト）

翻訳者から


先日、minifesto.orgミニサイトがネットワーク上に登場しました。私の意見では、スタートアップへのアプローチ（および開発全般）の経験に関する抽象的な論文です。 テキストのマニフェストは最初から最後まで柔らかくなりますが、これにより悪化することはありません。



繰り返しになりますが、「コンピュータサイエンス」というフレーズの翻訳がないことをおpoび申し上げます。



簡単に







パレート法のために戦う



パレートの法則では、結果の80％がアプリケーションの実装済み機能の20％によって達成されると規定されています 。 次のスプリント/ゴールサイクルを計画するときは、このことに留意してください。

最高のエンジニアとは、将来の努力の80％を残すような方法で、一連の要件を実装するコストを見積もることができるエンジニアです。



自分でつぶしてください。 これは軍隊ではありません。私たちの業界では、あなたはあなたが考え、責任を負うことに支払われます。 要件が冗長であると思われる場合は、 常に自分の立場を表明してください。



あなたが書くことができる最悪のコードは、使用されていないコードです。 これを行うために、略語YAGNI（あなたはそれを使うつもりはない） [文字通り-「あなたはそれを使わない」; ここでは、元のテキストに基づいた逐語的なものです。 翻訳者] 。



あなたが書く最高のコードは、あなたが書かないコードです。 間違ってはいけないからです。



優先順位を付ける



エラーを修正する方法があります。これを「沈殿」と呼びます。 これは、他のエラーの累積によってエラーが修正されるときです。 私が侵食と呼ぶ別の方法があります。 これは、顧客が考えを変えたときです。 優先順位付けと露出が不必要な作業からあなたを保護するまさにその例。

結局のところ、ミニマリズムは仕事をする方法ではありません。 ミニマリズムは重要なものに集中する方法です。



最高は善の敵



完璧を求めますが、今はそうではありません。 反復とは、適切なタイミングで適切なアドバイスを提供する友人です。

最初に 、それを実行してから、正しく実行してから、それを改善します。



エンジニアはしばしば世界をモデル化できると考えますが、世界がこれを示すたびにそうではないことを示しています。 かなり複雑なシステムを簡単に設計することはできません。 デザインは常に進化的です。



すべてを作業の中間段階として扱います。 何かがまだ正常に機能していない場合でも、負担をかけないでください。 モッシャーの法則を思い出してください。「すべてが正常に機能すれば、仕事はなくなります。」



つぼみで殺す



破壊する 。 より速く、より良い。 数か月間作業してきたものをゴミ箱に捨てることを恐れないでください。

最初から始めると、 新しいものが自動的に表示されます。 それはあなたの経験から生まれたものです。



何をしているかを常に評価します。 これは、 リーンスタートアップの本が言っていることです。 MVP（最小実行可能プロトタイプ、ベアリーライブプロトタイプ）を開発します。 ご覧ください。 ふさわしくない？ 捨てて、あなたはすでに経験を積んでいます。

ミスをすればするほど、早く学習できます。



価値を高める



誰もすべてを知ることはできません。



自問してください -チームをどのように支援できますか？ 彼女は何が最も必要ですか？ スケーラビリティの専門家は何人いますか？ あなたのプログラミング言語を完全に知っているのは誰ですか？ 製品を最も応援しているのは誰ですか？ 誰がその取り組みを調整していますか？



すべてのチームは異なるので、あなたは適応して選択し、あなたとあなたのチームの長所と短所を探す必要があります。

一つのことを愛し、 それをつかむことを学びます。 自分自身を正しく与えてみてください。 結局のところ、あなた自身があなたの問題を解決するのに役立つものではなく、何とかしてあなたの仕事をするものではありません。



もちろん、タスクを共有できる人と一緒に作業する方が簡単ですが、チームの本当の強みは補完的な人々にあります。 少なくとも、チームAを覚えておいてください。



最初の基本



私たちの生活のある時点で、基本の重要性を理解します。 何らかの理由で、 基本に戻ることは高齢者向けのトピックであると理解されています。 馬鹿にならないように、待ってはいけません。 今すぐ基本に賭けてください。



コンピューターサイエンスの年代記には、新しいプロジェクトに適用できる優れたソリューションがあります。 これらの決定から始めて、一貫して考えようとする必要があります。



有名な言葉を言い換えると、ソフトウェア開発には、アーキテクチャ、 アーキテクチャ 、アーキテクチャの順に3つの重要な側面があります。



そのような基本の例： 共有責任 、 一般システム理論 、 ギャングフォーデザインパターン 、 共有責任 、 SOLID原則 、 クリーンコード 、 アジャイル原則 、 アルゴリズム 、 データ構造 、 HTTP仕様など

もちろん、Jasmine、JUnit、Mochaなどの単体テストフレームワークに突入することもできますが、もちろん、 テストでカバーできるコードを記述する方法を学ぶ方が便利です（たとえば、コードを状態から分離し、コンポーネントの接続性を減らす）。



さまざまな角度から見る



単純なものは 、複雑なものよりもはるかに大きな労力で得られます。 ミニマリズムには、より少ない労力でより多くのことを行う方法を見つけるための創造性が必要です。



技術的なスキルは複雑さの原因であり、 創造性はシンプルさの原因です。 創造性は一種の「ほろ酔い研究」です。 機会をお楽しみください。



もっと仕事をしようとせず、仕事を減らして、もっと知的にしよう。 考えて！ あなたが取り組んでいるものについて考えてください。 自動操縦を無効にします。 快適ゾーンを離れます 。 自分の手でコントロールしてください。



現状を失うことを恐れないでください。 周りの世界はあなたより賢くない人々によって構築されたことを忘れないでください、彼らはそのような世界が可能であると単に信じていました。



もちろん、人々はあなたを奇妙な人だと考え始めることができます-単にあなたが奇妙なことをするからです。しかし、あなたは奇妙で革新的なことをするまでリーダーになれません。 あなたの前に誰もやったことのない何か。

たとえば、すべての種類の会議や会議で、会社で多くの時間が無駄になっていると皆さんは考えていると思います。 まあ、すべてについて話し、何についても話さない人。 これが、Jeffrey Basos（Amazonの創設者兼CEO）が彼の会社でのミーティングに少し型破りにアプローチするようになった理由です。 すべての会議参加者が会議室に集まったら、30分間、会議の要約を完全に黙って読むことができます。 そしてその後、議論に進むことができます。



構文



私たちは機械ではなく人のためにコードを書きます 。構文は彼らの相互作用の基礎です。



良い例はパスツールの引用にあります：「もっと時間があったら、 もっと短い手紙を書くでしょう。」



メソッドに短い名前を付け、クラスにできるだけ責任を与えないようにします。 パラメータの数を減らし、明らかなコメントを避けます...コードから何もスローできない場合、作業は完了します。



混同しないでください



ソフトウェア開発の問題は、抽象化のレイヤーを追加することで解決できます。 過度の抽象化以外。 残念ながら、これはアーキテクチャの複雑さを制限し、単純さと冗長性の間の特定のバランスを模索させます。



抽象化は素晴らしいです。 これにより、自分の考えを正確に表現できる新しいセマンティックレイヤーを作成できます。 しかし、アクティビティの一部の側面（リファクタリングなど）でも、システムの巨大で詳細すぎるスキームの理解が複雑になります。



それが、解剖を行い、 妥協策を検討することができる自然な点を探す必要がある理由です。



例として、ドメインモデルの「ルート/リーフ」パラダイム、「コントローラー/ツール」パラダイム、「 高密度-低接続性 」の原則、レベル間RESTful-相互作用インターフェース 。



スクラブ残り物



「残りのジャストインケース」などがあります[元の-「キッペル」、約。 翻訳者] 。 これは念のため残しておきますが、二度と使用しません。 あなたの家では、これは大抵の場合、あなたのコードの中にあります。 プロジェクトの一部が破損する可能性があるため、削除するのが怖い継承メソッド。 私たちが二度と必要としない、すぐに必要なライブラリ。 古いコメント...



人間の本質には、それを英雄的に単純化するために複雑さを作り出さなければならないという事実があります。 定期的にプロジェクトを調べ、「見捨てられた場合」を見つけて破壊する必要があります。



ミニマリズムは、コアからの気晴らしと戦います。


More articles:


All Articles