  |
はてなキーワード: バージョン管理システムとは
分散バージョン管理システムGitの開発者でもあるトーバルズ氏は、暗号通貨をサンタクロースやイースター・バニーと同じ神話的カテゴリーに位置づけているとユーモアを交えて付け加えた。
彼のコメントは、ビットコインの曖昧な創設者であるサトシ・ナカモトではないかという間違った憶測を含む、技術コミュニティでの議論の中で生まれた。
トーバルズ氏はこのような噂を否定し、Linuxカーネルの編集で自分の名前がユーモラスにビットコインと結びつけられたことを明らかにした。トーバルズ氏は、自分はビットコインの多額の財産を所有していないと断言し、そのような主張の信憑性については否定的であるとの立場を繰り返した。
ソース: https://www.realworldtech.com/forum/?threadid=217627&curpostid=217694
私はWebアプリケーション開発に関わっているエンジニアであり、社内の多くのエンジニアもWebやネイティブアプリの開発に従事しています。会社の規模は日本国内で言えば大きい方です。
そんな会社で働いている中で、最近著名なエンジニアが入社しました。私はその方をSNSなどで拝見しており、どんなアウトプットを出すのかとても楽しみにしていました（ただし、その方は私とは関わりのない部署に配属されています）。しかし、3週間が経過した現在、もやもやすることがあり、この日記を書いています。
まず、前提として、入社して3週間でアウトプットを出せる人は世の中にそう多くはないと思っていますし、それが高い職位で雇用されているなら尚更だと思います。なので、3週間経って何もアウトプットがないのは仕方ないことだと思います。システムに関する知識（解決したい課題、要件、仕様、関係者、社内事情、技術領域などなど）がまったくない状態で、そのキャッチアップに時間がかかるのは誰しも同じだと思います。
しかし、この3週間でその方がどういうアウトプットをするのか見たかったので、バージョン管理システムのログや社内チャットツールで色々と確認してみると、どうもその方は外部の登壇資料を作ることしかしていないようでした(実際には自社の仕事もしていましたが、登壇資料が9割を占めているように見えました)。
この行動に対してもやもやすることがありました。それは、「まず自社に貢献しないのか？」「登壇料をもらっているならそれは副業の範囲内であり、プライベートでやるべきではないのか？」です。その方がどういう期待値で入社しているのか分からないので、もしかしたら登壇も仕事の一環なのかもしれません。それでももやもやします。そもそも、自社の利益にその登壇は本当に貢献するのか？というところです。外部に登壇するくらいなら、自社向けに発表と質疑応答を行い、社内エンジニアの能力向上に貢献するほうが良いと思います。
よくある反論として「自社の宣伝になるから良いのでは？」というのがあります。それも理解できるのですが、それは自社で得られたノウハウを宣伝する場合に当てはまると思います。しかし、その方は入社後ほとんど自社のシステムに関わっていないので、その反論は当てはまらないと思います。
また、副業として登壇料を受け取っているようです。自分には直接の害はないのですが、これって会社から給料をもらっている時間に副業していることになり、副業規定に抵触するのでは？と思いました。私自身も副業でソフトウェア開発をしていますが、本業の時間に副業をしても良いのだろうか？と疑問に思いました。また、それが普通に許されているのもなんだかなーと思いました。まず、自社に貢献しろよ、と。
私がすごいと思うソフトウェアエンジニアは、やはり自社の課題をスマートに解決する方々だと思います。ですから、登壇ばかりしているエンジニアに高い給料を払っているのがもやもやします。
最後に、その方の職歴について思ったことがあります。あまり詳しくは書きませんが、おそらくそれなりに高い職位（テックリードなど）で雇用されていたと思います。職位が高ければ高いほど、成果を出すのに時間がかかると思いますが、その方は結構なペースで転職しています。それ自体は構わないのですが、もしかして自社に貢献できず、居場所がなかったのでは？と勘ぐってしまいます。この勘ぐりを加速させる材料として、その方の登壇や記事にはほとんど自社の話がないこともあります。
実は他にも色々ともやもやすることはありますが、このくらいにしておきます（登壇内容などにも疑問はありますが、それは個人の自由なので）。
まだ3週間しか経っていないので、これからどうなるのか分かりませんが、引き続きウォッチしていきたいと思います。離れた部署にいる人間から見えていることなので、細かいところは違うと思います（思いたいです）。これからどうなるのか、楽しみです。
「ソースコードに間違いが見つからないのに想定される出力をしない。あるいはソースコードに修正を加えていないのにいきなり想定出力を返すようになった。」
こういう経験がある人はいるはずだ。なぜこれが起こるのか。一つの原因を見つけた。
それは環境変数や設定ファイルに存在する。デプロイ時には設定ファイルを特定の値に修正してから、ということがあるだろう。
開発環境でコーディングする人が、デプロイ時の設定ファイルには関与せず、デプロイの担当者がそれを把握している。
開発者はセキュリティ上の理由でデプロイ時の設定ファイルの内容を見ることができない。
この場合、設定ファイルの内容が間違っていても、開発者が原因が正しく特定できないケースがあるのである。
対処方法は以下である。まず事前にやっているであろう対処は以下である。
追記:
他に遭遇したケースは、環境のアップグレードによってphpが特定の関数を廃止したというケースだ。
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか？同じものを表すのに関数ごとに別の変数名を付けているとか？
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか？
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
プログラミングの話題と相性がいいんじゃないかと思って、昔読んだことがある達人プログラマー (1999年に出版された第1版の方、2019年に出版された第2版ではない) をぱらぱら見返してみた。プログラマーとしての姿勢やプラクティスなどは一般に普及したかどうかの判断が難しい。間違いなく一般的になったなと思えるものに絞って書く。インフラ面の進化が大きいと言えそう。
フリーレン「わずか数年で人類の開発方法論に組み込まれ、新しいインフラによってシステム開発の生産性を向上させた。」
でも今のチームはソースコード管理システムを使っていないんだけど……
恥ずかしいと思ってください！ そして、これが伝道師となる機会だと受け止めてほしいのです。しかし、彼らが自ら進むべき道を見つける時まで、あなた一人ぼっちであってもソース管理を使うようにしてください。
フェルン「いまのはバージョン管理システムです。」
いつリファクタリングを行うべきなのか？
コードがうまくなじんでいないと感じたり、まとめるべき 2 つの事柄を見つけたりといった何か「おかしなもの」に遭遇した場合、手を入れることを躊躇してはいけません。
テストの文化
あなたの記述したソフトウェアはすべてテストの対象になります。あなたやあなたのチームの人間がテストをしなければ、最終的にユーザーがテストを強いられるのです。このため、テスト計画を徹底的に練る必要があります。しかし、事前にものごとを少し考えるだけでメンテナンス費とヘルプデスクへの呼び出しを大幅に削減できます。
(中略)
テストは技術というよりは文化なのです。こういったテスト文化は、使用する言語に関係なくプロジェクトに植え付けることが可能なのです。
フェルン「いまのはテスト駆動開発です。」
多くのプロジェクトでは、こういったレベルのビルドは毎晩自動的に実行されています。つまり、プロジェクトの特定部分を夜間ビルドで作成すると同時に、個別のテストよりも完全なテストを実行できるのです。これによって、完全なビルド実行時に行うテストをすべて実行させることも可能になります。結果として、その日のうちに回帰テストの問題を見つけられるようになるわけです。ソースの変更後、できるだけ早い時点で問題を検出できれば、バグの検出と修正を円滑に進められるようになるはずです。
Unity5から長く離れていたほぼほぼ今となっては初学者とみなしてよい者なのですが、
開発環境と最初から選定すべきライブラリのベストプラクティスについて教えて欲しいです。各々のオレオレベストプラクティスで良いです。
想定されるテンプレは
バージョン管理システム:
入れておくべきライブラリ:
入れておくべきアセット:
みたいな感じです。
例えば
コーディング用エディタ: VSCodeになんかよさげなプラグイン
入れておくべきライブラリ: UniRx,UniTask
入れておくべきアセット: 画像や音楽、3DモデルというよりはRewiredなどのロジックを補強するアセットなどが知りたいです
こんな感じでしょうか。
とりあえず上にインシデントを報告するために報告書を書いてもらったんだけど、「NGワードを削除しました」だけだと上の人に詳細に伝わらないので削除した単語一覧と削除した理由も追加しておいてねって報告書の添削をしたら数日後に人事から呼び出しを食らった。
ここれまでの段落の内容と、そもそも本文全体からして増田本人がapproveするとは考えられないから。
「インシデント報告」「削除しました」って書いてあるから、上記に引用した段階ではすでに事後。
となると、masterにpushできたに違いない（PR経由のmasterマージも、自分で無条件マージできるならばmaster pushと一緒）。
また、前段の方で「そのNGワード集に編集リクエストみたいなの」と、「編集リクエストみたいなの」と言っていることから、バージョン管理システムなりの使い方をよくわかっていない可能性が高い。
ふわふわした形でバージョン管理システムを使っているならば、すべての人に全権限を与えていたり、masterマージ時にレビュー必須にするなどの条件が設定されていないということはあり得る。
Git（ギット[2][3][4]）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナは濱野純 (英語: Junio C Hamano) で、2005年7月から担当している。
Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
みんな大好きGAFAMはご存知の通り言論統制が大好きだよ！言論統制はユーザだけでなく社員にも課しているよ！どんなことが言えないのか紹介していくね！
追記：差別用語としての地位を確立していない言葉に敏感になりすぎるとより差別と分断を助長していくよ！これらは包含的言語と呼ばれるけれどもむしろこのような過敏な言い換えを知らないと差別主義者としてのレッテルを貼られるなど階級差別的で排除主義的な行いにしか用いられることは無いよ！つまり本来の目的を全く達成しないばかりか分断をより強くしていくよ！更に二重基準も酷いもので論理なんてものは存在しないよ！これらの言葉を推し進めている人達は自分たちが正義の行いをしていると思い込んでいるので余計にたちが悪いよ！
結局さ、Web3で何ができるのか提唱者も含めて誰も明確に語れていなくてWeb3っていう言葉だけが1人歩きしている状態じゃんね？
ブロックチェーンで既存のWebを置き換える、既存のWebをアップデートするっていうけどさ、既存のWebって大半がランダムアクセスじゃん
ブロックチェーンのランダムアクセス性能が改善されていってるという主張があるのは知ってるが、ブロックチェーンの基礎部分はシーケンシャルアクセスを念頭に置いたもんじゃん
どうやっても既存のリレーショナルデータベースのランダムアクセス性能を追い越すことはなく、ブロックチェーンのランダムアクセス性能が現在のリレーショナルデータベースと同等になった頃にはリレーショナルデータベースは更なるランダムアクセス性能の向上を果たしてると見て良いだろ
ブロックチェーンは永遠にリレーショナルデータベースを超えられないじゃん
NFTだって結局のところブロックチェーンではクソデカバイナリファイルを扱うのは無理があるって言うんでURLみたいな小さなテキストデータで実体を管理しようというGit LFSと似たような運用の仕方なわけだろ？
クソデカバイナリファイルを扱えずにどうやって既存のWebを置き換えたり、既存のWebをアップデートするんだよ
いやそうじゃないんだ、もっと良い方法あるんだと、そんなものがあるなら先にバージョン管理システムがやっとるわと
全くもって理解できないんだよWeb3って一体なんなんだよ
IT技術者の理解を放置して投資投棄やってる連中の中だけで進んでいくIT技術ってそんなもの成立すると思ってるのか？
そして返ってくるのはお決まりの「お前がバカだからWeb3を理解できない」ですよ
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、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構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
https://b.hatena.ne.jp/entry/s/github.blog/jp/2021-01-06-commits-are-snapshots-not-diffs/
複数の差分からスナップショットを取り出すことは必ず成功するが、
複数のスナップショットから差分を取り出すことは失敗する場合がある。
gitでファイル名変更とファイル内容変更を同時に行ったときに、
つまり、コミットをスナップショットとして保存する設計には実害がある。
確かにスナップショット方式であればバグによっって特定のコミット内容が失われた時に、
しかしバージョン管理システムは通常そのようなバグが発生しえないほど安定した状態で使われるため
その上gitでもレポジトリ容量削減のために、記憶媒体上に保存されるデータは差分なので
初期のプロトタイプ版開発のためにはスナップショット方式は有効だったかもしれないが、
リリース版でもその方式を利用し続けたのはgitの設計上の欠陥であり、
どんなに優れたツールや設計思想などがあっても、使う奴がダメだと全く無意味。弊社もWebアプリを作ってて、RESTだのFluxアーキテクチャだのいろいろ導入を試みたが、ほとんど無駄に終わった。
どんなクソ組織でも効果があると確信持って言えるのは上の3つだけ。1つ目は初歩的すぎると思われるかも知れないが、筆者の想定するダメな組織・ダメなプログラマというのは、このレベルの連中を含む。
静的型付け言語（サーバーサイドならJavaやC#、フロントエンドならTypeScript）を使わせれば、少なくともコンパイル時に分かるエラーは修正させられる。
というか、ダメなプログラマに動的型付けの言語は触らせてはいけない。必ずそのプロジェクトは半年後には保守できなくなる。
テストは強制的に書かせるし、テストのないクラスや、通らないテストあったらコミットできないようにする（それは容易にできる）。
もう一つの方法は、そもそも優秀なエンジニアしか参加できないようにすること。たとえば、Scala、Haskell、Erlang、Common Lispなどで書かれていれば必然的にそれが分かるエンジニアしか開発できないし、こういう言語を自主的に学習しているエンジニアは優秀である可能性が高い。
結論を最初に書くと、作家がやりたいのは「小説のバージョン管理」ではなく「出版プロジェクトのタスク管理」と「成果物の品質管理」なのである。
数年前に「家事をRedmineで管理すると捗る」という記事が流行ったように、それと同じことが作家界隈でも散発的に起きていると考えたほうが実情に近い。
「WordやG Suiteの校正機能じゃダメなの？」に対する返答は「WordやG Suiteにはタスク管理ツールが付いてないからダメ」。
本当はGitHubである必要はなく、RedmineやTracとWordを組み合わせてもいいのだが、「ハンマーを持つ人にはすべてが釘に見える」のでGitHubのためにGitを使おうという本末転倒な議論になりがちな印象がある。
逆に「バージョン管理はあるがタスク管理と品質管理がない」環境の例としてはウィキペディア（MediaWiki）がある。
MediaWikiはすべての版をバージョン管理しており、差分も履歴も見られるが校正にはあまり向いていない。ウィキペディアの文章があまり洗練されないのは支援ツールの不在による部分が実は大きい。
の2つで、それを下支えするためにバージョン管理システムは必要だがGitほど多機能である必要はない。むしろRCSくらいシンプルなほうが理解されやすいのではないかと思う。
「業務ではこんなことやるんだな。テストってこういうことか。ここは案外適当なんだな。この製品のプログラムはこんな感じのプログラムになってるんだな」ってことが業務でわかる。だけど言語とかフレームワークとかの仕様は業務では別に身につかない、なぜならそういうのはほぼOJTだから（聞けば答えてくれるシステム）。
最初の研修で言語とフレームワーク一つずつでも覚えさせてもらえばだいぶありがたいと思うけどそういうの無い場合本当にそういうのは独学になる。家に帰って。または先輩にたまに聞くとか（ちょびちょびと…）。そんなんなら知恵袋で聞くのと変わらないし。
業務で学べることはただただ「これは実際こうやって動いてるのか」って中身が見れること以外は少ないと思う。言語やフレームワークやサーバーやバージョン管理システムとかは自分で覚えないといけない。というか覚えられない。時間かかる。働いてる中での独学なんて時間そんな無いし。
食べログやWeb制作企業のアコギな商売のため、それらに不満を抱えているローカル小規模商店が多いとわかった
そこで(抜けはあるかも知れないが)一部の知識を提供しようと思う。
前提として「すべてこの情報でまるっと上手くか？」といえば「そうてないこともある」ことは留意しておいて欲しい。
流石に今どき!DOCTYPEから手打ちしろというのは酷すぎるので「静的サイトジェネレータ」を使う
わかりやすく言えば「ホームページビルダー」で、デザインテーマに合わせたWebページの雛形を生成してくれるもの
現在では静的サイトジェネレータと言うとGUIではなくCUIからWebページを生成してくれるものを指すことが多い
GUIの場合は「Webサイト作成ソフト」「Webオーサリングツール」と呼ばれることが多い
生成されたWebページが含まれたディレクトリをFTPアプリケーションでプロバイダのホームページスペースへアップロードするだけでWebサイトを立ち上げることが可能
早い話こんなのが簡単に作れる上に、最初からたいていはスマホにも対応してる
ttp://www.codeblocq.com/assets/projects/hexo-theme-magnetic/
ttps://sharvaridesai.github.io/hexo-theme-edinburgh-demo
ttps://themes.gohugo.io/theme/yourfolio/
ttps://themes.gohugo.io/theme/alpha-church/
ttps://themes.gohugo.io/theme/hugo-shopping-product-catalogue-simple/products/
ttps://themes.gohugo.io/theme/hugo-creative-portfolio-theme/portfolio/
ttps://event-jekyll-theme.github.io
ttp://jekyllthemes.org/themes/project-gaia/
ttps://portfolio-central.github.io/jekyll-instagram-portfolio-theme/
ttp://mushishi78.github.io/one-page-wonder-jekyll/
ttps://jekyller.github.io/online-cv/
「久々にその固有名詞見たわ」「古いバージョンなら持ってる」と言われそうなド定番
オープンソースなWebオーサリングツール。無料だけどホームページビルダーやDreamweaverに比べると使いにくい
日本語情報も豊富なRuby製静的サイトジェネレータ。他者へ質問しやすいというメリットもある
Node.js製の静的サイトジェネレータ。もう既にNode.js環境があるならアリかな？
Go製静的サイトジェネレータ。シンプルな機能とWebページ生成までの高速性が売り
「どれが良いか？」と問われると「どれが良いってことは無いんだけど、情報の豊富さならJekyll、Webページの生成の速さならHugo」というのが答え
合わないと思ったら別の使えば良いとは思う
プロバイダのホームページスペースにはFTPアプリケーションによるアップロードを行う
定番の「FileZilla」や「FFFTP」あたりを使っていれば間違いない
プロバイダがサーバサイドスクリプトを許可していない限りコメント機能の実装は難しい
しかし、需要があるところには供給もあり「DISQUS」というコメント機能が使えないWebページにコメント機能を実装させるWebサービスがある
Twitter、Facebook、Google+などのSNSアカウントがあれば書き込むことができる
静的サイトジェネレータ名にDISQUSと加えてググればたいてい情報が出てくる
ちなみにWindowsではWSL環境でUbuntu上にHugoなどを構築すると楽
CLIが苦手な人は従来通りホームページビルダーやDreamweaverを使えば良いと思うが、CLIの利点はGitなどバージョン管理システムで管理しやすく、今後レンタルWebサーバへ移行しても、容易にそのままホームページを移行できるというメリットがある
WordPressなどのCMSには良い部分が多くあると思うし、顧客が追加要望ばかりしてアホすぎるという意見もわかるし、メシの種だからあんまり触れてくれるなというのもわかる