LoginSignup
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@webmaster-patche

プログラマーのマインドとは

Last updated at Posted at 2019-12-17

はじめに

  • 当該記事はたたき台のため、今後、イメージやフローを盛り込む予定です

ベテランプログラマーになるために

プログラマーとコーダーの違いとは

  • コーダーはSyntaxを並べて機能化しているだけ

  • プログラマーはパラダイムや機能、Syntaxの理解、SDK（や標準ビルトインオブジェクト、ライブラリ）の把握、IDEの理解、ソースコード管理、バージョニング、開発手法、開発技法、メソッドシグネチャ、言語コミュニティの存在の把握などを理解している（無論、アルゴリズムやアーキテクチャ、理論はある程度知りえるか、知りえる状態にしておくことも必要である）

Rubyの例

Rubyであれば

  • Matzが開発者である
  • OSSである
  • YARV-VMがある（YARVバイトコードがある）
  • ガベージコレクションでメモリ管理がされる
  • OSに依存しないスレッド機構がある
  • オブジェクト指向
  • オブジェクトの強い型付けがある
  • メソッドのアクセサが指定できる（private/protected/public）
  • インタプリタ言語である
  • メンバ変数がプライベート変数である
  • 全てがオブジェクトである（スタックではない？）
  • 静的型チェックがない（コンパイラで型安全を保証しない、というよりその仕組みがない）
    • 厳密にはRuby2.6からJITコンパイラが登場してsoバイナリを直接ロードする仕組みもあるが、何れにしても実行時エラーしか取得できない
  • 変数名に型関連付けがない（Genericがない？）
  • 型宣言がない（動的型付けである）
  • 型キャストがない
  • コンストラクタはinitializeのみ（指定できない）
  • 単一継承しかない
  • インターフェイスではなくMix-in
  • ブロックがある
  • 例外処理機構（エラーハンドラ）がある
  • XMLよりもYAML（これは今のトレンドの気がする）
  • メソッド参照・オブジェクト参照ができる
  • Syntax SugarでJavaよりも構文を減らすことができる
  • nilを持つ
  • ==は等価式、 hoge.equal? は同一オブジェクトの比較
  • メソッドシグネチャの丸括弧は省略できる

リファレンスマニュアル

Change log

コミュニティリスト

逆にJavaであれば

  • コンパイラがある（JDKに限る。JREはランタイム用であるためコンパイラが内包されない）
  • 様々な命令を伝えるオペコードがある
  • JVMがある
  • 静的型付け
  • 静的型チェックがある
  • 変数名に型付けがある（Generic）
  • ヒープメモリとスタックメモリ領域があるなども含まれる
  • JME/JEE/JSEで提供されるライブラリが異なる

若い頃にやるべき事

こだわりなく、パラダイムやデザインパターンなどにとらわれる事なく学び、実際にチュートリアルなどをやってみてOutputする

  • このやり方は覚えるということの基本であり、何十代になっても変わらない

UMLを学ぶ

  • 昨今のDDDセミナーやDesign Sprintなどを見える限り、UMLを再学習しているとしか思えないケースがちらほらと見える

    • 全てではないが、UMLをワークフローに組み込んだものが少なくない

  • UMLは開発の上ではまず最初に学ぶべきもの（OJTと称して、現場で見て学べという企業もあるが、適当な開発手法を回して、設計を素通りしている企業では学ぶものは何もないため、もし現状がそうなら転職を考えましょう）

    • 大手の開発ベンダーや三大キャリア、一部上場の事業会社でも、UML標準が到底導入出来ないような企業、またはプロジェクトが何社もあります（何処かは伏せますが、知名度がある企業です）
要件定義フェーズ
  • ロバストネス図
    • ユースケース図を作成
    • そこからアクターを登場させ、アクターが必要とするインターフェースをバウンダリ要素を追加
    • コントロール要素でそのバウンダリ要素とエンティティ要素をつなげる
    • それがロバストネス

ここにイメージを組み込み予定

設計フェーズ
  • PDM
  • ER
  • シーケンス図やクラス図など

ここにイメージを組み込み予定

実装フェーズ

Design Sprintなどの開発手法を学ぶ

Design Sprintワークフロー
  1. Prepare
  • 人、場所、モノ、時間を用意する（ステークホルダ）
    • 人はエンジニア、デザイナ、PM、意思決定者、マーケッター、セールス、ファシリテータ
    • 場所はワークフローの実施ワークスペース
    • 時間はワークフローの実施スケジュールの調整
    • モノは大量のPostit、ペン、分類分けできるだけのホワイトボード、投票のためのシール、多めのA3~A5の紙、（あると良い）タイマー、飲食品（疲れるので）、プロトタイピングツール（推敲で必要）
    • HMWのKPI設定 時間をあまり掛けない（むしろHMWアイデアをメンバに出してもらうことの方が重要）
    • トピックの設定 ~0.5d
  1. Understand
  • HMWとは何かの説明をする 5分程度
  • Lightning Talk 10〜15分/チーム（トピック）（ビジネスルール、KPIなどの共有=キックオフの位置付け）
  1. Diverge
  • Crazy8sで発散
    • HMWアイデア、課題を付箋に書きまくる
    • HMWアイデア、課題をまとめていく（アフィニティカテゴリ化）
    • HMWアイデア、課題を付箋に書きまくる〜アフィニティカテゴリ化は出し切るまで行う 30分
    • （マインドマップで問題整理） 10-15分
    • Crazy 8s 5分
    • ソリューションスケッチ（ユーザーストーリーまたはユーザージャーニーマップの推敲） 30-50分
    • ドット投票 5分
    • 最終投票 5分
    • 発散を繰り返し行う
  • 課題解決の方法を模索する（チームビルディング、チームワーク）
  1. Decide
  • 最終投票を元に、最終決定する（コンセンサス）
  1. Prototyping
  • プロト作成（あくまでプロトタイプの段階で、開発をするわけではない）

