プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ
こんにちは、櫛井です。 プロジェクトマネージャーやディレクターの仕事というのは多岐に渡りますが、特にプログラマーと上手にコミュニケーションを取り一定の目的を果たすというのはわりと大変なことだったりするらしいです。私は比較的プログラマーとうまくやれているタイプのようなのであまり苦労した覚えが無いのですが、過去10数年で培ったプログラマーと上手くやる方法を紹介していきたいと思います。おまけで「プログラマーに嫌われる６つのこと」も紹介します。 ※うまくやれてるイメージ図 プログラマーと上手くやる方法をざっくり言うと 役割分担として求められていることをやる お互いのTODOを把握し区切りをつける スケジュール管理をしっかりする といったカンジです。ではそれぞれ説明していきます。 役割分担として求められていることをやる そもそもディレクターが求められる役割とはなんでしょうか。Web開発案件におけるデ
Joel on Software - 下っ端でも何かを成し遂げる方法
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2001/12/25 このサイトではソフトウェアマネジメントを扱っている。しかしあなたは経営命令で組織を変える力を持ってないかもしれない。あなたが階級組織の最下層にいる下っ端のプログラマなら、人々にスケジュールやバグデータベースを作るように命令することができないのは明らかだ。そしてあなたがマネージャであったとしても、開発者を管理するのは牧猫するようなもので、違いはそんなに楽しくないことだとわかるだろう。「こうしろ」と言うだけではそうはならないのだ。 ジョエルテストで低いスコアしか取れない組織であなたが働いているのなら、それはいら立たしいことだろう。あなたのコードがいかに良くとも、あなたの同僚がああもまずいコードを書き、あなたは自分がそのプロジェクトに関係付けられていることが恥ずかしく感じられる。あるい
どうせ理系出身者なんていらねえんだよ。
いまさら言ってもしょうがないだろうが、SIerに就職を希望したり内定した人たちに一言いっておきたい。 http://blog.miraclelinux.com/yume/2007/11/post_1ab2.html http://d.hatena.ne.jp/itoyosuke/20071101/1193932945 http://www.atmarkit.co.jp/news/200710/31/ipa.html 元の報道や参加者のブログエントリ見たりすると、ありがち過ぎて泣けるのだ。はっきりいうと、SIerの人事は情報工学科出身者は求めていない。それどころか理系出身者すら求めていない。 口先では求めているというよ。また、現場で最後に「技術的になんとかする」のは理系に期待されることが多いし、実際に期待通りに解決するのは大抵理系だ。しかし評価はされないし感謝もされないよ。とくに給料に反映す
製品モデルと作品モデル : 404 Blog Not Found
2006年07月24日14:00 カテゴリValue 2.0 製品モデルと作品モデル 我が畏友、宋さんらしい問題意識なのだが、しかしその解決法は根治術とは言い難い。 社会貢献うたうＩＴ経営者の偽善??過労自殺が語る業界の労働事情?ビジネス-最新ニュース:IT-PLUS この現状を食い止める方法があります。それは労働時間の長さで差をつけられないようにすることです。労働時間を平等に８時間に制限しておけば、作業量に対して人月数を積んでいくモデルは崩壊します。 なぜなら、労働時間、いや、コードに触れる時間を制限してしまうというのは、責任感あるすぐれたエンジニアであればあるほどむしろ辛いものだからだ。 「あと５分あれば、このバグを潰せる」といった時に、「本日の就業時間は終わりました」と言われて退社しても、次の出社時間まで、そのバグのことで頭がいっぱいで休めない。エンジニアというのはそういう生き物だ。
そういえばコーディング…… - finalventの日記
昨日だったかはてな社長の訓辞みたいのがあって、ふーんと読んだが。 これはなんの学術団体でもあるレベルがそろうと起こるのだが、外部とのコミュニケーションが事実上無くなる。しかたない面がある。 ま、話を端折ってコーディングだが。 むかし、プログラマやっていたとき思ったというか、当時はそういう問題意識が大きかったというか、今思うと、製造業の世界だったのかな。コーディングというのはプログラマに閉じていなかった。 話を端折るが、いいコーディングというのは困ったものだった。 そういえば、思い出すが、あるCOBOLのプログラムを直せと言われて、ほいっと、Pascal風っていうかに書き換えて、単体チェックもしてＯＫだったのだが、上司（高卒）のＳＥに叱られた。というか、微妙だった。こういうコードを書かないでくれ。これが正しいのというのか構造化というのかもしれないが、ちゃんとread at endでこう書いて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記