The Frameworks Dilemma

ໃນຖານະເປັນຜູ້ພັດທະນາ, ກອບແມ່ນປົກກະຕິແລ້ວເປັນສິ່ງທໍາອິດທີ່ເຈົ້າຈັບໄດ້ໃນເວລາທີ່ທ່ານຕ້ອງການເລັ່ງສິ່ງຕ່າງໆແລະຮັກສາສິ່ງທີ່ຫນ້າເຊື່ອຖື. ຄົນເຮົາມັກຈະເວົ້າເຖິງກອບວຽກຄືກັບວ່າມັນເປັນທາງອອກທີ່ສົມບູນແບບທີ່ສາມາດແກ້ໄຂບັນຫາທັງໝົດຂອງເຈົ້າໄດ້, ເຮັດໃຫ້ການພັດທະນາໄວຂຶ້ນ, ງ່າຍຂຶ້ນ ແລະມີປະສິດທິພາບຫຼາຍຂຶ້ນ. ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານມີປະສົບການບາງຢ່າງພາຍໃຕ້ສາຍແອວຂອງທ່ານ, ທ່ານຮູ້ວ່າກອບບໍ່ແມ່ນການແກ້ໄຂຂະຫນາດດຽວ. ການເລືອກອັນທີ່ຖືກຕ້ອງສາມາດປັບປຸງການເຮັດວຽກຂອງເຈົ້າໄດ້, ແຕ່ການເລືອກທີ່ຜິດອາດເຮັດໃຫ້ເຈົ້າເຈັບຫົວໄປຕາມເສັ້ນທາງ, ເຮັດໃຫ້ເຈົ້າຊ້າລົງເມື່ອເຈົ້າຕ້ອງຍ້າຍອອກໄປຢ່າງໄວວາ.

ໃນການຕອບ blog ນີ້, ພວກເຮົາກໍາລັງຈະເຂົ້າໄປໃນສິ່ງທ້າທາຍທີ່ແທ້ຈິງແລະຍຸດທະສາດທີ່ມາພ້ອມກັບການເລືອກແລະການນໍາໃຊ້ກອບ. ພວກເຮົາຈະເບິ່ງບັນຫາທີ່ອາດຈະເກີດຂຶ້ນ, ວິທີການຫຼີກລ້ຽງພວກມັນ, ແລະວິທີການຮັກສາ codebase ຂອງທ່ານມີຄວາມຍືດຫຍຸ່ນ - ເຖິງແມ່ນວ່າໃນເວລາທີ່ກອບຢູ່ໃນການຫຼິ້ນ.

ຄວາມສໍາພັນທີ່ທ່ານບໍ່ຮູ້ຈັກເຈົ້າກໍາລັງເຂົ້າໄປໃນ

ການຍຶດຫມັ້ນໃນກອບແມ່ນຄ້າຍຄືການເຂົ້າໄປໃນຄວາມສໍາພັນໃນໄລຍະຍາວ. ແລະມັນບໍ່ແມ່ນສິ່ງທີ່ຈະເບົາບາງ. ບໍ່ເຫມືອນກັບຫ້ອງສະຫມຸດທີ່ງ່າຍດາຍຫຼືສິ່ງອໍານວຍຄວາມສະດວກຂະຫນາດນ້ອຍ, ໂຄງຮ່າງການມາພ້ອມກັບຄວາມຄິດເຫັນ - ຈໍານວນຫຼາຍຂອງພວກເຂົາ. ພວກເຂົາເຈົ້າບັງຄັບໃຊ້ໂຄງສ້າງແລະວິທີການໃນຄໍາຮ້ອງສະຫມັກຂອງທ່ານ, ບໍ່ວ່າທ່ານຈະມັກມັນຫຼືບໍ່.

ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ຈະຕ້ອງຈື່ໄວ້ວ່າຜູ້ສ້າງກອບມີບູລິມະສິດຂອງຕົນເອງ. ພວກເຂົາກໍາລັງແກ້ໄຂບັນຫາຂອງເຂົາເຈົ້າ, ບໍ່ແມ່ນຂອງເຈົ້າ. ພວກເຂົາບໍ່ໄດ້ເປັນຫນີ້ເຈົ້າຫຍັງ (ເວັ້ນເສຍແຕ່, ແນ່ນອນ, ທ່ານມີ buddy ໃນທີມງານກອບພາຍໃນ, ໃນກໍລະນີນີ້, ໂຊກດີທ່ານ). ຖ້າສິ່ງທີ່ໄປທາງໃຕ້, ໂດຍສະເພາະເຂົ້າໄປໃນໂຄງການຂອງເຈົ້າ, ເຈົ້າອາດຈະຢູ່ໃນໂລກທີ່ເຈັບປວດ. ໃນປັດຈຸບັນທ່ານກໍາລັງຕິດຂັດມັນ, ຫຼືຮ້າຍແຮງກວ່າເກົ່າ, ripping ມັນອອກທັງຫມົດ.

