  |
はてなキーワード: ソースコードとは
まったく同じ処理結果の
異なるソースコード
片方は１００行 片方は１０００行
どちらが大変か・・・
結果が同じならば同じに見える・・・
どうして、コードを短くするか
ただし短きゃいいかと言うと、下手に短くすると機能が落ちたり、処理性能が落ちたり
複雑
何回も難解も つくりなおして、いろんなテストをして
どのコードにするかきめていく。
ソースコード公開というか、そもそもコードを公開できないならGPLを使わずに商業ライセンス版（多くのGPLソフトはソースコードを開示したくない企業のために別バージョンを用意している）
お客さんからの問合せを受けるサービスデスク兼切り分けを行う二次窓口（ソースコードやDBの値を読むかんじ）をやっていた。
地味な作業かなと思いつつやってみると面白いもので、バグを見つけたときダンジョン探索で宝物を見つけたような達成感や、だんだん怪しいところが経験的にわかるような自身のレベルアップも感じられた。
また普通のSEやPGより「本当にサービスを使ってる人の声」みたいなのを聞けるのも嬉しかった。なるほど設計でよく仕上がってコーディングもよくても使ってみたらイマイチって普通あるんだなとか。保守って基本的にコスト部隊として組織では下に見られてるので還流する仕組みがないんだけど。
結局、バグをどんどんインシデントとして上げてたら「捌ききれんから」と首を切られてしまったんだけど保守業務って悪くないもんだと思ったりした。
レアケースだし、環境に依存するから特定のメーカー向け意外にはOFFになっている
３０年ぐらいだけど
かならずこのほうほうでつぶせるとはかぎらないけど
どうすれば会社から排除して、ソースコードを奪えるか？というのは定型化してきたとおもう。
それでもいいっちゃぁいいけど
どうすっかなと言うのを考えるけど
あんまいみのあることでもないし
日銭があればそれでいいというはなしもある。
★
ソートがまさにそうだけど、バブルソートの特異領域N=1,Bigがそうだけど（例示）
ソートアルゴリズムも１つじゃなくて、テキストでもあれだけ教えている。
現場ではどうするか？といえば
採択されたものがソースコードに書かれる。それいがいはブランチに合ったりする。
これらがあるので、いわゆるバイナリやリバースからはソースコードの複雑さは推し量れないし
こういう膨大なテストがあったりするので（俺の場合は少ないが）
リバースだけから学ぼうとするな、ソースコードとアセンブリ結果から学べ
というのはそういうこと
いくつかいったけど、コンパイラの最適化を期待したりしてソースを書いたりするので
そういう書き回しをまなんでいくことも重要
ソースだけになｗ
