  |
はてなキーワード: ソースコードとは
https://b.hatena.ne.jp/entry/s/qiita.com/ko-flavor/items/e7a60bc897965943e0a0
ソフトウェアに適しているドキュメントは設計書ではなく仕様書だ。
なぜソフトウェアに設計書という場違いな概念を持ち込んでしまったのだろう？
ましてエクセルで書くなんて。
ソフトウェア構造はプログラミング言語以上に表現に適した記法はない。
プログラミング言語以外のソフトウェアの構造を表す記法には例えばUMLなどがある。
しかしUMLは概要を表現する（モデリングする）にはいいかもしれないが、設計をしっかりと表現するには無理がありすぎるのだ。
エクセルを使い、一般的にもなっておらず規格化もされていないオレオレ記法で設計を表現しようとするなんて、さらに無理がありすぎる。
エクセルで設計を書いているという現場では、きっとエクセルでの「設計書作成」という本来すべき設計とは程遠いブルーカラー的仕事にばかり力をいれ、まともな設計もされていないのではないか。
それに設計書作成に注力するあまり、まともな仕様書など書かれていないのであろう。
仕様に基づいて書かれたソースコードが設計を表現する。ソースコードが設計書なのだ。
これがソフトウェアに適したやり方であり、だからこそ仕様がしっかりと実装されているかどうかを読み解けないようなソースコードはクソと言えるのだ。
頼むからセンスのない奴はプログラマにならないでくれ。迷惑だから。
これが最もプログラマになってはいけないタイプ（犯罪行為などの言うまでもないことを除けば）。
たとえば
等。
不要なものを作ることで、プログラムは複雑になり、メンテナンスの手間は増え、バグは発生しやすくなる。
一定レベル以上のプログラマが最も自然だと同意するような実装（「実装しない」という選択肢もふくめて）をパッと思い付けない奴は、センスが足りていない。
将棋で言えば、駒がぶつかったら先ず取る手を考えるといった基本的な手筋が思い浮かばないようなもので、現実的に使い物にならない。
これは、「Code Complete」「The Pragmatic Programmer」等の著名なプログラミングの本に共通する結論である。
これが「The Pragmatic Programmer」にあるDRYの原則である。
要するに、すべての情報が単一のソースから決定されるべきということだ。情報が二重化すると、それらの間で不整合が生じバグの原因になる。また、二重化した情報は、修正の手間が二倍になる。
たとえば、ユーザーのプロフィールを管理するレコードやクラスに「生年月日」と「年齢」を同時に保持する必要はない。年齢は生年月日から計算できるからだ。
世の中には、「xxxFlag」みたいな不要な変数を作ったり、共通のロジックを抽出せずにコピペコードを濫造するダメプログラマーが多すぎる。
もちろん、合理的な理由があって、この原則が適用されない場合もある。
たとえば、多くの言語組み込みの配列や文字列は、その要素と長さを二重に管理している。配列の長さは要素を数え上げることで求まるが、それには要素数に比例した計算時間がかかるためだ。
ただし、こういう場合でも、公開されたメソッドによる操作では、必ず内部の変数は同期されるように作ることが可能である。それをしないのは、怠慢でしかない。
一文字変数とか連番とかは論外だが、「ary」とか「setData()」みたいな何の情報も伝えないような変数名・関数名を付けるやつ。
正直、コードの読みやすさなんて6〜7割くらいは変数名の付け方で決まると思っている。
名著「The Art of Readable Code」も、半分以上が変数名の付け方に関連する内容だ。
なぜ変数名が曖昧になるのかと言えば、怠慢を除けば理由は2つある。
1つは、コードを書いた奴自身が、そのコードの機能を明確に言語化できないということ。
もう1つは、1つの関数で多くのことをやりすぎたりしていて、その変数の役割が曖昧になっているということ。
たとえば、関数の内部で宣言した変数は、多くの言語では関数の外からは参照できない。
スコープは狭い方が良い。これはほとんど全ての状況に適用できるプログラミングの大原則だ。
スコープが広いということは、ソースコードの多くの場所からその情報を参照・変更できることを意味する。
たとえば、クラスのメンバ変数は各々のインスタンス内でしか参照できないが、静的な変数はすべてのインスタンスが共通に持つ。このため、静的な変数を変更すると、すべてのインスタンスに影響を及ぼし、影響範囲の把握やテストが困難になる。
スコープを広げるか狭めるか、2つの選択肢があったとして、広げる方に心が傾く奴は、プログラマをやめた方がいい。
結果的にメンテナンス困難なコードを生むというのも勿論だが、単に書くだけでも、スコープが広い方が書きづらいのだ。つまり、必要もないのにわざわざ変数のスコープを広げようとする奴は頭のおかしい奴しかいないということになる。
複雑なメトリクスなどを持ち出すまでもなく、たとえば1メソッドの行数が何百行もあるとか、1クラスのメンバ変数が何十個もあるとか言うの。
これは論外である。プログラマとしての能力云々以前に、明らかな怠慢であり、社会人としての常識が疑われる。
定期的にメンテナンスされ続けているOSSのソースコードなどを見ると、関数（メソッド）の行数は平均して5〜10行。20行を超えるものは稀である。
長いものであっても、外部で定義した関数を順番に呼び出しているだけであったり、リクエストをハンドリングして各々の処理に振り分けているだけのようなものがほとんどである。
それを超えているコードは、合理的な理由があってそうなっていることよりは、単に悪い設計であることの方が多い。
これらは実はプログラミング云々というより、内容の理解力や国語力の問題なのである。
ある情報を得るために必要十分な情報は何かが分かってないから、余計な変数を作ったり、無駄に変数のスコープを広げたりする。
そして、自分が作るものを正確に理解していないから、適切な名前がつけられないし、適切なモジュール分割ができない。
それがすべての原因。
こういう人がまず身につけるべきは、プログラミングのテクニックではなく、日本語を正しく読む力。
低学歴が「プログラミングなら自分でもできるかも」なんて思っちゃいけないってこと。もちろん、下請けのSIerとかで使い捨てのコード書きとして働くことはできるが、上に書いたような最低限の力がないなら、それ以上を望んではいけない。
ちなみに、上に書いていることと反対のことを思っている人も世の中にはいる。
特に、昔からプログラミングをしてきた自称ベテランに多い。その人は、能力があるというよりも、単に現代の開発に際して必要な知識がないだけなので、真に受けないように。
また、大学でコンピュータサイエンスの基礎を学びたての学生なども、知識をひけらかしたくて上と反対のことを言う傾向がある。その程度のことは、良識のあるプログラマはみんな分かっているのだが。
今、プログラミング界隈ではmaster/slaveやblacklist/whitelistのような、ある文化的背景を持つ人にとっては差別的表現になりうるモノの表現を変えようという動きになっている。代案としては色々あり、例えばmaster/slaveはprimary/secondary、blacklistはblocklistというふうに変更しようという案が出ている。
正直言葉狩りや言葉遊びの域を出ないという心情が大きいのだが、ナチュラルに差別に怯える人々や、ナチュラルに無自覚に差別をしてしまっている我々の意識は変えないといけないというのも理解できるので、プログラミングがBLMに関係ないと言い切る勇気は俺にはない。
というわけで本題なのだが、「〇〇という言葉／作法は、××という意味に捉えられますので、〇〇は不適切です」という理屈と軟膏は何にでもくっつくことを実践し生業としていると言えばマナー講師であるのだが、これがプログラミング界隈に進出してくる気がする。近い将来、ソースコードに意図せずうっかり差別的表現を使ってしまい訴訟されるリスクをヘッジするために、プロのマナー講師による講習、ソースコード監修が必要になるかも知れん。俺は悔しいぜ。マナー講師が俺の書いたプログラムにダメ出しして、プルリクにmanner_ violationとタグがつけられてマージ拒否される未来を想像したらよ。それをされるくらいならIPAの高度技術者試験に「プログラミングマナー技術者試験」なるものが追加して欲しいのだが。俺は死ぬ気で取るぜ。マナー講師に命令されるくらいなら、俺がマナー講師になるって言ってんだ。
私は21年の新卒であり、志望分野はWeb系のプログラマだった。
選考を受けた各社に関してその選考フローと所感について述べる。
昨年2ヶ月間インターンシップに参加した。
エントリーシートの提出、技術問題 (コーディング2問、作文1問 制限時間60分)。
コーディング問題は1問目が簡単なもの、2問目が少し複雑なもの。
競プロ的なアルゴリズム力が求められるものではなく、HTTPリクエストに関する基礎的な知識が要求される。難易度は高くはない。
日本語力が要求されるわけではなく、字数制限なども特にない (あったかも)。
当該分野に造詣が深ければ無限に書けるし、なければ書けない。
人事担当のエンジニア*2との (オンライン/オフライン) 面接 (60分)。
オーソドックスな質疑応答の他、提出した技術問題のコードや作文の内容に関する聞き取りなどもある。
ここで落ちた。
CEO、シニアエンジニア、新卒エンジニアなどを交えての面接 (らしい)。
1次面接の面接官の片方が、インターン参加時のメンターの1人だった。
面接の1週間前に面接官のTwitterアカウントをブロックしたのが悪かったのかもしれない。
「(技術力が基準以上あるのは前提として) その水準の如何よりはむしろ勤労意欲の有無を重視する」みたいなことを言われた。
インターンの成果報告をD社の技術ブログに書いたが、腹がたったのでそれを削除しようかと思った。
ここのサービスは二度と使わない。
Ruby本体にコントリビュートした経験があったのでそれをアピールできるかもしれないという意図で受けた。
エントリーシートの提出。
ここで落ちた。
落ちたので知らんが同社を受けた知り合いによると5次まであるらしい。
1次面接の際に「何がしたいのかわからん (意訳)」みたいなことを言われた。
何がしたいのかと言われれば労働がしたくない。
また「勤労意欲の有無を重視する」みたいなことを言われたのでまあそういうこと。
ここのサービスは二度と使わない。
Web系。
前述2社を落ちたあと2週間くらいなにもやる気が起きなかったが、ここなら受かりそうな気がしたので受けた。
エントリーシートの提出。
シニアエンジニア*2との (オンライン/オフライン) 技術面接 (60分)。
自分の関わったプロジェクト (分野問わず) のソースコードを提出するよう求められ、当日はそれに関したディスカッションを行った。
人事、CTO、その他社員を交えたオフラインでの面談 (60分)。
内定。
Web系。
I社と同時にエントリーシートを提出した。
エントリーシートの提出、技術問題 (コーディング3問 制限時間60分)。
人事との面接 (45分)。
内定。
2次面接の際にインターンに参加しないかという打診があったが、D社に落ちた経験がトラウマになっていたので断った。
人事担当者の意思決定が全体的に遅い印象があり、特にCOVID-19や緊急事態宣言のために3次面接と最終面接との間が3ヶ月空くことになった。
複数の退職エントリに書かれている内容に関して、その真偽を社員にたずねたところすべて事実であるという証言が得られたためエントリーを取り下げた。
エントリーシートを提出したところ人事から企業説明会の案内が届いたが、その宛名が全く知らない人間の名前だった (おそらくコピペミス)。
I社を辞退し、O社の内定を承諾した。
D社・N社に落ちた経験から、同輩および後輩に対しては確固とした「「「勤労意欲」」」を持つことをおすすめする。また、面接担当者のTwitterアカウントはブロックするべきでない。
まぎらわしいと 感じる人が 調べたんだ。
あなたの技量が少ないのではなくて、紛らわしい相手が悪いんだ。おもしろいね。
プロが見て、まぎらわしくつくってあるんだろうね。
ではなんで？
僕 あなたに 文句言われるほど お金もらってないよ？ 実害ならともかく
なんで 無料のソフトや 無料のソースコードに まぎらわしいとか すこしバグが有るとか 文句言ってるの？ 有償版があります というときに 有償版で直してあるバグって 全部直さないといけないの？ ソースコードがあって、自分でも治せるよ
そういうのって、犯罪なの？
無償版では 多少のバグは直してない しんこくなものはなおしてある 有償版は ちゃんと直してある って犯罪ですか？
どうして、まぎらわしいとか いうんだろう。
自分たちが作った、自分たちの作品 こうして、まぁいうだろうね。
でもまぎらわしいといわなくていい
これだと、じぶんにはわかりにくいから、こうしてくれ。
そのひとにとっては、こっちのほうが見やすかったんだろう。
本当に迷惑なんだ
たとえば、オセロを作るとき、ふつうの人は「指定のマスに石をおけるか」「石をひっくり返す」などのユーティリティを作って、それを組み合わせて作る
そうすることで実装は簡単になるし、各操作は独立にテストしたり修正したりできる
ところが、自称プログラミングできるやつの4人に1人くらいは、すべてのロジックが同一スコープ内で渾然一体となった複雑なソースコードを書いてくる
正直、そういう奴は考えていることが違いすぎて、具体例を思い付くのが難しいのだが、たとえば「石をひっくり返す操作」と「黒石の数を数える操作」は独立に実装した方がいい。ところが、奴らは「石をひっくり返しながら、黒石の個数の変数を更新する」ということをやる。石の数なんか高々64個なので、こんな最適化の意味はない。これだけならまだ良いが、奴らはあらゆる処理を無理やり同じ関数内で実装しようとする（独立した処理を順番に行うだけならまだ良いが、上の例のように、積極的に関係ない処理を互いに依存させたがる）から、もうわけ分かんなくなる
そういうコードがダメな理由はいくらでも説明がつくが、そもそもそういうコードを書いてくる奴は頭がおかしいというのが根本的な問題なんだ
こういうやつは、コードの品質が低くて他人に迷惑をかけるのはもちろんなんだが、それ以前にものごとを整理して考える力が極端に低くて、技術的な内容のコミュニケーションが成り立たない
git とか使ってるなら戻せるんだから消しておけ が主流だと思う
自分も以前はそう思ってた
だけど、過去バージョンから戻せるのはそれを知ってる人、基本的に作ってその修正をした人なんだよね
引き継ぎで渡されたものとか過去に何があったか知らないし、戻すだけで良くても戻すものがあることを知らない
引き継いだときに何千とかあるコミット全部を確認なんてするわけないし、コミットがきれいにまとめられてなくてコメントも「修正」くらいしか書いてないのだと見る価値ないから全くと言っていいほど見ない
そういうことを考えるとコード中に残した上でコメントとして「〇〇するための機能、✖✖ならこのコメントアウトを解除すればいい」みたいなのが残ってる方が助かる
コメントアウト部分はメンテされてないからそのままでは動かないかもしれないけど、他人が作ってどこをどう修正すればいいかがわかりづらいものだと、なにもないよりは参考になるものがあってそれを少し直す方が楽だし
少なくとも、ちゃんとソースコードが読み書きできて、Git等の必須のツールが一通り使えれば、小売や飲食よりマシなとこはあると思う
もし、諸君が「コンピュータの技術を活用して、世の中を便利にしたい」という願望を抱いているなら、絶対に日本のIT企業に就職してはいけない。
日本の企業では諸君の想像するようなわくわくするような開発体験は決して得られない。
諸君が、コンピュータの技術を真摯に学ぶ気があり、最新の技術とハイレベルな開発者から刺激を受けたいのであれば、オープンソースのプロジェクト等に貢献すべきだ。
以下、なぜ日本のIT企業に就職するべきではないのか、理由を述べる。
特にBtoB（法人向けサービス）の開発に顕著だが、日本で就職する限り、作るのはコンピュータリテラシーの低い老人向けのクソ下らない業務システムがほとんどである。
信じられないかも知れないが、「手書きの文書を読み取って、FAXで送信する」みたいな無駄なシステムは、今なお日本中で生産され続けている。
そもそも顧客自身が、そのシステムで本質的に何を実現したいのか理解していないため、従来のやり方をそのままシステム化することになる。
こうして、コンピュータを用いる利点が全くない「アナログ業務をパソコンの上で行うだけ」のクソシステムが出来上がる。
はっきり言って日本の平均的なエンジニアのレベルは、その辺の学生未満である。
アルゴリズム、オブジェクト指向設計、メモリ管理、セキュリティ等のプログラミングの必須事項を十分に理解しているプログラマは、全体の1%もいない。
下請けのカスにもなると、ググって出てきたコードを内容も読まずコピペして、「動いた」だの「動かない」だのとやっているのが大半である。
自動テストやCI等はおろかソースコードをバージョン管理すらしておらず、本番環境へのデプロイは手動で行っており、数万行を超えるコードがmain関数にベタ書きされている等という例は珍しくない。
諸君がいくら最新技術を学ぼうが、仕事で任されるのはほとんど、そういう連中が生み出したプロダクトやツール群のメンテナンスである。
こうしたクソプログラムは、一度作られたら最後、メインプロダクトが完全に死に絶えるまで、死神の様に付き纏う。
日本で職業エンジニアになっても、何の役に立つのか分からんクソシステムしか作らないし、無能の書いたクソコードのメンテナンスで精神病むからやめろ、ってこと。
そういうときはバックアップも全部捨てて、コードを会社に置いてくる。うたがわれないようにな。
資金切れで、どうしようもなかったんだと。思ってくれればいい。
10年超のプログラマやってるものだけど自分の成長過程を書いてみよう
おっさんさ？
フレームワークどころかwebpackが何か知らねえだろ？
時間がない？書き方知らねえんだろ？
Gitもaddとcommitとpushしかできないですよね？
前のやつ戻す時にソースコードいちいち書き換えてどうすんすか？
revertってのがあるの知りません？
おれがレビューしたら平気で別の箇所コピペしたから問題ないとか言うの恥ずかしくないんすか？
さっきも言ったけどあんた恥ずかしくないんすか？
文脈読めてないのか
選民思想が高いという話の後に
「ソースコードを思案してる最中は意識が飛んでるので話しかけられても困ります」みたいなツイートがバズった時にも思ったけど他の職業は頭使わないとでも思ってるんですかね？
なんだから
「プログラマーは『他の職業は頭使わないけど俺らは使うから話しかけられても困るんだぜ（ドヤァ』と言う」って意味で書いてると分かるだろ
チャットを使ってメンバーへ指示したのよ。「●●だったら変更しといてね」って。
期待する返答は「承知しました」とか「変更済みです」とか、イエスかノーだと思ったのよ。
だけど返ってきた答えは...
《ソースコードを貼り付け》
なんだろう、聞きたい答えを貰うまでに発生する、この無駄に近いやり取り。
だから、いつから、ここはヌーディストビーチになったんだっていうのが、今もめてるんだろうな。
普通は完成品のプログラムを売る。ソースコードを見せろっていうのは・・・だめではないけど
屋台にいったら、おいしかったから、作り方を詳しく教えろって言うようなもの。
発狂寸前なほど自分たちが作ったソースコードの世話に忙殺されて、せっかく東京で働いてても家と会社の往復
その成果は、ストックオプション持ってる厚〇りジェ〇〇ンとかブルーボトルコーヒー日本進出を営業妨害した意識高い系みたいなバカそうなインチキおじさんが幹部や経営者だからと総取りされて
壊れるかアサイン先が不得手なら明日からこなくていいよクビなで放り出されて、精神科と自宅と失業保険受けるための家の往復
そんな仕事やるくらいなら、ロシアか中国の大使館か朝鮮総連にでもいって産業スパイか、イスラム国かアルカイダにでも就職面接してテロリストにでもなった方が100倍マシだろ
