アカウント名:
パスワード:
コーディング標準は一応ありましたが、だれも従ってませんでした。自分も一読したけど覚えてません。でも、人それぞれながら自分のルールに従ってキレイなコードを書けていたので、特に困りませんでした。綺麗な街にはゴミを捨てにくいようなものではないでしょうか。キレイなコードを皆が心掛ければ、後に続く人もキレイに書こうとするのだと思います。
あなたを批判するわけじゃ無いけど、おそらく「なぜ標準が必要か」という目的が最初にないと、手段が目的になっちゃうのだと思います。
一番困るのが、ファイル単位、あるいは、機能単位で保守の担当者を決めていたけど、その担当者が継続できなくなるケース。目的の一つに、その担当者しか読めない(他の人が読みにくい)ということを、減少させたいことになるかなーと。
でも、レビュアー(又は後継者)が、ソースを理解する為に考えようとしない姿勢がいかがかと。
昔の話ですが、某F社に派遣で行っていた時にレビューを受けた時、「確かに正常に動いてるけど、(ソースのロジックが)よく分からないから書き直して」って言われた時は、キレそうになりました。
「ロジックちゃんと説明したろうが!!頭使えや!!」って言いかけてギリギリ飲みこんだ記憶が。
#10年以上前の話だから時効だよね?
レビューで「enum の意味が分からないからちゃんと書いておいて」と言われてコメントに言語仕様を逐一書いたことならある。
それだけじゃなんとも言えませんね。
確かに正常に動いているけど、ロジックに無駄がある。俺が書きなおしたら数十行が数行になった。
ってことはよくあるんで。
>確かに正常に動いているけど、ロジックに無駄がある。>俺が書きなおしたら数十行が数行になった。
逆です(苦笑)。
「じゃあどんな風に書けばいいんですか?」って(半分キレ気味に)聞いたら、「なんかテーブルみたいの作ってさぁ、~」と、それだとどう考えてもソースの量3倍&実行時間3倍くらいは想定できる事を言われて、めっちゃ呆れた記憶が。
#ええ、もちろん最終的に喧嘩別れですよ。#(自分の)会社には、ちゃんと謝りましたけど。
状況にもよるかも。テーブルみたいな効率悪いコードは、機能修正でふるまいを変えたりするのが簡単だけど、簡潔に最適化されたコードは、機能銃政治はロジック自体の作りなおしに近いレベルで修正が必要になる。性能上のボトルネックではなく、将来別人の手によって機能修正が必要になることが想定される場合、テーブルみたいな効率悪いコードもありだよね。
コーディング規約は理解以前の話なので。別にコーディング規約に従っていないプログラムでも読めない事はないけれど、そのプログラムそれぞれの規約に従って読み書きすることが全体の生産性を高めることになるかどうか。
あと、気持ちは察するけれど、簡単に理解できるプログラムを書くこともお仕事なのよね。システムの規模が大きくなればなるほど、開発や保守に携わる人間のスキルもまばらになってくるので、それを踏まえて「処理速度の早いプログラム」より「誰もが読めるプログラム」が求められる状況は多々ある。
# ただ、馬鹿に合わせているとスキルが腐るので逃げたのは正解かと
>あと、気持ちは察するけれど、簡単に理解できるプログラムを書くこともお仕事なのよね。>システムの規模が大きくなればなるほど、開発や保守に携わる人間のスキルもまばらになってくるので、>それを踏まえて「処理速度の早いプログラム」より「誰もが読めるプログラム」が求められる状況は多々ある。
正にそれを言われました。「誰もが読めるプログラムを書いて」って。ただ、当時の僕には、どうしても「頭使えば理解できるだろ!?」って考えの方が強くて・・・何が悲しくて「サルでも分かるプログラム」を書かなきゃならないんだって思っちゃいました。今思えば、若気の至りではありましたね。
#転職した理由も、まさにその通りです。そこの会社だと、どうしても某社の影響下なので。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
あったけど (スコア:0)
コーディング標準は一応ありましたが、だれも従ってませんでした。
自分も一読したけど覚えてません。
でも、人それぞれながら自分のルールに従ってキレイなコードを書けていたので、特に困りませんでした。
綺麗な街にはゴミを捨てにくいようなものではないでしょうか。
キレイなコードを皆が心掛ければ、後に続く人もキレイに書こうとするのだと思います。
Re:あったけど (スコア:0)
あなたを批判するわけじゃ無いけど、おそらく「なぜ標準が必要か」という目的が最初にないと、手段が目的になっちゃうのだと思います。
一番困るのが、ファイル単位、あるいは、機能単位で保守の担当者を決めていたけど、その担当者が継続できなくなるケース。
目的の一つに、その担当者しか読めない(他の人が読みにくい)ということを、減少させたいことになるかなーと。
Re:あったけど (スコア:2)
でも、レビュアー(又は後継者)が、ソースを理解する為に考えようとしない姿勢がいかがかと。
昔の話ですが、
某F社に派遣で行っていた時にレビューを受けた時、
「確かに正常に動いてるけど、(ソースのロジックが)よく分からないから書き直して」
って言われた時は、キレそうになりました。
「ロジックちゃんと説明したろうが!!頭使えや!!」
って言いかけてギリギリ飲みこんだ記憶が。
#10年以上前の話だから時効だよね?
Re: (スコア:0)
レビューで「enum の意味が分からないからちゃんと書いておいて」と言われて
コメントに言語仕様を逐一書いたことならある。
Re: (スコア:0)
それだけじゃなんとも言えませんね。
確かに正常に動いているけど、ロジックに無駄がある。
俺が書きなおしたら数十行が数行になった。
ってことはよくあるんで。
Re:あったけど (スコア:1)
>確かに正常に動いているけど、ロジックに無駄がある。
>俺が書きなおしたら数十行が数行になった。
逆です(苦笑)。
「じゃあどんな風に書けばいいんですか?」
って(半分キレ気味に)聞いたら、
「なんかテーブルみたいの作ってさぁ、~」
と、それだとどう考えてもソースの量3倍&実行時間3倍くらいは
想定できる事を言われて、めっちゃ呆れた記憶が。
#ええ、もちろん最終的に喧嘩別れですよ。
#(自分の)会社には、ちゃんと謝りましたけど。
Re: (スコア:0)
状況にもよるかも。
テーブルみたいな効率悪いコードは、機能修正でふるまいを変えたりするのが簡単だけど、簡潔に最適化されたコードは、機能銃政治はロジック自体の作りなおしに近いレベルで修正が必要になる。
性能上のボトルネックではなく、将来別人の手によって機能修正が必要になることが想定される場合、テーブルみたいな効率悪いコードもありだよね。
Re: (スコア:0)
コーディング規約は理解以前の話なので。
別にコーディング規約に従っていないプログラムでも読めない事はないけれど、
そのプログラムそれぞれの規約に従って読み書きすることが全体の生産性を高めることになるかどうか。
あと、気持ちは察するけれど、簡単に理解できるプログラムを書くこともお仕事なのよね。
システムの規模が大きくなればなるほど、開発や保守に携わる人間のスキルもまばらになってくるので、
それを踏まえて「処理速度の早いプログラム」より「誰もが読めるプログラム」が求められる状況は多々ある。
# ただ、馬鹿に合わせているとスキルが腐るので逃げたのは正解かと
Re:あったけど (スコア:1)
>あと、気持ちは察するけれど、簡単に理解できるプログラムを書くこともお仕事なのよね。
>システムの規模が大きくなればなるほど、開発や保守に携わる人間のスキルもまばらになってくるので、
>それを踏まえて「処理速度の早いプログラム」より「誰もが読めるプログラム」が求められる状況は多々ある。
正にそれを言われました。「誰もが読めるプログラムを書いて」って。
ただ、当時の僕には、どうしても「頭使えば理解できるだろ!?」って考えの方が強くて・・・
何が悲しくて「サルでも分かるプログラム」を書かなきゃならないんだって思っちゃいました。
今思えば、若気の至りではありましたね。
#転職した理由も、まさにその通りです。そこの会社だと、どうしても某社の影響下なので。