ບໍ່ມ່ວນ, ບໍ່ແມ່ນບໍ?

ສະນັ້ນກ່ອນທີ່ທ່ານຈະຜູກມັດຕົວເອງກັບກອບ, ໃຫ້ແນ່ໃຈວ່າມັນເຫມາະສົມກັບສິ່ງທີ່ທ່ານຕ້ອງການ. ຖ້າບໍ່ດັ່ງນັ້ນ, ທ່ານກໍາລັງ rolling dice ໄດ້.

ບັນຫາ FAANG

ຜູ້ຂຽນບໍ່ຮູ້ວ່າ FAANG ກາຍເປັນ MAANG, MANGA, ຫຼືວ່າພວກເຮົາທັງຫມົດພຽງແຕ່ຢູ່ໃນອານິເມ່ໃນປັດຈຸບັນ.

ນີ້ແມ່ນບ່ອນທີ່ປະສົບການນັບມື້ນັບຫຼາຍ. ເມື່ອບໍລິສັດເຕີບໂຕຢ່າງໄວວາ, ພວກເຂົາມັກຈະປະເຊີນກັບສິ່ງທ້າທາຍທີ່ບໍ່ມີການແກ້ໄຂນອກຊັ້ນວາງສາມາດຈັດການໄດ້. ຂະຫນາດຂອງບັນຫາເຫຼົ່ານີ້ບັງຄັບໃຫ້ພວກເຂົາສ້າງເຄື່ອງມືຂອງຕົນເອງ - ຖານຂໍ້ມູນທີ່ກໍາຫນົດເອງ, ເຄື່ອງຈັກ ETL, ເຄື່ອງມື BI - ທ່ານຕັ້ງຊື່ມັນ. ຍັກໃຫຍ່ເຕັກໂນໂລຢີເຊັ່ນ Google, LinkedIn, Spotify, ແລະ Netflix ໄດ້ນໍາພາທາງ, ການກໍ່ສ້າງແລະເຄື່ອງມືເປີດແຫຼ່ງທີ່ສ່ວນທີ່ເຫຼືອຂອງພວກເຮົາໃນປັດຈຸບັນໄດ້ຮັບການຫລິ້ນກັບ.

ແຕ່ນີ້ແມ່ນສິ່ງທີ່: ເຄື່ອງມືເຫຼົ່ານີ້ບໍ່ໄດ້ຖືກສ້າງຂຶ້ນເພື່ອໃຫ້ສາມາດນໍາໃຊ້ໄດ້ທົ່ວໂລກ. ພວກມັນຖືກສ້າງຂື້ນເພື່ອແກ້ໄຂບັນຫາສະເພາະທີ່ບໍລິສັດສ່ວນໃຫຍ່ຈະບໍ່ພົບ. ວິສະວະກອນທີ່ເຮັດວຽກຢູ່ໃນບໍລິສັດໃຫຍ່ເຫຼົ່ານີ້ໄດ້ຖືກນໍາໃຊ້ເພື່ອຮັບມືກັບສິ່ງທ້າທາຍເຫຼົ່ານີ້ - ພວກເຂົາເຈົ້າໄດ້ສ້າງວິທີແກ້ໄຂທີ່ດໍາເນີນການໃນລະດັບທີ່ສ່ວນໃຫຍ່ຂອງພວກເຮົາພຽງແຕ່ສາມາດຈິນຕະນາການ. ດັ່ງນັ້ນ, ເມື່ອພວກເຂົາຍ້າຍໄປຢູ່ໃນບໍລິສັດຂະຫນາດນ້ອຍ, ການຕັດສິນໃຈຂອງກອບແລະເຄື່ອງມືທີ່ເຂົາເຈົ້າເຮັດແມ່ນອີງໃສ່ຄວາມເຂົ້າໃຈຢ່າງເລິກເຊິ່ງຂອງທັງອໍານາດແລະຄວາມຜິດພາດຂອງເຕັກໂນໂລຢີເຫຼົ່ານີ້.