デザインパターンを学ぶ

MVC
MVVM
MVP

ディレクションやプロダクト・プロジェクトマネジメント手法をやんわりレベルでも理解する

  • Design Sprint手法一つとってもタイムマネジメント、リソースマネジメント、コストマネジメント、調達マネジメント、品質マネジメント、人的資源マネジメント、コミュニケーションマネジメントについて部分的に理解できる
    • Google Design Sprint

開発技法を知る

  • 終生スタンドアロンな開発しかしない天才であれば技法を知る必要もないのだろうが、JKありえないので、開発技法はプロフェッショナルとして必要である
品質を高める方法
ペアプログラミング
モブプログラミング
PDCAサイクル

  • YWT

    • 「Y：やったこと」「W：分かったこと」「T：次にやること」
    • 実施したこと(Y)に対する、理解したこと(W)、それに対しての次のアクション(T)を整理する、ポジティブ型のPDCAサイクル
    • 日本能率協会コンサルティングが提唱した手法
    • メリット：
      • ポジティブ型である為、悪い点ばかりがピックアップされがちなKPTとは真逆のスタンスである
    • デメリット
      • そもそものスコープに漏れがあると、ポジティブシンキングがちになり、実質的に問題を抱えているにも関わらず、改善思考にならない（現実に満足してしまう）

  • KPT

    • 「定常的に実施すること：KEEP」、「新たに出てきた問題点：PROBLEM」、「試行するべきこと：TRY」

30代前のプロフェッショナルとして慣れ始めた頃にやるべき事

開発手法を理解する

  • ワークフローが確立していない企業・プロジェクトを幾度となく経験している点から、開発手法を正しく理解していないディレクター、PM、リーダーが多い様です。
スクラム開発

  • スパイク

    • スプリントバックログがReadyとなっている状態でスプリントに投入される必要があり、とはいえ、スプリント内でバックログのストーリーが完成する可能性を上げるためには、技術的な調査が完了していて、制約を克服していることが必要となる。

    • スパイクの算出方法

    • 例）

    • チームのベロシティ平均が 100 と仮定する

    • チームの人数が5人と仮定する

    • 2週間のスプリントでスパイクにはスプリントの半分を費やすと仮定

    • 100 の半分は 50 でこれを開発者の人数で割ると 10 になる 利用出来るポイントで一番近いのは 8 なので 8 を採用する

  • ストーリポイント

    • 呼び方は千差万別

    • Drecomなど：ストーリーポイント / ZenHub：Estimate

    • **フィボナッチ数列**で指定可能な数値が決まっている

    • 1, 2, 3, 5, 8, 13, 21, 40

    • 何時間での見積もりではなくストーリーポイントを登用する理由

      • 経験、知識、手法は十人十色である為、例えばAさんがある機能を８時間で作れても、それをBさんが８時間で作れるとは限らない
      • ある言語が出来る、あるF/Wが出来るとしても、その「出来る」は皆同じだろうか。
      • 主観的要素が色濃く出て、影響を受ける分野では、全ては相対的となるのである

    • ストーリーポイントを使った「相対見積もり」では人の知識や能力に依存しないで見積もりを出す事が可能

    • 例えば、東京ー京都間の移動に2掛かるとして、その２倍程度離れている、東京ー博多間は5と見積もることができる

    • 相対見積もり = ある施策の実工数 x 相対規模 の結果がフィボナッチ数列の境界値を超えない範囲の最大値

    • 5 = 2 x 2 > 3

    • 相対的見積もり

    • 絶対的見積もり

      • 時間的見積もりをそれぞれの主観で割り出す

      • 属人化を生み出す可能性が非常に高い

      • 正確な時間見積もりはほとんど不可能

      • 要件は全く同じではないので、F/Wの制約、言語バージョンの制約、ライブラリの制約、システムの制約など様々な不確定要素がある

  • ベロシティ

    • １スプリントあたりの生産量( ストーリポイントの総計？ ストーリーポイントを割り当てた施策のうち、達成した施策の合計）

      • スプリントバックログから当期スプリントで施策し完了したストーリーの数

      例）
      １人１人のスプリントにおけるストーリーポイントの合計（総量）
      この総量は、あくまで「あるチームにおけるある人のストーリーポイントを積み重ねたもの（コンテキスト）であり、これは他のチームには適用できない（状況が全く同じことがあるだろうか？）。そして、ストーリーポイントにはスパイクなども含まれる為、これを工数（人日）などには変換できない」である。

プロジェクトマネジメントを学ぶ

攻撃手法を学ぶ

セッションフィクセーション
セッションハイジャック
SQLインジェクション
クリックジャッキング
XSS
XSRF
PersistentXSS
ブルートフォース(総当たり)
ハッシュコリジョン

キーワード

プログラマー プログラミング 開発手法 開発技法 ウォーターフォール スクラム エクストリームプログラミング 反復開発 アジャイル projectmanagement PMBOK マネジメント デザインパターン DRY 開発環境

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?