就職して2年半で学んだ
2490 ワード
去年の今頃、会社を退職して留学生になり、あっという間に1年が経ちました.しかし、就職して2年半で学んだことは、1年後も時代遅れではありません.
もちろんこれは技術面だけでなく、会社の技術管理上の問題が多い.
私は大学の中であのような反抗的な人に属して、異なっていることが好きです.みんながWindowsを使っている間に、私はLinuxを使いました.みんながC++(うちの学校ではC++を入門言語に選んだ)で宿題をしていたとき、私はJavaを使いました.その後、みんなJavaで書き始めました.PythonやNode.jsに転用しました.大学の最後の学期のWeb開発の授業になると、私は微博で、Node.js、HTML 5、CSS 3、MongoDBで宿題を書きます.(私の当時の技術選択型には今、MEAN Stackという標準的な呼称がありました)、朽ち果てた先生に新しい技術を見せてください.
私のこの新しい技術に対する追求はずっと仕事まで残っていて、私たちのチームの多くは新しい技術に適しているか、古い問題を修正するか、私が主導しています.例えばiPhone 5に合わせると、Autoresizing Maskを正しく使用(当時はまだAuto layoutがなかった)、ARCなどに適していました.これらの比較的正常な技術アップグレードのほかに、cutting edgeのものを作るのが好きでした.その後、大企業で、技術的な雰囲気があまり濃くない大企業では、cutting edgeの技術が成功しにくく、会社の観点からメンテナンスコストが増加していることがわかりました.
たとえば株を作るときは、株の本文部分をhybridの形にします.すなわち、本文レンダリングはWeb技術を用い、本文ピクチャロード部分は非常に複雑なキャッシュロジックがあるため、nativeのコードを呼び出す必要があり、本文のいくつかのリンクポイントが入るには別のview controllerに入る必要がある.そのため、両側のコードを互いに呼び出すための簡単なbridgeを作りました.実はこのbridgeの主な目的はJavaScriptにNativeのコードを呼び出すことです.私はWeb技術が未来だと信じているので、コードの先頭をJavaScript部分に置き、Native部分は必要なインタフェースしか提供していません.またJavaScriptの文法が二重すぎるのが嫌で、CoffeeScriptを使って開発し、Xcodeのbuild phasesにCoffeeScriptをXcodeのコンパイルに伴ってJavaScriptにコンパイルするスクリプトを入れました.これで私はとても楽しかったです.技術が優雅だと思いますから.
しかし、間もなく、私が退職するにつれて、コードを同僚に渡した後、問題が発生しました.実はiOS開発チームの中で、Webフロントエンドの背景があるのは私だけです.他の同僚はJavaScriptもあまり知らないので、CoffeeScriptは言うまでもありません.だから私は私のコードが少しずつ変更されているのを見ています.まずCoffeeScriptを廃止するのはほぼすぐのことです.そして同僚たちはJavaScriptではなくobjcに慣れているため、コードロジックの重さが徐々にobjcに移行し、私の設計が逆転され、Web部分は純粋なViewとなり、Web部分の制御は完全にobjcによって完成した.そこで私のJSPBridgeの使い道は少なくなりました.
私がこのことから学んだのは、技術の選択型の時、自分の信念と便利さに専念することができなくて、会社の角度から考えなければなりません.まず、多くの人が技術マニアではないという事実を受け入れる必要があります.やむを得ない時になって、多くの人が新しい技術を学びたくない.新しい技術については、必要なのかオプションなのか、この等級付けが必要です.必要なのは、使わないと淘汰されるということです.あるいは高い学習曲線でない場合にbug率を大幅に低減する(例えばARC).オプションとは、ファンシーな概念であり、符号化効率を大幅に向上させることができず、学習曲線が高く、現在の技術が完全に代替できる新技術を指す.例えば現在熱いreactive概念は、optionalだと思う.reactiveはコード品質を大幅に向上させることができず、かなりの学習曲線がある(Haskellのような専門的な関数式プログラミングの訓練を受けていないので、FRPを正しく使うのは難しいですが、reactive cocoaを使う人は多くpromiseで使っているので、大役小役と言えます).これらのoptionalの新技術は、多くの上級者にとって確かに効率が向上しているかもしれませんが、多くの一般プログラマーにとってはそうではありません.だから、型を選ぶ際に考慮しなければなりません会社の平均的な技術レベル.
私は以前thoughtworksで彼らの技術レーダー図を見て、私は彼らが実際にどのようにしたのか分かりませんが、明らかに彼らは新しい技術を試してみる上で順番に漸進的に試して、これはとても良いと思います.
人を募集するときにトップの人材を募集すれば、最新の技術ができると思っている人もいます.しかし、事実は人を募集するのは難しい.私の家には長い間頼りになる人がいないので、技術マニアを募集するのはもっと不可能です.中型上場企業としては、小さな会社はおろか.だから多くの时に愿望はとてもすばらしくて、现実もとても非情です.
もちろんこれは技術面だけでなく、会社の技術管理上の問題が多い.
私は大学の中であのような反抗的な人に属して、異なっていることが好きです.みんながWindowsを使っている間に、私はLinuxを使いました.みんながC++(うちの学校ではC++を入門言語に選んだ)で宿題をしていたとき、私はJavaを使いました.その後、みんなJavaで書き始めました.PythonやNode.jsに転用しました.大学の最後の学期のWeb開発の授業になると、私は微博で、Node.js、HTML 5、CSS 3、MongoDBで宿題を書きます.(私の当時の技術選択型には今、MEAN Stackという標準的な呼称がありました)、朽ち果てた先生に新しい技術を見せてください.
私のこの新しい技術に対する追求はずっと仕事まで残っていて、私たちのチームの多くは新しい技術に適しているか、古い問題を修正するか、私が主導しています.例えばiPhone 5に合わせると、Autoresizing Maskを正しく使用(当時はまだAuto layoutがなかった)、ARCなどに適していました.これらの比較的正常な技術アップグレードのほかに、cutting edgeのものを作るのが好きでした.その後、大企業で、技術的な雰囲気があまり濃くない大企業では、cutting edgeの技術が成功しにくく、会社の観点からメンテナンスコストが増加していることがわかりました.
たとえば株を作るときは、株の本文部分をhybridの形にします.すなわち、本文レンダリングはWeb技術を用い、本文ピクチャロード部分は非常に複雑なキャッシュロジックがあるため、nativeのコードを呼び出す必要があり、本文のいくつかのリンクポイントが入るには別のview controllerに入る必要がある.そのため、両側のコードを互いに呼び出すための簡単なbridgeを作りました.実はこのbridgeの主な目的はJavaScriptにNativeのコードを呼び出すことです.私はWeb技術が未来だと信じているので、コードの先頭をJavaScript部分に置き、Native部分は必要なインタフェースしか提供していません.またJavaScriptの文法が二重すぎるのが嫌で、CoffeeScriptを使って開発し、Xcodeのbuild phasesにCoffeeScriptをXcodeのコンパイルに伴ってJavaScriptにコンパイルするスクリプトを入れました.これで私はとても楽しかったです.技術が優雅だと思いますから.
しかし、間もなく、私が退職するにつれて、コードを同僚に渡した後、問題が発生しました.実はiOS開発チームの中で、Webフロントエンドの背景があるのは私だけです.他の同僚はJavaScriptもあまり知らないので、CoffeeScriptは言うまでもありません.だから私は私のコードが少しずつ変更されているのを見ています.まずCoffeeScriptを廃止するのはほぼすぐのことです.そして同僚たちはJavaScriptではなくobjcに慣れているため、コードロジックの重さが徐々にobjcに移行し、私の設計が逆転され、Web部分は純粋なViewとなり、Web部分の制御は完全にobjcによって完成した.そこで私のJSPBridgeの使い道は少なくなりました.
stringByEvaluatingJavaScriptFromStringを使うとobjc呼び出しjsの機能が完成するからです.最終的に私が退職するのを待っていないうちに、そのモジュールは伝統的な技術に取って代わられました.私がこのことから学んだのは、技術の選択型の時、自分の信念と便利さに専念することができなくて、会社の角度から考えなければなりません.まず、多くの人が技術マニアではないという事実を受け入れる必要があります.やむを得ない時になって、多くの人が新しい技術を学びたくない.新しい技術については、必要なのかオプションなのか、この等級付けが必要です.必要なのは、使わないと淘汰されるということです.あるいは高い学習曲線でない場合にbug率を大幅に低減する(例えばARC).オプションとは、ファンシーな概念であり、符号化効率を大幅に向上させることができず、学習曲線が高く、現在の技術が完全に代替できる新技術を指す.例えば現在熱いreactive概念は、optionalだと思う.reactiveはコード品質を大幅に向上させることができず、かなりの学習曲線がある(Haskellのような専門的な関数式プログラミングの訓練を受けていないので、FRPを正しく使うのは難しいですが、reactive cocoaを使う人は多くpromiseで使っているので、大役小役と言えます).これらのoptionalの新技術は、多くの上級者にとって確かに効率が向上しているかもしれませんが、多くの一般プログラマーにとってはそうではありません.だから、型を選ぶ際に考慮しなければなりません会社の平均的な技術レベル.
私は以前thoughtworksで彼らの技術レーダー図を見て、私は彼らが実際にどのようにしたのか分かりませんが、明らかに彼らは新しい技術を試してみる上で順番に漸進的に試して、これはとても良いと思います.
人を募集するときにトップの人材を募集すれば、最新の技術ができると思っている人もいます.しかし、事実は人を募集するのは難しい.私の家には長い間頼りになる人がいないので、技術マニアを募集するのはもっと不可能です.中型上場企業としては、小さな会社はおろか.だから多くの时に愿望はとてもすばらしくて、现実もとても非情です.