Pushback ຕ້ານ Frameworks

ຫວ່າງມໍ່ໆມານີ້, ມີການກະບົດເລັກນ້ອຍ - ຄົນເຮົາເມື່ອຍກັບກອບວຽກ. ໂດຍສະເພາະໃນໂລກ JavaScript, ນັກພັດທະນາມີຄວາມເບື່ອຫນ່າຍກັບການປັ່ນປ່ວນຢ່າງຕໍ່ເນື່ອງ. ເຈົ້າອາດຈະເຫັນມັນ: ທຸກໆຄັ້ງທີ່ການປັບປຸງທີ່ສໍາຄັນຫຼຸດລົງ, ທ່ານຕ້ອງຂຽນບົດທີ່ສໍາຄັນຂອງ codebase ຂອງເຈົ້າຄືນໃຫມ່ເພື່ອໃຫ້ມີຄວາມກ່ຽວຂ້ອງກັນ. ແລະຢ່າເຮັດໃຫ້ຂ້ອຍເລີ່ມຕົ້ນໃນວົງຈອນທີ່ບໍ່ສິ້ນສຸດຂອງການປ່ຽນແປງທີ່ແຕກຫັກ.

ຄວາມອຸກອັ່ງນີ້ໄດ້ເຮັດໃຫ້ເກີດການຟື້ນຟູຂອງ stacks ງ່າຍດາຍແລະຫມັ້ນຄົງຫຼາຍ. ສິ່ງຕ່າງໆເຊັ່ນ vanilla HTML, CSS, jQuery, PHP, ແລະ SQLite ກໍາລັງກັບຄືນມາໃນບັນດາຜູ້ພັດທະນາທີ່ຈັດລໍາດັບຄວາມສໍາຄັນຂອງສິ່ງທີ່ເຮັດໄດ້ຫຼາຍກວ່າການຢູ່ໃນຂອບເຂດຂອງເຕັກໂນໂລຢີ. ແມ່ນແລ້ວ, ມັນອາດຈະຮູ້ສຶກວ່າ "ໂຮງຮຽນເກົ່າ", ແຕ່ມັນໄກຈາກສິ່ງທີ່ລ້າສະໄຫມ. ດ້ວຍ stack ທີ່ງ່າຍກວ່າ, ທ່ານສາມາດ iterate ໄດ້ໄວ ແລະສົ່ງໄດ້ໄວຂຶ້ນ. ແນ່ນອນ, ໂຄງຮ່າງການໃໝ່ກວ່າເຊັ່ນ React, Node.js, ແລະ Flask ມີບ່ອນຢູ່, ແຕ່ບາງເທື່ອເຈົ້າບໍ່ຕ້ອງການສິ່ງດີໆທັງໝົດ. ບາງຄັ້ງ, ການຍຶດຫມັ້ນກັບສິ່ງທີ່ເຮັດວຽກສາມາດຊ່ວຍປະຢັດທ່ານເຈັບຫົວທັງຫມົດ.

ໂຄງສ້າງອຸດສາຫະກໍາ Complex?

