＼回答があります！／

• 

  荘野敬也（bowyer-app）

  エンジニア

  2年前
  まずはコードを書いて動かしてみることから始めてますね。
  最近だと僕がflutterを始めたときはblueprintがあったのでそれを読んでみて、実際にサンプルコードを動かしました。
  https://github.com/wasabeef/flutter-architecture-blueprints
  view数 10
  • 1

• 

  kentaro haneda（jumbo）

  エンジニア

  2年前
  自分の知っている、詳しい言語との差を把握するところから始めます。
  GoFデザインパターンの中で馴染み深いものや、実装経験のあるような設計をその言語で再現してみます。
  個人的にはこれがクセや作りにくいところ、先人の苦戦などがイメージしやすい気がします。
  
  あとはその時有名なFWやライブラリなどを読みます。
  あまり大規模なものは最初は心が折れるのでstar数300くらいの伸びてきそうなリポジトリとかREADMEや補足を別で記事に書いていたりするものを読み、どういう思想でどういう実装をされたかを見るようにします。
  view数 13
  • 1
  • 4
  • 2

• 

  山本隼汰

  エンジニア

  2年前
  とにかくコードを読みます。個人的にはエディタやIDEは、手元で対話的に動作を見たい時か、読んでいるコードの挙動を手元で再現したい時しか使いません。自然言語を学ぶ見たく、最初に例文見て、文法覚えて、単語やフレーズ、慣用句を覚えたのち、「〇〇の時は、XXとも言えるけど、▲▲という方がこの言語っぽい」を掴みます。
  
  というのも、単位時間あたりにできることが書いてるよりも読んでいる方が多く、またどうしても書きから始めてしまうと「どうにかして自分が思っているような動作をさせよう」として、無理に変なコードを書いたり、後から見ると「なんでこうしたのかよくわからない」ことをしたりしてしまって、「その言語のことを学ぶ」という本質がどこかにいってしまうことが個人的には多いためです。
  
  自分に制約を課すことを念頭に、なるべくコードは書かず、「読めそう」と思うリポジトリや記事のコードリーディングして、なんならテストコードを見て挙動を確認していく方が多いです。文章をブログなどに寄稿する際に、他の文章のテイストを見て、そのメディアに合うテイストに調整する作業と近しいでしょうかね。
  
  「ここで、この処理が書かれているなら、多分次に〇〇の処理がくるだろう」と読めるようになると、体感的にはある課題が与えられた時に、その言語で「どのように書けば課題を解決できるか」がある程度道筋建てられるようになるため、そこで初めてコードを書くようになります。 （編集済み）
  view数 12
  • 1

• 

  Shoichi Namba

  エンジニア

  2年前
  最初は何も考えずにいきなり実際にいつも作っているようなものを作ってみます。
  やはりいつも作っているものがちゃんと作れるようになりたいというのと、あとはその方が必要なもの、つまづくけど知っておいたほうが良い処理の作り方などを早めに自分でも知ることができるからです。
  また、必要なライブラリもちゃんとあるっぽいとか、無さそうなのでこのあたりが弱点ぽい、というのも徐々にわかってきます。
  
  また興味があればそこで作っていく中で思考が枝分かれしていき、色々と知識を深める機会につなげることができたりします。
  view数 13
  • 1