アプリのドキュメントはともかく、OSのAPIやライブラリの関数や、
classなどのドキュメントはとても重要で、ソースがドキュメントと
いう考え方は絶対駄目。
それをやるから互換性の問題で悩まされ、そのOSやライブラリを使った
アプリが不安定化する。
ソースは一時的なものであって、たまたまそのバージョンのOSや
ライブラリでのみ通用する事情であることが多いから。
もし、安定したOSを目指すなら、むしろソースは非公開にして、ドキュメントで
公開されている仕様のみでアプリを作った方が安定することもある位。
たとえば、fopenやprintf、argv[]やatoi、strtodなどの互換性は、
ソースを見なくてもあらゆるプラットフォームで割と高い。
逆にLinuxのGRUB(ディスクのマルチブートツール)などはLinuxのソースに
基づいてプログラミングされているようで、OSのバージョン間の互換性が低く、
非常に不安定。
しかも、マルチブートしたいだけなのに自分でスクリプト言語を書かなくては
いけない事が多く、僅かでも間違うとディスクの破損事故につながったり、
OSが起動しなくなって簡単には復旧できなくなる可能性がある。
これは、正式なドキュメントによらずにソースの解析に基づいてプログラミング
してしまっていることが要因だと考えられる。
>>5 残念ながらLinuxはUNIXの仕様が正確にわからなくて、細かいところはかなり異なるものになった。
C言語もUNIX用に作ったので、仕様が明示されておらず、同じコードでもバラバラで、完全な環境依存になっている。
ドザExcelerの弊害、仕事終わったつもりでいる
コードと一緒で意味あるドキュメントもあるしクソなドキュメントもあるってだけ。
コードと一緒で長くても短くても品質とは関係ない。
成果物はドキュメントではなく動作するコードです。
コード知らない人の設計書は穴だらけ。
まともなドキュメント書けないSIerみたいなやつはコードもクソだよ。
ドキュメンテーションが苦手で、コーティングが得意なんていうのは、仕事ではありえないんだよな。
得意苦手というよりは、特定のドキュメントが存在することで誰が得するの？って話では？
特定のドキュメントって具体的に何なのかは知らないけど
NECとかに要求される大量のExcelファイルは本当に無駄だと思う
極端に一時的な資料になっているドキュメントも困る。
コードが完成してから書くドキュメントには価値がある
>>16 誤解のない意思疎通のために必要なら
一時的なものでもドキュメント書いた方が結果的に安上がり
ルールとか規約のためだけに書いてるものはだいたい無駄
>>17 各ファイルのステップ数とか書き込むExcelとかに？
>>19 そういうのは自動生成すればいいだけだからどうでもいい
枯れてるJavaとかならなぁ、flutterとかだと新しいプラグインで「あーこんなやり方あるの？/できないの？」みたいな事も多いからなぁ
ListView.builderの中のListView.builderとか一工夫必要だしなぁ
API mockでプロトタイプアプリ作ってエンドと合意してから要件他まとめる感じ
linux kernel読むのにソースだけ読み始めても無理があるだろ。
明らかにドキュメントが必要だし、実際役に立ってる。
Ruby では、ソースコードのクラス定義やメソッド定義箇所に、
YARD の記法に従いコメントをつけることで、自動的に文書が作られる
>>28 書かせるのが仕事なんだから
コード以外にもたくさん書かせたほうが仕事ができる男なんだよ
役に立つドキュメントを書ける人とそうでない人がいる
>>30 これはそうだな
本当に役立つドキュメントを書ける人は20人に1人もいない
まあそれはコードでも同じなんだが、コードの場合糞でも動くってところが厄介。
ドキュメントはクソでも動かさないから修正されない
ドキュメントこそクソができないようにレビューしなければいけないのだが
クソでも動かさないから間違っていても客から文句は言われないのでレビューもしない
ドキュメントがクソだとコードはクソにしからない、これはドキュメントのせい
ドキュメントがクソ方がもっと厄介
そだよ
上流ドキュメントの質が一番重要だから君たちより高い金もらって
ドキュメントだけ書いてあとは君たち下請けに投げてるんじゃないか
クソの下請けがクソにしかならないのは当たり前
>>34 だからドキュメントのレビューさせろって言ってるんだが？
>>34 糞しかできないんじゃその高級なドキュメントとやらに価値はないがな。
>>36 そだよ
客は本当の価値なんて分からないから下請けがクソでしたってことにして清算するだけ
本当の価値に対して金が動くわけじゃないから
>>35 すればいいじゃんw
レビューすらさせて貰えないのは君の会社の管理体制の問題だろ
その程度の交渉力すらないならドキュメントの質に関係なくクソ確定だよ
ドキュメントの内容が正しいか
ちゃんとテストしましたか？
テストは重要ですよ
>>33 これは本当にそう思う
・ドキュメントはテストできない
・ドキュメントは静的解析できない
これがドキュメントの抱える最大の問題
まあ静的解析はできなくもないが
標準的なエコシステムが無いのでコストが高すぎる
独自のエクセル設計書解析システムを持ってる現場で働いたことがあるけど
解析が重すぎ&成果しょぼすぎて全く役に立ってなかった
ドキュメントもテストできるよ
自動化はまだ難しいだろうけど
そもそもテストが必要になる時点でクソドキュメントだけどな。
だから全てのドキュメントは、クソドキュメントだからテストするんだよ
ドキュメントをレビューする時に何をレビューしてんの君たちww
ドキュメント作ってるやつがレビューをさせないんだよ
バグありのまま出来ましたって出してくる
大量に持ってくるからその場でレビューできる量じゃない
そして実際に作ってる段階で漏れや矛盾が見つかる
納品するやつが受け入れテストさせねーんだよ
バグありのまま出来ましたって納品してくる
そして実際に運用してる段階で不具合が見つかる
検収とか受け入れテストとかすれば良くない？
そもそも下流でレビューするという工程が含まれてない
上流に戻すという工程が含まれてない
>>50 工程管理に不具合があるなら修正すればいいだけじゃん
修正できないのは君の能力不足が原因
自分の能力不足を他人のせいにしてるうちは成長しない
>>51 それを修正するには、上流は偉くない、
難しいことをしてるわけじゃない、給料を減らすべきだ
という流れにつながるから上流は拒否するんだよ
>>52 それが解決策だと思うならそうすればいいじゃない
拒否されてハイそうですかって引き下がるしかできないならそれは君の能力不足
最も実際には何も行動してなくて自分の能力不足の言い訳をグチグチと垂れ流してるだけだろうけど
そういう契約しかできないというのも能力の問題
そういう契約しかできないような会社で働く選択肢しかないというのも本人の能力の問題
問題だらけのドキュメントを提出してくるやつは
技術的能力は低くてもそれ以外の能力が及ぼす影響についていくらか理解してる分だけ
レビューさせないと愚痴るだけのやつに比べれば100倍マシ
もしかして一人で働いてるんか？
契約を開発が担当するわけないだろ
発注側が飴対応で舐められてるのか受注側が確信犯でヤバいのかその両方なのか
>>56 理解できないんだね
君みたいな考え方しかできない開発者は例外なく使えない
例外なく、ね
>>58 使える開発者が存在するなら、俺以外がすでにやってる
そりゃそんな契約しかできない会社だもん、使えるやつがいるなんて誰も思わないよww
とことん頭悪いね
問題がある現状を変えるために君は何をしたの？
愚痴ってるだけ？
> 君は何をしたの？
転職
周りの人間を育てるよりも
すでに育っている人に変えるほうが
自分の時間を使わなくてすむ
時間は有限
>>61 まともな会社に転職してたら
「ドキュメント作ってるやつがレビューをさせないんだよ」なんて言わないわなw
ブックマークへ