ກອບເປັນ... overhyped? ມັນເປັນການຍາກທີ່ຈະບໍ່ສັງເກດເຫັນວ່າບາງກອບມີຄວາມຮູ້ສຶກຄືກັບເຄື່ອງມືທີ່ອອກແບບມາເພື່ອດຶງດູດການສະຫນອງທຶນຂອງ VC ຫຼາຍກວ່າການແກ້ໄຂບັນຫາທີ່ແທ້ຈິງຂອງນັກພັດທະນາ. ມັນຄ້າຍຄືວ່າມີລະບົບນິເວດທັງຫມົດຊຸກຍູ້ນັກພັດທະນາເຂົ້າໄປໃນກອບເຫຼົ່ານີ້, ພຽງແຕ່ໃຫ້ພວກເຂົາຮັບຮູ້ໃນພາຍຫລັງວ່າ, ເມື່ອພວກເຂົາຂະຫຍາຍ, ພວກເຂົາຖືກລັອກເຂົ້າໄປໃນເວທີທີ່ມີລາຄາແພງ. ແນ່ນອນ, ກອບເຊັ່ນ Databricks ແມ່ນແຫຼ່ງເປີດແລະບໍ່ເສຍຄ່າເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ແຕ່ເມື່ອທ່ານເຕີບໂຕ, ທ່ານກໍາລັງກ້າວໄປສູ່ການແກ້ໄຂວິສາຫະກິດຂອງພວກເຂົາ. ແລະທັນທີທັນໃດ, ຄ່າໃຊ້ຈ່າຍໃນ hosting ແລະການດໍາເນີນງານຂອງທ່ານແມ່ນຜ່ານຫລັງຄາ, ໃນຂະນະທີ່ VPS ງ່າຍໆອາດຈະພຽງພໍ.

ມັນຮູ້ສຶກຄືກັບດັກ, ບໍ່ແມ່ນບໍ?

ການຊັກຊ້າການຕັດສິນໃຈຂອງກອບ

ນີ້ແມ່ນຄໍາແນະນໍາທີ່ຂ້າພະເຈົ້າສາບານໂດຍ: ຢ່າຟ້າວເຂົ້າໄປໃນການເລືອກກອບ . ຢ່າຕັ້ງໃຈຈົນກວ່າສະຖາປັດຕະຍະກໍາຂອງເຈົ້າຈະສົມບູນ.

ກອບຄວນຈະເປັນສິ່ງສຸດທ້າຍທີ່ທ່ານກັງວົນ, ບໍ່ແມ່ນທໍາອິດ.

ກ່ອນອື່ນ ໝົດ, ໃຫ້ແນ່ໃຈວ່າສະຖາປັດຕະຍະ ກຳ ຂອງທ່ານແຂງ. ຮູ້ຈັກອົງປະກອບຫຼັກຂອງເຈົ້າ ແລະເຂົາເຈົ້າຈະໂຕ້ຕອບແນວໃດ. ເມື່ອທ່ານໄດ້ຮັບສິ່ງນັ້ນແລ້ວ, ທ່ານສາມາດປະເມີນກອບດ້ວຍຄວາມເຂົ້າໃຈຢ່າງຈະແຈ້ງກ່ຽວກັບບ່ອນທີ່ພວກເຂົາອາດຈະເຫມາະ - ຫຼືວ່າພວກມັນເຫມາະທັງຫມົດ.

ວິທີການນີ້ຮັບປະກັນວ່າການອອກແບບຂອງທ່ານແມ່ນແຂງແລະເຫມາະສົມກັບຄວາມຕ້ອງການສະເພາະຂອງທ່ານ. ໃນເວລາທີ່ມັນມາເຖິງເວລາທີ່ຈະພິຈາລະນາກອບ, ທ່ານຈະສາມາດເຫັນໄດ້ຊັດເຈນບ່ອນທີ່ມັນສາມາດເສີມຂະຫຍາຍສະຖາປັດຕະຍະກໍາຂອງເຈົ້າໂດຍບໍ່ຈໍາກັດມັນ.

ກ່ອນ​ທີ່​ທ່ານ​ຈະ​ກ້າວ​ເຂົ້າ​ໄປ​ໃນ​ການ​ນໍາ​ໃຊ້​ໂຄງ​ຮ່າງ​ການ​ໃດ​ຫນຶ່ງ, ຖາມ​ຕົວ​ທ່ານ​ເອງ: ເຈົ້າ​ຕ້ອງ​ການ​ມັນ​ແທ້ໆບໍ? ແນ່ນອນ, ກອບສາມາດເພີ່ມຊັ້ນຂອງອັດຕະໂນມັດແລະຄວາມສະດວກສະບາຍ, ແຕ່ພວກມັນຍັງມາພ້ອມກັບຂໍ້ຈໍາກັດຂອງຕົນເອງ. ຖ້າຄໍາຮ້ອງສະຫມັກຂອງທ່ານມີຄວາມຕ້ອງການທີ່ເປັນເອກະລັກ, ກອບອາດຈະບໍ່ດີກັບພວກມັນ.

