プログラマーの一日ってどんな感じなの?
引用元: ・プログラマーの一日を教えてくれ
の永遠ループ
>>3
楽しそう
>>4
参加したけどまあまあ楽しかったな
それが会社の本当の開発現場かわからんけど
テストっていちばん頭使うんだよ
いや、それはオマエがテスト以外知らないってだけだろ
大抵の現場だとテストエンジニアって設計者としてやっていけなかった落ちこぼれがなるもんだよ
ドキュメント作成とかすんの?めんどくさそう
怒られる
昼食
怒られる
定時
怒られる
終電前
退社
スマホいじる
スマホいじる
スマホいじる
パソコン消す
かわいそう
設計はしないの?
>>14
俺は下っ端だから
作ってって言われる時は関数単位?
そういうときってなんかフローチャートとかくれるの?
リコーでソフトウェア弄ってた時は死ぬかと思った
打ち合わせ用の資料作成
打ち合わせ
打ち合わせによる変更まとめ
現場指示用の資料改稿
進捗管理用の資料作成
打ち合わせ
打ち合わせによる変更点まとめ
以下ループ
>>15
やだよプログラミングしたい
>>16
いいな楽しそう
なぜ死ぬかと思ったのか聞きたい
>>17
打ち合わせとは一体……
楽しい設計実装より
クソくだらない打ち合わせやら
ドキュメント作りやら
ダルいテストやら
の方が長いな
ドキュメントってどんな奴作るの?
>>22
例えば
お客さんと仕様調整するためのもの
機能の概要を洗い出して可視化するための仕様書
複数のモジュール間のIFを定義するための仕様書
具体的な実装方法を
漏れなくテストするためのテスト仕様書
テスト結果を報告するための資料
バグった時の修正や再発防止策の文書
色んな人間が複数人で分担する以上
お互いの認識を一致させる必要があるわけで
「誰が読んでも解釈の余地なく同じ意味で伝わる」
資料が必要になるんよ
詳しく書いてもらってすまんな
ある程度プログラムできないと仕様書とか設計書って書けないと思うんだけど
そういう設計書って分担して書けるもんなの?後から設計ミスとか発覚しない?
>>32
設計はある程度経験を積んだ人が書くよ
新人は設計書読んで実装するところからやるね
で、分担出来るよう
概要設計書で、機能を実装するに必要なモジュールにいくつかに分ける
その後インタフェース仕様書でモジュール間のIFを決める
設計ミスは起こる
可能な限り発生しないように複数人参加して仕様書をレビューをする
仕様書をみんなで叩いて叩いてミス漏れ間違い曖昧さを潰す
というように、何をするにしてもドキュメントが必要になるんだ
ありがとう、参考になる
ドキュメントが必要になるのはわかった
「ドキュメントを変更するのがめんどくさいからプログラムを変えたくない」みたいなことが起こりそうだなと思った
俺は軽い吃音もちだからプログラマーになったが自分のペースで納期内に作れるようになりさえすればあとは天国
なにしてても怒られないぜ
ドキドキの就活なんだ
ミーティングとエクセルカチカチとメールが作業の7割
>>25
SIerってなにすんの?
>>26
プログラマーとは一体……
まぁフリーランスだしな
趣味のプログラムは楽しい
理由は一人で作るから
プログラマーという仕事は苦痛
理由は一人で作れないから
これが全てなんですよ
プログラミングが好きなら仕事じゃなく趣味でやるのがいいんです
メンバー間での認識のすりあわせは大変だとは思う
友達とプログラム作ってるのは楽しいんだが会社ではそうも行かないか
俺の一日
起きる
会社行かない
仕事する
飯作る
食べる
寝る
普通……じゃないな
会社行かなくていいのかよどういうことだ
>>35
自分で会社やってると便利だよね
客先には週2くらいで行ってるんだがw
フリーランスとはいえプロジェクトに参加してるなら会社いくもんだと思ってた
そういう形態もあるんだな
授業で書かされて意味ないと思ったんだが
「こういう感じでいけばいいと思うんですけどどうですかね?」的な時の資料としては作る事がある
あとは、作った後の「こういう感じで処理してます」って報告用
>>40
あんまり書かないな
フローチャートの粒度なら
ソース書いたり読んだりすれば良いと思う
が
相手によって「ソース読めばいい」は通用しないので
書くことはある
そういう現場もあるよ
おすすめ記事
コメント
トラックバックは利用できません。
コメント (0)
この記事へのコメントはありません。