【じっくりSw1ftUI】ちょいとブレイク〜動かしもせずに、すぐに正解を決めつけたがる生兵法はケガの素。型破りと形無しは違う。思い込みでしか動かず学ばぬ愚者は、（どの業界でも）大成しない。
さてと、今週も楽しくじっくりSwiftUI〜〜〜で、前々回と前回
で、
クラスの基本と、サブクラスへの継承、プロトコル
なんかをやったから、今回は、
struct(構造体)とenum(列挙型)
に入っていきたかったんだけど、最近、ちょっと普段の業務やネット記事なんかでちょいちょい、
危険な考え方とか作法だなあ🧐
って思うモノをよく目の当たりにしたので、
今回は、ここで一旦、本編はちょいとブレイク
今朝、書き始めるまでNHK日曜討論って番組を見てたんだけど、
この国は、まったり経営学シリーズ
で書いてたとおり、
レジティマシーが強い上に、
社会全体の空気が変わるのにすら５〜10年単位で時間がかかる
誤った個人主義と競争主義に晒されて、
常に新しいことを取り入れてやってるつもりで、
しっかり本質を理解しようともせずに、
タイパ・コスパ（とやらで）
付け焼き刃で良いとこ取りだけして、中途半端に、何十年も、
同じ歴史を繰り返してるだけ〜〜〜
だから、
焦って理解した気になって先に進む
より、特にSwiftの基本文法くらいは、
しっかり・ゆっくり・じっくり
やって理解してから先に進んだ方がいい。たとえそれで、SwiftUIを使いこなせるようになるまでに１年かかったとしても、
それ以上にこの国は、5年後も10年後も殆ど何も進んでないし〜〜〜
👉じっくりやっていて、お釣りがくるよん
実際、オイラが仕事の片手間でSwiftを勉強し始めた８年前に、当時最先端だった
UIKit
を今になってやっと導入しようなんて開発現場が、日本全国に星の数（＝吐いて捨てる）ほどあるみたいだしね👀💦
自分が好きで学び始めた学習で焦る必要なんてない🕺
むしろ、焦って数週間とか数日で
Swiftは簡単だと思い込み、
付け焼き刃でやって理解した気になって
自分たちで炎上させてる現場ばかりです。
個人で世界に発信できる開発環境なのに、それを会社でやってる時点で、如何に論理的思考力がなく、思い込みとレジティマシー（＝それまでの業界で正しいと思われてるやり方）だけに縛られてるかがわかるでしょ👀
Swift自体をちゃんと理解しておけば本来、
炎上なんかするはずのない静的プログラミング言語なのに、、、。
記事にせず、オイラ個人がiOS17を学ぶだけなら、
このくらいの分量の本は、３日〜２週間くらいで学べる
けど、去年も書いたけど記事にした方が、
世界中に発信するから下手なことが書けない分、深い理解に繋がる
これまで開発現場を見てきた経験や考え方を踏まえて、共有できる
👉記事に書かないよりは社会的な裾野が広がる
って思うのでやってるだけ〜〜〜〜
世の中にはいろんな考え方な人や開発現場、組織があるから、
シリーズで紹介した
くらいを読みこなせて、日々の仕事で実践した上で、
自分なりのやり方を見つける
なら、やればいいとは思うけど、
なんかでも書いてるとおり、プログラミングに通底する考え方や作法を習得もせずに、
目先のタイパ、コスパ
とやらで
優秀ぶりたいエンジニア
ほど、すぐに
「独自の〜」
「これはいらない〜」
「時代が違う〜」
「アジャイルだから〜」
で実は不可欠な作業や作法を端折ったり、経験者が意識的にあえてやらない（やっていない）ことを、
「今まで誰もやっていない」ってやろうとするからね〜〜〜🧐
型破りと型無しは違う（故・十八代目中村勘三郎）
ま、10年いろんな現場でエンジニアやった経験から、
100回の理論や推論よりも１回の検証。
100回の検証より１回の実装。
ってことが骨身に染みて分かってるし、コードコンプリートでも
あたりから一貫して書いてる
インスペクションの重要性
を、きちんとデバッグもインスペクションも理解してない状態で、コードだけ理解した駆け出しエンジニアなんかがトリッキーな持論を展開したりするからね。。。
持論なんて殆どが、ただの思い込みに過ぎないのに。。。👀💦
ま、そーゆー自称、（優秀な）エンジニアさんほど、
なんかでも書いてるとおり、オープンレンジとクローズレンジひとつとっても、
頭の中だけでコードを組み立ててからコードを書くこと＝論理的
と勝手に思い込んで、
（打鍵ミスも含めて）書いたコードを直後にちゃんと検証しない
結果、
必ずバグを引き起こす
（例：最後の繰り返し数を含む含まないだけでも、計算結果が大きく異なる）
からね。
さらにそんな人ほど、
より難しいことをやろうとして、
可読性（＝読みやすさ）の低いコードを書きたがる
本来ならば、
・対象のプログラミング言語を本当に理解してるエンジニアは、極力コードを書かなくていいように、使い回せるコードテンプレートを作るなり、パラメータで呼び出すなりする
👉「ハードコーディングほど怖いものはない」
・コードを書くなら書くで、今後の改修を意識して、シンプルで３日後の自分＝誰でも見てわかるコードを書く
👉「３日後のコード（自分）は他人」
で、
必要以上に小難しい書き方とか結合なんてさせない
実際、そもそもSwiftってプログラミング言語自体が、
これまでの他のプログラミング言語での課題を研究して、
シンプルでモダンで分かりやすい
ようにしてるのに、自分たちで下手なべき論とか持論を寄せ集めて、
（前回と前々回でやった）クラスの継承が出来たらすごいとか偉いとか勘違いして、（改修コストや可読性を意識せず）結合を強くしまくる
コードも変数や定数にname1,age1みたいなことを100も200も作って誰の何の年齢なのかもわからない引数名を付けたがる
コーディング作法に則らず、キャメルケースも意識しないから、Name1,Age100,name2,age583,,,みたいな同じ役割の変数や定数に、適当にぐちゃぐちゃにしてるにも関わらず、「それを読み解いて論理的にやるのがエンジニア」、「エンジニアなら読み解けるべき」みたいな持論を押し付ける
なんてやって、結果、現場を炎上させるとかやらかしてるからね。まさに、
愚の骨頂
だし、自分たちで解決出来なくなって、最終的にオイラみたいなラスト・エンジニアに困って相談して解決してもらってるだけでは、
改善しないし、
自分たちのバカさ加減を露呈させてるだけ👀💦
で書いたとおり。
ここまで読んだだけでも、持論を展開して、小難しいことをやろうとするエンジニアがいかに、
目先の屁理屈を理論と勝手に思い込んで、
自分は論理的なことをやってると誤解し、
自分の書いたコードが正常に想定通りに動くかってことを書いた直後に検証しないなんて、
はたから見てるといかに非論理的なことをしてるか
👉てか、もはや論理じゃない
てことがわかるでしょ👀💦べき論とか理論とは何かすら分かっていないレガシーエンジニアが集まる現場なんかではそれが横行してんだけどね💦
指導のつもりで論理的だと多用する人ほど、
＜そもそも論理的とは何か＞
が分かっていないってのはどこの業界でもどこの職場でもザラにある話
👉「人は自分ができていないことほど口にする」
なので、これまでのオイラの記事では、
同じコードを極力書かなくていいように、このマガジン全体で使い回すコードテンプレートを導入編で紹介し、
コードを書いたら、ちゃんとすぐに実行した結果をスクリーンショットで示す
ようにしてる。
なぜなら、この記事を読みながら学ぼうとしてる人に、
変な持論とか哲学、作法なんかを身につけてほしくない
からね💦変な考え方とか癖なんかが身につくのは一瞬なんだけど、一回身についた癖や考え方を直そうとするのは、一生分の時間をかけても直らない人は直らない。
自分の目先の経験からだけで安直に短絡的に、せっかちにすぐに持論を生み出そうとするような思い込みが強い人ほど特に。。。
Appleやオラクルといったプラットフォーマーが作ったたかが開発環境にそもそも、持論なんか必要なわけないだろ笑🤣
誰もがより簡単により使いやすく、アプリやシステムなんかを作りやすくしてるだけの開発環境を、魂とか情熱とか職人とか、持論ゆーてる時点で、
その開発環境のやり方とか考え方を理解してないってことを露呈させてる
だけだからね。記事を読んだ結果でそーならなくていいように、考え方を示すときには、極力、参考にした文献とか世界的な名著なんかも引き合いに出して説明してるつもり。
でも書いてるとおり、
自分のコードを書いた経験知だけを元に理論を組み立てる＝帰納的
👉ただの独りよがり。何か違う経験やアクシデントがあるとすぐに崩れる
＝他の事象に通用しない以上は、理論とは言わない。その人個人のただの経験に基づく持論。
世界的な経験者の経験を集めて、研究・分析した成果
👉どこの開発現場でも起こりうる事象を踏まえている共通の理論なので、色褪せないし、知って理解しておけば、対処が簡単にできるし、そもそもアクシデントが起こらない＝演繹的
それこそが、理論
だからね。
で今でも色褪せない、親しみやすい世界的な名著を感想文って体裁で紹介し、
実際それを読まずに、自分の経験だけを頼りに持論を展開して、開発現場でトラブルの主原因になってるような、どの開発現場にも必ずひとりはいそうな魑魅魍魎をこれまでの経験も共有（こんな人が開発現場にはよくいるから気をつけてね！）できるように、
も２年くらい前から書いてる。
自分の経験からだけでせっかちに持論（＝正解を決めつけてるだけ）を展開したがる、自己アピールが大好きなエンジニアさんほど、
「経験が大事だ」
「マニュアル人間になるな」
「原理原則なんかに従ってたら仕事なんかできない」
みたいなことをよく口にするんだが、そんな人は、
自分の解釈と思い込みでしか生きていない
し、他の記事でよく書いてる話だけど、
「経験が大事だ」の割に、自分の経験からすら学べず、同じ失敗を繰り返す
「マニュアル人間になるな」てゆーマニュアルに従ってるだけの行動を取る
「原理原則なんかに従ってたら仕事なんかできない」と言って、原理原則に従っていれば、本来は起きないトラブルを増やして、余計な仕事を自分で増やす
まとめ
今やってる本がすでに11章まで終わっていて、
12章：構造体と列挙型
13章：プロパティラッパー
14章：配列と辞書型
15章：エラーハンドリング
と残り４章で
基本文法＝Syntax
も終わりが見えていて、いよいよ
SwiftUIフレームワークを使った開発方法の実践
にそろそろ入っていけそうだから、Swiftの基本文法を知る、触れる、習得する自体はもちろんすごく大事なんだけど、それ以上に、
裏を返せば、たかだか、
実践編に必要な最低限のSwiftの文法の知識
をまとめてる程度の内容に、
変な持論、自分なりの独自のやり方、
サンプルコードは見ずに書けて当たり前など
思うだけで烏滸がましいし、いずれ大きな恥をかくだけだし、
そんな人がいたら、すでに変な考え方や癖がつき始めてて危険だから
今すぐやめときなされ
いくら頭の中で、階層の深いループやクラスを繋いで、
「こうなるはずだ！」
なんて推論を繰り返したところで、いざやってみたら、実際にはうまくいかないってことは山ほどあるし、その失敗と改修を繰り返して、次回からやらないようにしようって少しずつ経験値を積み上げて、
いずれ自分なりのアプリを作れるようになれば十分なんだから。
オイラがこれまでに作ってるコードテンプレートも
別にクラスでやろうが、（次にやる）構造体でやろうが、
自分のやりたいことや顧客の要求が実現できればそれでいい
んだし。
プログラミングに最適解
はあっても、
答え＝正解なんてない
からね。それよりは、
自分の書いたコードを書く
そのコードをなるべく早く自分で実行する
期待どおりの動きになっているかを検証する
が一番大事。
正道に優る王道なし。
急がば回れ。
急いては事を仕損じる
オイラが今までに出会った数少ない本当の職人さんたちも、職人であればあるほど、
何十年経ってても、とにかく基本に忠実で丁寧
当たり前のことを当たり前にしかやらないし、
変な持論とかべき論みたいな無駄なことは一切やらない。
ま、学び始めてすぐとか数ヶ月くらいしか業務経験もないくらいな時期に変な持論とか自分のやり方とかをゆーてる人や組織ほど、数年もしたら、
人であれば、業界自体から自ら去って行く
組織であれば、市場から淘汰されて倒産してる
からね。
そんな雑音は気にしなくていい。
自分が興味があって、好きで学び始めてるだけなんだから、
ゆっくり・じっくり・楽しく学び続けるだけでいい
てか誰かを意識して競争してる時点でそれは、
勉強であって、学びではない。
熱中も夢中にもなれてないからね。
焦って先に進もうとする暇があったら、
楽しくいつまでも学び続けられるように、
マンネリ化しないように神経を使うだけでいい。
人間はどうしても
飽きるし、忘れる生き物だからね👀
ま、それが人間の他の生物とは違う最大の強みでもあるしね〜〜〜
そんな炎上してる企業を避けて、就職したいとかでこのマガジンを読んでる人がいたら、
に嗅ぎ分け方は書いてるつもりだから、参考にしてみてね〜〜〜
最後に繰り返しとくけど、プログラミング言語とかアプリ開発くらいで
べき論とか持論をゆーてる人がいたら、
遅かれ早かれいずれ淘汰される人
だし、じっくり学んできちんと理解しておけば簡単にできることすら、
小難しくしか出来ない人＝どうせ職人ではない
から、
本当に気にしなくていいし、相手にしなくていい。
👉少し学べば誰でも簡単に開発できることを
わざわざ小難しくしてる時点でただの愚か者でしょ笑🤣
とまあ、ここまでつらつらと書いてきて、それを読んだ感想が
所詮、オイラの持論ですよね〜〜
で片付けるならそれはそれで全然OK！
繰り返し書いたところで、何者からも学ぼうとしない人はここで書いてる通りの失敗を自分で経験してからすら学ばないし、学ぶ人はこんなこと言われなくてもすでに自分で学んでるだろうしね〜〜〜〜🕺
それが、オイラのこれまでの人生で経験した現場や去年までFacebookやnoteなんかで合計2000記事くらい書いてきた
オイラなりの結論
経験が大事って人ほど、他人の経験＝書物や理論を素直に聞こうとしないし、そんな人は、他の人や過去の自分がすでにやってる失敗を今日もどこかで繰り返す
👉同じ歴史を繰り返してるだけ〜〜〜
（最初の方に書いてるとおりで国も人も一緒〜〜）
だからね
さてと、今朝の新聞をまだ読んでないし、
遅くとも３月中には、SwiftUIフレームワークに入れそうなので、
💃本編の続きはまた来週🕺
時間が余ったら、今日書くかもしれないけどね。
自分が好きで学び直しや暇つぶしがてら公開してるだけの記事に、
他にやりたいことを後回しにしたり
疲れを残してまで
休日にやらないといけない程の価値はないので〜〜〜〜
このマガジンで、
これまでの記事で公開してるサンプルコードだけ見て、動かしもせずに
「完璧に理解した」
「検証なんか必要ない」
なんて思ってる人がいたら、今週は一度、ここで記事を止めるから、色々振り返ってみてね。変な癖とか自分なりのやり方なんかを今の段階で思い描いてた人もいそうだったから、
💃今週は一旦ここでブレイク＝立ち止まって振り返った方がいい🕺
と思ったので、記事を一旦止める〜〜〜〜！てか、
でも書いてるとおり、どのマガジンでもそうなんだけど、別に、
あなた個人に向けて書いてるわけではなく、
Swiftどころかオブジェクト指向言語、ひいてはプログラミングに触れたことがない人でも
最初から最後まで読んでもらえればわかるくらいの難易度で、
本の流れにだけ沿って、オイラなりのサンプルコードを展開してるだけ
なんだから
読んで「分かった気になる」、「完璧に理解できた気になる」ってのは、
当たり前の話だからね。
だって、そうなるように書いてるんだから。
ただし、それであなたが実践で、エンジニアの基本的な作法まで含めて、
すぐに使えるかどうかは全然別の話。。。
ま、そんなこと言われなくても、わかっているとは思うけど〜〜〜〜
じゃ、また次回〜〜次こそ本編！
＊タイパ、コスパで〜〜〜〜先に進んで予習したいって人で、
「本の内容だけを知れれば充分。」
「お前の学びの記録なんかはどうでもいい。」
「この記事の内容なんか見なくても、本だけ見れば理解できる。」
って人は、公式なサイトかどうか知らないけど、
に内容はそのまんま載ってるみたいだからそちらを参考にしてね〜〜〜。
＊ま、オイラは英語の学び直しにならないから、引用する時以外読まないけどね。
この記事が気に入ったらサポートをしてみませんか？