ຄິດຍາວແລະຍາກກ່ຽວກັບຜົນປະໂຫຍດໄລຍະຍາວຕໍ່ກັບຂໍ້ຈໍາກັດ.

ການສ້າງໂຄງຮ່າງການໃຊ້ຈ່າຍໄດ້

ຖ້າທ່ານຕັດສິນໃຈວ່າກອບເປັນມູນຄ່າຄວາມສ່ຽງ, ໃຫ້ແນ່ໃຈວ່າມັນງ່າຍທີ່ຈະທົດແທນ. ແມ່ນແລ້ວ, ເຈົ້າໄດ້ຍິນສິດນັ້ນ. ສ້າງຄວາມຍືດຫຍຸ່ນບາງຢ່າງເພື່ອວ່າຖ້າທ່ານຕ້ອງການຍົກເລີກມັນໃນພາຍຫລັງ, ມັນບໍ່ແມ່ນວຽກງານທີ່ໃຫຍ່ຫຼວງ. ນີ້ແມ່ນວິທີ:

ຫຍໍ້ຄວາມເພິ່ງພາອາໄສຂອງເຈົ້າ

ຮັກສາມືນ້ອຍໆຂອງກອບວຽກອອກຈາກລະຫັດຫຼັກຂອງເຈົ້າ. ໃຊ້ການໂຕ້ຕອບເພື່ອ abstract ຫນ້າທີ່ຂອງກອບເພື່ອວ່າເຫດຜົນທຸລະກິດຂອງທ່ານບໍ່ຂຶ້ນກັບກອບໂດຍກົງ.

ໃຫ້ເວົ້າວ່າທ່ານກໍາລັງໃຊ້ TensorFlow ສໍາລັບການຮຽນຮູ້ເຄື່ອງຈັກ. ແທນທີ່ຈະຝັງລະຫັດ TensorFlow ຕະຫຼອດຄໍາຮ້ອງສະຫມັກທັງຫມົດຂອງທ່ານ, ກໍານົດການໂຕ້ຕອບເພື່ອຮັກສາສິ່ງທີ່ເປັນລະບຽບແລະບໍ່ມີຕົວຕົນ:

 from abc import ABC, abstractmethod import tensorflow as tf class ModelTrainer(ABC): @abstractmethod def train(self, data): pass class TensorFlowTrainer(ModelTrainer): def train(self, data): # TensorFlow-specific training logic model = tf.keras.models.Sequential([...]) model.compile(optimizer='adam', loss='sparse_categorical_crossentropy') model.fit(data, epochs=5) return model

ໂດຍການເຮັດອັນນີ້, ເຫດຜົນຫຼັກຂອງທ່ານບໍ່ໄດ້ສົມທົບຢ່າງແຫນ້ນຫນາກັບ TensorFlow. ຖ້າທ່ານຕ້ອງການປ່ຽນໄປໃຊ້ໂຄງຮ່າງການຮຽນຮູ້ຂອງເຄື່ອງຈັກອື່ນ, ມັນເປັນພຽງແຕ່ການຫັນປ່ຽນການຈັດຕັ້ງປະຕິບັດ.

Dependency Injection (DI) ແມ່ນເພື່ອນຂອງເຈົ້າ

ຕໍ່ໄປ, ໃຫ້ເວົ້າກ່ຽວກັບ Dependency Injection (DI). ເຕັກນິກນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດໃສ່ການປະຕິບັດສະເພາະຂອງການໂຕ້ຕອບຂອງທ່ານເຂົ້າໄປໃນຫ້ອງຮຽນຂອງທ່ານ, ຮັກສາ codebase ຂອງທ່ານ decoupled ແລະ modular.

 class TrainingPipeline: def __init__(self, trainer: ModelTrainer): self.trainer = trainer def execute(self, data): return self.trainer.train(data) # Inject the TensorFlowTrainer implementation pipeline = TrainingPipeline(TensorFlowTrainer())

