プログラマーとして一番大事な能力
タッチタイピングは必須だけどタイピング速度はそれほど必要ない
エディタを使いこなして効率よく編集できる力のほうが大事
できるだけ脳の負担を小さくして
できるだけ少ないタイプ数で目的を達成しようとするのが
プログラマー的思考 >>131
記号を正確に入力出来る能力が高いといいな。エディタの補完なんかは記号入力起点が多いから。
ホームポジションから離れることが多いので大体タッチタイプできても、記号来るとなんか崩れるんだわ。 アイデアをダーって出力したいときに、タイピングが遅いとアレだなとは思うけど、普通は考えている時間の方が断然長いしな…
でも、タイピングは速い方がいいね 3DSに鬼トレというゲームがあるが、これの鬼計算がある程度できないと厳しいと思う
複数の変数・関数を脳のワーキングメモリに入れることが出来ないと
しょっちゅうアノ変数どんなんだっけ?関数どんな動きしたっけ?って確認する作業が発生して時間の無駄だし間違いも発生する。
趣味ならいいけど仕事でプログラマーを選ぶのはやめておいたほうがいい いや関数とか変数にわかりやすい名前つけてればそんな能力いらないだろ
function_001()
var_001
とかそういう世界で生きてるなら必要かもしれんがw 関数を使うなというアホな理論がありましてね
ユニケージとかPOSIX原理主義っていうんですけど >>134
一番大事な能力ではないが
あきらかに試行回数が品質に差を付けている場面はある >>137
仕様書と一致させることが大事な職場だとそっちのが楽
response
responce
とかくだらないことで時間取られない >>140
アプリケーションの生産性よりも
仕様書と一致させることが大事だってことですか? 訂正
ソフトウェア開発の生産性
仕様書と一致させることが大事だってことですか? >>137
わかりやすい名前を付けても、脳のワーキングメモリに複数の変数名・関数名を
とどめておくことが出来る人と出来ない人に別れて、出来ない人は職業プログラマーには向かないでしょ? そこは職業プログラマーじゃなくて
単にプログラマーでいいでしょ?
わかり易い名前の価値が理解できない人が作ったものなんて
怖くて使えないよ >>142
うん
正直デカすぎて通しで動いたときの動作なんて誰も把握できないし >>145
でかくて把握できないから小さい関数作るんでしょ
論理が破綻してるぞ >>146
それ俺の元の主張と何か食い違うことある? 136
複数の変数・関数を脳のワーキングメモリに入れることが出来ないとプログラマーを選ぶのはやめておいたほうがいい
137
いや関数とか変数にわかりやすい名前つけてればそんな能力いらないだろ
138
仕様書と一致させることが大事な職場だとそっちのが楽
140
仕様書と一致させることが(ソフトウェア開発の生産性にとって)大事だってことですか?
145
うん
146
論理が破綻してるぞ
147
それ俺の元の主張と何か食い違うことある? コミュニケーションが伝わらない原因は>>140の日本語が破綻してるから
>仕様書と一致させることが大事な職場だとそっちのが楽
そっちってどっち?
意味不明
こんなのはスルーすべき 仕様がどんどん変わっていく環境というのもあるぞ。開発中のOSとか。
OSの新しいコードをチェックアウトしたら自分のコードがビルドできなくなったり
新しいOSビルドで「あんたのコードにバグがあるよ」ってバグレポされたり。俺じゃねー
そういうのは逆に変化についていく能力も重要。 >>151
これが意外と多いんだよな
対応するのが面倒になってくる だからといって対応しないと、ユーザーに価値を提供できないわけで
そういう変化に対応しやすい設計を作る能力というのも
プログラマーにとって大事な能力
ひどいやつだと、対応するのが難しいから、
そんなのは作らない主義ですとかいって
逃げるやつもいるからなw 素人が趣味でやるのはどうぞって感じだけども...
デヴィッド・カトラーとかまだコードを書いたりしてるのかな まあ俺様一人が作るなら仕様書なんて要らないんだけどさ 昔は1日1万行ぐらいコードが書けたが、最近駄目になってきた
プログラマーとしての能力が失われてきている感じだ 最近だめになったんじゃなくて昔からずーっとダメなんだよ
プログラマーの能力がないから1万行も書いちゃうわけ
それに今も気づいてないんでしょ >>159
わかる
ワイは統合失調症発症してから1行も書けなくなった スレチ
プログラマーとして一番大事な能力が1日1万行書く能力として終わるならいいが1万行も書けたと自慢したいだけ 名人プログラマーは遂にはプログラムを書くことを忘れ果てるのだよ ルーチンをコピペで増やして1万行ではなかろうな…
10年くらい前までそういうコードばっか書いてた会社勤めてたけど
5年前にやらかして2年後に潰れたから正解だった 1万行オナニーコード書くより
コードを1行追加or修正して色んな人にレビュー指摘して貰う方が遥かに成長出来る 100行の関数を1日10個で週5日の2週間やると10000行増えてる
事前に細かいとこまで設計やってるとこのペースはよくある 週2日出社、週2日在宅の週4日勤務が最高の働き方だと提唱したい
週休3日制になったら給料を減らされる??そんな考えだからいつまで経っても貧乏なんだよ...
サラリーマンが副業でプライベートカンパニーを設立するメリット
Webマーケターに転職して、セミリタイアを実現させる方法
【朗報】「在宅勤務OK」の求人、コロナ前と比べて7 7倍に上昇!
【悲報】「会社員に戻りたい!」というフリーランス、全体の3%しかいないw
【悲報】副業が解禁されても、副業を見つけられずに困窮する会社員が続出...
日頃から副業をやっておくことの重要性を再認識しよう
【驚愕】5人に1人は本業よりも副業収入の方が多いことが判明w 本業よりも稼げる副業とはなんなのか?? >>169
超短期間で見積りを出す場合
解析工数は行数で出すとハズレがないぞ 超短期かどうかじゃなくて
同じことの繰り返しをする場合だろ >>173
はい、想定していますよ
ユニケージエンジニアの作法その一 forやwhileなどの繰り返し構文の使用は控える
https://uec.usp-lab.com/JOURNAL/CGI/JOURNAL.CGI?POMPA=SAHOU_journal02
ユニケージではforやwhileは
現場の作業員が読むのに苦労する
難しいものであるという前提です 他所の業者が造ったプログラムを引き継ぎで仕方なくメンテしたことがあるが
ソース観たらまじでfor使わずに
a[0]=1;
a[1]=2;
a[2]=3;
printf("%d", a[0]);
printf("%d", a[1]);
printf("%d", a[2]);
みたいなのが延々と続いててびっくりしたことがある
前の業者は行数で見積もり出して行数で請求してたのかな >>153
> ひどいやつだと、対応するのが難しいから、
対応難しいと感じてやらずに逃げるのはプログラマーの感覚としては正しいと思うよ
下手に対応して強引に動かせたとしても、その後のメンテ作業地獄を自分や同僚に残しかねない >>176
別のプログラムでforを使ってテキストとして吐き出していたのかも? >>179
そっちの吐き出しプログラムがスゲーきれいな書き方だったら笑うなw メンテする人が暇になって人員削減されないように雑に作ってくれたんだよきっと >>180
こう言うソースジェネレータ作ってると基本誰も見ないのに生成したソースのインデントとかの見た目にこだわってしまうわw >>176
案件ごとに対応するとき既存のコードに触れてはいけないみたいなことがある。
例えば最初に
a[0]=1;
printf("%d", a[0]);
てなったところ追加案件で
a[0]=1;
a[1]=2;
a[2]=3;
printf("%d", a[0]);
printf("%d", a[1]);
printf("%d", a[2]);
となって最初のコードに触れてはいけないからへんなことになる
そして可読性も失われる >>176
forが使えないプログラマを派遣で雇ったことがある。すぐに追い返したけど。 >>178
あーそっかーループを使うより速いよね。 っておい たとえば、九九の2の段を表示したいとする。手続き型プログラミング
言語的な発想でシェルスクリプトを書くと、次のようになる。
for i in 1 2 3 4 5 6 7 8 9; do
echo "2×${i}=$((2 * ${i}))"
done
ユニケージ開発手法では次のように記述する。
echo "2×1=$((2 * 1))"
echo "2×2=$((2 * 2))"
echo "2×3=$((2 * 3))"
echo "2×4=$((2 * 4))"
echo "2×5=$((2 * 5))"
echo "2×6=$((2 * 6))"
echo "2×7=$((2 * 7))"
echo "2×8=$((2 * 8))"
echo "2×9=$((2 * 9))"
ユニケージ開発手法では上から下に読めるというメンテナンス性を強く意識している。
プログラミングに慣れていない現場の作業員は、繰り返し構文がでてくると理解が及ばないことがある。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 162以降1レスも投稿してないが
プログラマーとして一番大事な能力が1日1万行書く能力だと言って
1万回の繰り返しを1万行にループ展開してメンテナンス性を上げようとマジで言ってる?
スレチすぎて話題について行けなかった >>187
そこから3の段を作ろうとしてすべての2を3に書き換えてしまうんですね 一番大事ではないけれど
そういう泥臭い作業をやらされる案件でも、ミスなく素早くこなせる基本能力が要求されるな
タイピング速度、エディタの使いこなし、タイプミスの発見能力が必要だ 普通のプログラムじゃないけど手書きのMakefileの中にずらーっと似たようなルールが
書かれていたのを見たことはある。
あれはループやワイルドカードは使わない方がよかったのかな。 >>193
内容が同じかどうかではなく、独立した機能かどうかで決める >>194
例えば .cpp から .o を作るルールが、丁寧にすべてのファイルに対してずらーと書いてあった。
ワイルドカードも使える一方(コンパイルオプションが違ったりしない限り)、なんらかの事情で
あえて明示的に書く理由もあるのかなと。 >>197
なんだか私の makefile と同じですね
.c.o:
$(CC) $(CFLAGS) -c $<
.rc.coff:
$(RC) -i $< -o $@
$(EXE): $(OBJS) $(RES)
$(LK) $(LDFLAGS1) -o $(EXE) $(OBJS) $(RES) $(LDFLAGS2)
sss.o: sss.c sss.h debugout.h wmalloc.h maindialog.h buttonok.h editip2connect.h registry.h thread.h editproxyip.h backgroundcolor.h
debugout.o: debugout.c debugout.h wmalloc.h sss.h
maindialog.o: maindialog.c maindialog.h sss.h debugout.h rbutton.h cmbomyaddress.o cbproxyavailable.h buttonok.h editport.h editinterval.h editip2connect.h editproxyip.h backgroundcolor.h
registry.o: registry.c registry.h debugout.h sss.h
... もう嫌だ… if(flg == 0){
flg = 0;
}else if (flg == 1){
flg = 1;
} flg == 0 ? 0 : flg == 1 ? 1 : flg >>174
"for を使えばこんなに簡単にまとめられます" と、まったく逆ベクトルだな。
"for を消す" で、「再帰使うのかな〜」とか思って読んだら顎が地下にのめり込むねこれ。 >>197
>例えば、.cpp から .o を作るルールが、
>丁寧にすべてのファイルに対して、ずらーと書いてあった
そんな事を書いている人が、他にいる? エラーの時にブログじゃなくてドキュメント読もうとする意欲 >>209
ドキュメントの不備に絶望して、ライブラリソースを苦もなく読むようにw >>207, 205
男性限定であれば、宮台真司信者である私としては、これらは装備したいものですね… >>210
ソース非公開に絶望して、アセンブリ出力を苦もなく読むようにw 趣味のプログラミングは念入りにテストを実施
仕事では手抜きテストしてチームの協力を煽ぐ 細かいことは気にしない能力
言われたことだけ直す能力
余計なことはしない能力 テスターからバグが上がってきたとき、その人が実際にどういう条件で何をしたかを
詳細に聞き質さないといけない場合はあったな。特にあまり有能でないテスターの場合に。
とは言ってもその人しかバグが再現できない場合があったりしてないがしろにはできないというw バグを上げるときは
その手順とセットで上げるんじゃないのか? いくらいっても頑なに
エラーの出たテスト手順やエラーの出たデータを出さない人いるんだよな
そいつの上司にいっても変わらないし
メールの送信ミスの振りして
このラインのテスター変えてくれって本人に送ったら何故かそいつの上司だけ交代になって
本人が残り続ける地獄があった 低レベルな会社の愚痴をこぼされてもそんな会社にしか行けなかった自分を恨め
って言う感想しかないわ 世の中の9割は筋肉で解決できる。
筋肉を鍛えるべき。 羞恥心
他人にコードを見られたときに馬鹿にされたくない、一目置かれたい、
そうやって綺麗なコードが書ける >>226
それは違うと思うなぁ・・
一目置かれたいとか、エゴはプログラマにとっては害悪だと思う、個人的には。
綺麗に書くのは後々の自分や他人のためだ 体力、筋力、精神力
元気があれば何でもできる
力こそパワー システムが何かを理解できることだな。
IoTの末端だけで解決できることなぞ僅か。 てか、マスターベーションの世界。
システムとして機能するには、上位アプリとの協調仕様が大事。
このメッシュデザイン、システムアーキを理解、構築できるかが、大事な能力。