  |
はてなキーワード: ソースコードとは
変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、その利便性からプログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
PythonのフレームワークであるFlaskのソースコードが讀む必要があつて、公式リポジトリを調べる爲に「Flask GitHub」で検索したんですよ。
さうしたら、【Heroku】GitHubで作成したFlaskアプリをHerokuに連携させる - Qiitaと云ふ記事が目に留まつたんですね。
これはおかしい言葉遣ひだな、と思ひました。だつて、GitHubはソースコードのホスティングサーヴィスであって、「Flaskアプリ」を作る機能は持つてゐないのですから。だから、「GitHubで作成したFlaskアプリ」などと云ふものは存在しない。
ところが、ふと後から思ひ返して見ると、もしかしたら筆者の意圖は違ふんぢやないか、と思つたんですね。つまり、「GitHubで」は「作成した」にかかるんぢやなくて、
GitHubで（作成したFlaskアプリを）Herokuに連携させる
のやうに、「GitHubで」は「連携させる」を修飾するんぢやないか、と思つたんです。
この「作成した」は、何かのtoolを用ゐて作つたと言つてゐるのではなく、英語の「You」のやうに、不特定の人の動作を表してをり、そして、「GitHubで〜連携させる」は、「GitHubのDeploy機能を用ゐて連携させる」と云ふ意味だと考へれば、辻褄が合ひます。
より分かり易く書けば
cat filename.jurina
print "Hello world";
public class filename{
public static void main(String[] args){
System.out.println("Hello world");
}
}
と出力するプログラムをjurinaと名付けるとする
cat filename.jurina
int i=1;
print i;
public class filename{
public static void main(String[] args){
int i=1;
}
}
Javaに置き換えて出力するだけのJava プリプロセッサである
言いたいことVMを解析して、OPコードを吐くコンパイラを作ろうとしていたが
このうち定型業務はCOBOLが主力だった時代からどんどんシステム化されてきた。
したがって、今の今までシステム化の手が入っていないのは殆どが非定型業務。
この非定型業務が本当に面倒で、基本設計のレベルから収拾がつかなくなるのだ。
流石に今の今までシステム化の埒外に置かれてきただけのことはあるというか。
とにかくたった一つの業務を取っても、その中で場合分けの分岐や収束がやたら多い上に、複雑怪奇に入り組んでいて、フローチャートにまとめられない。
このフェーズで簡潔なフローチャートにできないものは絶対ソースコードに落とし込めないので、本当に悩ましい。
というか「あんなこともある」「そういえばこういう場合もあるんだよね」と、業務担当者からヒアリングすればするほど理解が進むどころか、むしろわかりにくくなる。
しかも全部ケースを出し切ったと思って要件を整理しているとあら不思議、「あれ？この場合は…」と新たな疑問が何個も湧いてきて、再確認という手戻りが起きる。
そしてそのタイミングで「衝撃の新事実」が発覚し、それがその業務だけでなく他の業務にも大いに影響する話だったりするため、横展開を余儀なくされる。
そんなことが延々と続くため、そもそも設計作業が半永久的に終わらない。
むしろ、実務を担当している末端の人たちの柔軟性の高さが異常とも言えるわけで、よくこんなわけのわからん仕事を混乱せずにできるなあと感心するのだが。
「共通言語たるドメインモデルを、そのままコードと1対1対応しなければならない、という思い込みや風潮。
既存のWAF(Web Application Framework) の利点を潰してどうする…」
こういう誤った思い込みをエンジニアにさせているのは、ドメイン駆動設計の原典である「エリック・エヴァンスのドメイン駆動設計」が、いかに抽象的な内容で、ある意味では哲学的であったかを、明示するものでは無いか。
プログラムとはメタファーであり、現実を、もしくはそれに準ずる写像的な世界観を、コードに忠実に再現するものでは必ずしも無いと考える。この記事の増田は「過度な抽象化」とも書いているが、プログラムというか、そもそも言語そのものが物事の全てを表象できるものではなく、ある一側面の一イメージしか切り取れない不完全なものだし、それ自体が問題ではない。現実とソフトウェアの溝を、ユーザーとエンジニアの溝を、ドメインとソースコードの溝を、いかにして埋めるかというのが、ドメイン駆動設計の本質だし、その埋め方についてはエリックエバンスは一例を示しているに過ぎない。EntityやValueObjectなど、必要なら使えば良いし、不要なら使わなければ良いのだ。ただし、元々何が問題なのか、問題だったのかという点について、いかにして向き合うかが肝要であり、それは技術論や方法論の話ではない。
ドメイン駆動設計の記事を書いたり、勉強会で発表をしている人間は、原典やそれに付随するドキュメントの内容を、無批判に信奉し、そのようにしなければならないという強迫観念に追われているのではないか。そもそも、本当に理解しているか怪しいし、不安だから教科書の内容にしがみつこうとするのだろう。さらにこの手の連中は、昨今のCQRSやイベントソーシングやマイクロサービスなどとも絡めて話をし出すから、タチが悪い。「ドメイン駆動設計はこの手の技術スタックと相性が良い」という言葉を何度も見かけたが、技術的な方法論はそもそも無関係だったはずだし、そうやって安易に結びつけてしまうから、ユーザーが置き去りになって来たんじゃねーのと、暴言でも吐きたくなる。問題の本質はどこにあったのかを、聖典の内容や、流行り廃りの技術とは切り離して、エンジニアは三思九思すべきだ。
別にこうあらなければならないという法律や決まりは無いし、好きにやれば良い。モデルと1対1にならなければ、分割する事を選択するのも一つの向き合い方だ。ドメイン駆動設計の信者ににゃんにゃん写真でも撮られて、ばら撒くと脅迫されているのであれば勿論話は別だ。恥ずかしい写真を魚拓されたくなければ、とりあえずEntity、ValueObject、Repository、Service（笑）位は最低限、用意するのが身のためだろう。
自分の頭で考えて、自分の責任で判断するという当たり前の事に立ち返りたいものだ。ドメイン駆動設計という盲目的な宗教からいかにして抜け出すかが今後のエンジニアの課題だろう。
追伸
○ご飯
朝：サンドイッチ。昼：パン。夜：人参と玉ねぎとシメジと豆腐とたまごのスープ。納豆。
○調子
むきゅーはややー。お仕事は、超頑張った。
「複雑なコードがいくつも絡まった機能でバグ発生、しかも再現性無し」というワクワク案件。
楽しかった。
バグと向き合ってる時の脳味噌が広がってシステムと自分が混ざっていく感覚、気持ちよかった。
ソースコード書くのも好きだけど、バグ対処の時はソースコードよりも広い部分も気にするからより脳味噌広がる感じが好き。
直し方も三案ほど出した。再現方法が普通に操作する分には中々起きないと思うので放置って線もありそう。まあこの辺は予算とか瑕疵責任も絡むので、僕が頑張れるところはひと段落。
○プリコネ
○ウマ娘
キングヘイローで三冠を狙ってプレイしてるんだけど、かなり上振れてくれて皐月賞2位ダービー1位菊花賞1位が出来て、超惜しかった。
ただこんだけ上振れても出来ないなら、もうちょい因子を強化してからこの遊びはすることにしよう。