ຕອນນີ້ລະຫັດຂອງທ່ານມີຄວາມຍືດຫຍຸ່ນ, ງ່າຍຕໍ່ການທົດສອບ, ແລະກຽມພ້ອມສໍາລັບສິ່ງທີ່ຈະເກີດຂຶ້ນໃນອະນາຄົດ.

ຮັບເອົາການປີ້ນຂອງການຄວບຄຸມ (IoC)

ເພື່ອຄວາມຢືດຢຸ່ນສູງສຸດ, ເອົາສິ່ງຕ່າງໆຂຶ້ນເປັນຈຸດໆດ້ວຍ Inversion of Control (IoC). ຮູບແບບນີ້ອະນຸຍາດໃຫ້ທ່ານລະບຸການປະຕິບັດໃນໄຟລ໌ການຕັ້ງຄ່າຫຼືສະຖານທີ່ສູນກາງໃນລະຫັດຂອງທ່ານ. ມັນແມ່ນຕົ້ນໝາກເຜັດຢູ່ເທິງສຸດຂອງສະຖາປັດຕະຍະກຳຂອງກອບ-ບໍ່ເຊື່ອຟັງຂອງເຈົ້າ.

ນີ້ແມ່ນຕົວຢ່າງຂອງວິທີການທີ່ອາດຈະເຮັດວຽກກັບວິທີການທີ່ອີງໃສ່ການຕັ້ງຄ່າ:

 # config.py class Config: TRAINER = 'my_project.trainers.TensorFlowTrainer' # main.py import importlib class TrainingPipeline: def __init__(self, trainer_class: str): module_name, class_name = trainer_class.rsplit('.', 1) module = importlib.import_module(module_name) trainer_cls = getattr(module, class_name) self.trainer = trainer_cls() def execute(self, data): return self.trainer.train(data) # Inject the trainer specified in the configuration from config import Config pipeline = TrainingPipeline(Config.TRAINER)

ດຽວນີ້, ຖ້າທ່ານຕ້ອງການປ່ຽນ TensorFlow ດ້ວຍກອບການຮຽນຮູ້ເຄື່ອງຈັກອື່ນ, ທ່ານພຽງແຕ່ປັບປຸງການຕັ້ງຄ່າແລະສືບຕໍ່. ບໍ່ hassle, ບໍ່ມີລະຄອນ.

ສະຫຼຸບ

ຈືຂໍ້ມູນການ, ກອບຄວນໃຫ້ບໍລິການສະຖາປັດຕະຍະກໍາຂອງເຈົ້າ, ບໍ່ແມ່ນກໍານົດມັນ. ດ້ວຍການວາງແຜນຢ່າງລະມັດລະວັງແລະການບໍ່ມີຕົວຕົນຂອງຍຸດທະສາດ, ທ່ານສາມາດເກັບກ່ຽວຜົນປະໂຫຍດຂອງກອບວຽກໂດຍບໍ່ມີການຕິດຢູ່ໃນການເພິ່ງພາອາໄສໃນໄລຍະຍາວ. trick ແມ່ນຢູ່ໃນການຄວບຄຸມ. ສະນັ້ນໃນຄັ້ງຕໍ່ໄປທີ່ເຈົ້າກຳລັງຈະລົງເລິກໃນກອບ, ຖອຍຄືນຫຼັງ ແລະ ເຕືອນຕົວເອງວ່າ: ເຈົ້າໂທຫາຮູບນີ້.

ຂອບໃຈສໍາລັບການອ່ານ!

ຄຳຖາມໃດ? ອອກຄໍາເຫັນຂອງທ່ານຂ້າງລຸ່ມນີ້ເພື່ອເລີ່ມຕົ້ນການສົນທະນາ fantastic!

ກວດເບິ່ງ blog ຂອງຂ້ອຍ ຫຼືມາເວົ້າສະບາຍດີ👋ໃນ Twitter ຫຼືຈອງ ຊ່ອງທາງໂທລະເລກຂອງຂ້ອຍ . ວາງແຜນທີ່ດີທີ່ສຸດຂອງເຈົ້າ!