忍者ブログ

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

★意識していくべきこと


失敗したことを分析すること
 ・なぜ失敗したのか
 ・どこから間違いだしたのか
 ・どのように対応すればこんなことにならなかったのか

一つのことに執着しすぎず、
様々な角度から物事を考えるように。
 
こまめな報告を行い、
自分だけが把握してる問題点などが
無いようにしていかなければならない
 
確認作業をしっかり行ない、
思い込みや勝手な判断をしないように
作業を進めていく
→ここ、こんな記述になっていますが、
 こういう判断して問題ないでしょうか?
 
作業を始める前や、質問をする前に、
全体を把握し、自分の考えを整理してから
作業を行なうようする。
 
時間がどれぐらいかかるか、把握しておく
どのぐらいでできるかすぐ報告できるように。
これぐらいでできるやろ?
いや、これとこれとこれしないといけないので、これぐらいかかります
 
精神的にムリになってきたら
愚痴を言える時間を作ってもらう
弱音吐きすぎて怒られるなら怒られればいい
PR

★意識していくべきこと

・指示されたことを疑う
 ほんとに言われたことだけ?他に対応する箇所あるんじゃない?
 その指示通りだと、こっちがおかしくなるよ....

・こう聞いたから、こう思って、こうした

・後々自分が楽できるように
  こんな問題が残ってる→報告する→前にこういう報告したじゃないですか
 こんなコントロールあれば使いまわせるな
 こういう風に書いておけば他の部分でも使いまわせるな

・資料作成を依頼された場合(例えば横展開の一覧)
 この資料を作る 【目的】 は?
   →作業漏れを無くすため
   →作業の量を把握するため

 この資料の 【使用目的】 は?
   →現在の対応完了を把握する
   →いつ誰が対応したか把握する

★意識していくべきこと

・自分の仕事に責任を持つ、失敗を分析する
自分が担当した部分でトラブルがあった場合、
自分の行なった作業に問題があるため、
原因を突き止め、改善しないといけない。

上記に関して、自分に話を振られていなくても
自分から進んで首を突っ込んでいかないといけない。
問題点を解決することで、スキルアップに繋がる。

・作業のリスト化
何の作業が残っているのか。
どんな問題が残っているのか。
どれを優先すべきか。
今の自分に何が足りないのか。
→ひとつずつ、確実に潰していける
 まとめてやると、ボロがでる

・攻めないといけない
受身・言われるがままではなく、
ちゃんと考えて、こんなアプローチの仕方はどうでしょうといった、
提案をしていけるようになっていかないといけない。
小さい内容でいいから、こまめに報告という形で伝えていく。
→客に提案できる力が付く
 自分の意見を言わないと、
 何を考えているのか、どこで困っているのか伝わらない

・失敗を恐れない、怒られるのを恐れない
切羽詰る前に、早めに失敗しておく。
早めに失敗して、自分の経験値を貯める、次に生かす。
→将来失敗するより、今失敗している方が、影響・被害が少ない
 怒られ方も今のうちのほうが、緩い

・人間観察
どうすれば、この人を有効利用できるのか
このタイミングで話しかけるのはマズイ
なんか困ってそう
今日は機嫌が良さそう、なんかいいことあったんかな?

・試行錯誤する
現在与えられているもので、
色々試行錯誤、失敗を繰り返し、
ベストなものを見つける。
より良いものを与えられた時に、
凄いことになる

・テストは奥が深い
入力項目があれば、
1文字だけ入力、フル桁入力、中間の文字数入力など
テストパターンが考えられる

入力項目が3つあれば、
1つ目だけを入力
2つ目だけを入力
3つ目だけを入力
1つ目、2つ目入力など、
色んなケースが考えられる

どこまでのテストを行なうべきか、考えてみる
どうやれば、効率よりテストをこなせるか考える
 

クラス

たとえば、ユーザマスタのアクセスクラス

ユーザマスタに関わる記述の大部分をこのクラスで行う
insert
update
select
エラーチェックなど

考え方

考えろ!
ノリとか勢いとか、ふと思い付いたから、とかだと、なんかおかしくなる

自信がないなら確認しまくれ
気が付いた変な動きは、隠さず伝えろ

今、効率が良いではなく、後々効率が良いのを選べ

失敗したらどこがまずかったのか、徹底的に覚えろ
二度と同じミスするな

コーディング

運用上、DBから取得できるのは1件のはず。
→1件以外はエラーとする

SQL文だけのメソッドでも、
具体的になんの値を取得しているのか、
コメントをしっかり書くこと

1行が長すぎる場合、改行して見やすくすること

問題提議

こう言われたから、こう作った。
ではダメ。
→こう作ってみたけど、ここらへんが使いにくいですが、
これで問題ないですか?

伝えてないと、リリース後などに、これは使いにくいから変えてって要望がでる。
無駄な工数が発生する。


画面デザイン含め、仕様が全て合っているわけではない。
言語の特徴や出来ることを踏まえて、仕様を変えることを提案していかないとダメ。

作業の進め方

コーディング開始前に、前もって必要となるメソッド群を洗い出す。
仕様書に書いていないロジックが見つかったら、その部分の仕様を固める。
異常系の処理とか特に。

クラスダイアグラムとか使ってみる

作業中であとから記述するとこなどに、
「TODO:~の処理を記述」のようにTODOを入れておく。
タスク一覧で抽出してくれる

コーディングでも、何をするかリストを作る。
追加の作業があるたびに追加する
これをしておけば、残りの作業が時間把握しやすい
他人に仕事を振りやすい

クラスを考える。
どんなクラスが必要か?
どれを継承させるのか?
継承させるには、同じような処理をするものでまとめる。
メニューとコンテンツは、まったく別物なので、別々の物を継承させるべき
クラスは特定の機能ごとに作る
いろんなことができるクラスは、何か間違ってるハズ

地盤を固める

クラスとは?
抽象的なもの。
設計図のようなもの。
たとえば、車の設計図(クラス)。
これに、車種や色などの情報を与えると(インスタンス化)車が特定できる(オブジェクトになる)


継承と共通関数
継承は似たもの同士で行うもの。
車の設計図とバイクの設計図は別物なので、
継承できない
似たような機能があるからといって、継承しないこと
共通関数とは全くの別物
継承は難しいのであまり使用しない方がいいかも。。。


共通関数
車とバイクにおいて、
アクセル・ブレーキなどは、加速・減速など
似たような機能がある。
これは共通で定義できる可能性がある。

他人の振る舞いから学んだこと

・仕様が固まった後の要望や、仕様変更は、
 文書に残して、都度客先へ伝える

→納品直前、納品後の武器になるから。
 費やした工数なども明記しておくこと


・仕様の不明点などが発生した場合、即座に客先に確認すること

→確認せず、勝手に仕様を決めると、後々、客から「これは言ってたのと違う」とか言われる

カレンダー

04 2024/05 06
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

カテゴリー

フリーエリア

最新コメント

プロフィール

HN:
No Name Ninja
性別:
非公開

バーコード

ブログ内検索

P R