なぜ私たちはコードを書くのでしょう？私は疑問に思っていました。コードはどれくらいの期間存続すると想定されていて、どれだけ使い捨てられるのでしょう？最終目標がユーザーに優れた便利な機能を提供することである場合、堅牢なコードに到達するために使い捨てるコードを書く価値はあるのでしょうか？私たちは優れたプログラマーとして、技術に磨きをかけますが、ただ正しくものを構築するのではなく、正しいものを構築するためにこれらすべての知識をどのように活用できるかを見てみましょう。
２０１６年にはじめて参加して今回二回目
プロトタイプを仕事にしています。
デザインチームに属しています。Experienceをテストする。
こういうことをしたかったので夢のような仕事です。デザイン、開発両方大好きなので良い組み合わせになっていました。
ただキャリアを始めた当初は出来ませんでした。どんなコード、どんなフレームワークが使えるかばかり気にしていた。
でも時間がたつに連れていろんなことができることに気づき、コードの書き方が変わってきた。色々なやり方があるということが分かってきた。
プロトタイプに限らず
ご自身の状況に合わせて考えていただければ。
ライブデザイントーク、皆さんいろいろアクションを取ってくださいました。今年は、オーディエンスの皆さんにも参加していただこうと思います。
答えを自身で書いてみてください。
始めていきましょう。
みなさん携帯つかっているようですね。
なぜみなさんデベロッパーなのでしょう、なぜいまデベロッパーとして仕事をしているのか答えを書いてみてください
私は、みなさんを幸せにしたい、生活の改善に寄与したい。
携帯は個人的でどんなところにも持っていく。そこで皆さんの生活を改善できる。
色々な答えがあるかと思います。何が正しい、間違っているということはないです。ご理解いただきたいのは自身のモチベーションを知ることです。
選択はすべてモチベーションがベースになっています。
コードはだれのために書いているのでしょう
面白い質問だと思います、これは次の質問にも関わります
自分自身、エンドユーザー、企業、同僚。。
いろいろな要素があると思います。モチベーションの話をさきほどしました。私はユーザー指向です。下よりです。
今までやってきたことにも影響しています。キャリアの中でもここが影響を及ぼしてきました。理想的にはバランスをとるのが良いと思います。でも状況によって、ぜんぜん違うことに成ることもあるでしょう。会社の中でも色々な動きがあったりキャリアで新しいことを学ばなくてはいけなかったり。その場所によって変わってくるでしょう。
そこで強調したいこと、なにかにYesと言っていることはなにかにNoと言っていることです。当たり前かもしれませんが、あえて考えることで、次にプロジェクトをするときに、実はこの辺、一度止まって自分のモチベーションを意識することで機会がいまれます。
正確に自分のせいかを意識するように成ると思います
では世の中が変わったらどう対応しますか？
私はいろいろやってきました。Python, React, TypeScript,最近はWeb開発です
でも優しくしてください
何が言いたいかと言うと、こうしたものは自分が選んだものではない。自分が選んだものであるケースもあった。今取り組んでいる体験はたまたまデスクトップに向いている。
必ずしも自分で選んだものではなかった、チームとして、ビジネスとして、全く違うスタックでやらなければならなくなったこともある。
これは正しい選択でした。これは皆さんにも怒るかもしれません。
まだ始めたばかりの人もいるかも、その領域の専門家かもしれない。
専門分野が変わったときにどう対応できるか。
自分が知らないテクノロジーに対応しなければいけないこともある
開発の中で大事になってくるのは学び方を学ぶ。
学びながら同時にコードをリリースする。
はじめて体験したのはReactNativeに切り替えたとき。自分の作業量を予測できなくなってしまった。
結局どうしたか、リリースしなければならないし学ばないといけない、フレームワークに基づいて理解しなくてはいけない、ドキュメントを読んだり勉強をした。次に何をしなくてはいけないかを考えながら学んだ。
それによってよりフォーカスできた
コードを書くときコードがどれくらい存在すべきと考えていますか
Developerとして自然にセキュアで堅牢、エンドユーザーにとって壊れないというのを考えていると思います。
現実的にコードの寿命はどのくらいなのでしょうか。どれだけ堅牢であれば本当に堅牢さが十分なのでしょうか。
１００％対応できるものはどれほどやれば良いのか、またはやらなくて良いのか、Paymentにはそうしたアプローチを取るということも考えられる。どのように目標を達成できるか。
コードに特別感は持たないほうが良いでしょう。技術スタックはすぐに変わります。
functional programing, reactional...素晴らしいものでしたがもう使われなくなったりしています。
コードを書く先にどれだけ書き直し、上書きがあるかを考えるアプローチもあるかと思います。
考え方を分けていくことが重要だと思います。コードにどのように実務的に対応するのが良いか考えていく。
コードリリースの阻害要因
同僚に見せる前、PRを作る前の阻害要因はなにか
私にとっては恐怖感です
もっと改善できたのではないか、適切な条件になっていないとレビューやユーザーに出すべきではないと思っている、本来それほど拘る必要ではないのにそうなってしまう。
私が書くものだがチームで共有するものでもある。チーム全体のスキルに依存していくことが重要。早い段階でチームのみんなに共有する。皆さんにも恐怖心がおそらくあるのではないか。もっと良くしようと思う。スペックをすべて間利用していないとか検証していなければ何が悪かったか心配に成る。心配するのは良いこと。重要なことを考えている。磨いていくことは重要だが、やはり私達の作業の阻害要因になっているのは阻害である。恐怖心はなくならないので共存することが大事。
リリースするときには余り心配することは実際にはない。進捗を早くすることが大事。方向性をはやくフィードバックを得る。長期的には正確度も高まり早く出すことができる。
最後に、どれぐらいの頻度でテストしますか？
コードに関して余りこだわりを捨てて人に共有することが重要になります。テストはいいやり方の一つです。
コミットする際、マージする際にテストするのであればいいですが、UnitTest,人に見せて確認することは非常に重要です。チームとしてのデベロッパーだけでなくテストすることが重要。
誰に対してコードを書いているのか。顧客か潜在顧客か同僚か
最終的に検証して確認する、最善のものを出すのが重要・
できるだけ頻度高くテストするのが重要。書いた目的を満たしているか。
なぜ だれのために 世界が変わったときどう順応するのか コードをどう変更していくのか 恐怖心が阻害要因になっている どうテストするか
私の経験は皆さんと違うかもしれません。でも数年間私は自問自答してきました。なので共有しました。
ときにはこうしたことも考えることが必要になると思います。
プロトタイプのマインドセットは何が何をどのように解決しようとしているのか
素晴らしい知識を個々で養い素晴らしい美しいものを構築してください
恐れを抱かずやっていただければと思います。
ありがとうございました。
