จะเข้มงวดหรือจริงจัง?


13

ฉันเริ่มตระหนักแล้วว่าการพัฒนาซอฟต์แวร์เป็นกระบวนการหนึ่งในการถามคำถามตัวเองอย่างต่อเนื่อง คำถามเกี่ยวกับคุณภาพของรหัสการแยกข้อกังวลการลดการพึ่งพา ...

แต่คำถามหลักคือคุณจะไปได้ไกลแค่ไหนโดยไม่ต้องไปโรงพยาบาลโรคจิต?

ฉันสมัครงานใหม่ เมื่อวานฉันอยู่กับนายจ้างในอนาคตที่เป็นไปได้ที่ต้องการทดสอบความสามารถในการเขียนโปรแกรมของฉัน แบบฝึกหัดข้อหนึ่ง: อธิบายว่าโค้ดนี้ทำอะไร ฉันอ่านโค้ดของแอปพลิเคชั่น (winforms ใน vb.net) ที่พวกเขาพัฒนา (มันเป็นแอพพลิเคชั่นสำหรับผู้บริหารในโรงพยาบาล) นี่ทำให้ฉันมีโอกาสได้เห็นว่าพวกเขาเข้าใกล้สิ่งต่าง ๆ อย่างไรและมันค่อนข้างน่าผิดหวัง

ตัวอย่างบางส่วน:

  • ฉันเห็นบางแห่ง: โทร [ใส่ชื่อของรูทีนย่อยที่นี่] -> ฉันหลง: นั่นไม่ใช่อะไรจาก VB6 ใช่ไหม
  • พวกเขามีข้อมูลแยกต่างหากโดยใช้ ado.net แต่วิธีหนึ่งที่ฉันต้องตรวจสอบส่งกลับชุดข้อมูลไปยังชั้นที่เรียก แยกข้อมูลหรือไม่ดังนั้นแอปพลิเคชันจึงเชื่อมโยงกับ ado.net (ซึ่งอาจไม่เป็นปัญหาหากไม่เคยเปลี่ยนไปใช้วิธีการเข้าถึงข้อมูลอื่น)
  • ชุดข้อมูลนั้นอ่านตามสภาพดังนั้นจึงยังคงเป็นวิธีการที่ใช้ข้อมูลเป็นศูนย์กลาง (แน่นอนว่าเราสามารถยืนยันเหตุผล / พฤติกรรมที่คุณสามารถใส่ในคลาสเช่น "ผู้ป่วย" หรือ "LabAnalysisRequest" ได้
  • ฉันยังเชื่อว่าได้เห็นการสร้างแบบสอบถาม SQL โดยการต่อข้อมูลสตริง
  • พวกเขาใช้วิธีการเก็บ (ซึ่งสำหรับฉันหมายถึง: การกระจายของตรรกะ)
  • ไม่เอ่ยถึงมุมมอง / ตัวควบคุม: มันขับเคลื่อนทุกรูปแบบ
  • สิ่งที่น่าเกลียดที่สุดที่ฉันเห็นคือ:
        ถ้า TestEnvironment.Intesting แล้ว
           someVar = [ค่าฮาร์ดโค้ดบางตัว]
        อื่น
           someVar = [บางค่าที่ถูกดึงแบบไดนามิก]
        จบถ้า
        [ส่วนที่เหลือของฟังก์ชันที่นี่]
    

ทุกอย่างแตกต่างจากสิ่งที่ฉันเรียนในโรงเรียน: (ผู้ไม่เชื่อเรื่องพระเจ้าคงอยู่) ชั้นโดเมน, ชั้นติดตา, ชั้นนำเสนอ, การทดสอบหน่วย ...

ดังนั้นฉันจึงเรียบเรียงคำถามของฉันใหม่: พื้นฐานหรือดันทุรังควรเป็นอย่างไร โปรแกรมเมอร์ควรยึดติดกับหลักการของเขาหรือเธอในระดับใดหรือเพียงแค่เขียนโค้ดที่ทำงานได้?


2
อาจเป็นของ prorammers.stackexchange เนื่องจากมันเกี่ยวข้องกับการอภิปรายทั่วไปของการพัฒนาซอฟต์แวร์และไม่ใช่ปัญหาเฉพาะกับบล็อคของรหัส
taylonr

7
ในด้านวิชาการของโลกไม่มีกำหนดเวลา ในด้านธุรกิจของโลกเกือบทุกครั้งจะมีกำหนดส่ง และมักจะเร็วเกินไป
Carlos Campderrós

1
ฉันเห็นด้วยกับคาร์ลอ เมื่อฉันเริ่มใช้งานกิ๊กในปัจจุบันทัศนคติของฉันที่มีต่อรหัสคือ "ฉันไม่อยากจะเชื่อเลยว่ารหัสนี้เป็นสิ่งที่น่ารังเกียจมาก!" หลังจากนั้นไม่กี่สัปดาห์ทัศนคติก็เปลี่ยนไปเป็น "ฉันไม่อยากจะเชื่อว่ารหัสนี้เป็นเพียงสิ่งที่น่ารังเกียจนี้" มันเป็นคำพูดที่เก่า: "คุณภาพความเร็วราคาเลือกสองอย่าง" การสร้างรหัสที่ดีอาจช้าหรือมีราคาแพงและบางครั้งก็ไม่มีตัวเลือก
Satanicpuppy

1
การฝึกอบรมอย่างเป็นทางการของฉันมี จำกัด ดังนั้นความเชื่อ / พื้นฐานของฉันค่อนข้างอ่อนแอ หากฉันไม่ได้ใช้งานจริงฉันจะใช้เวลานาน (มากกว่าตอนนี้) ในการขุดเอกสารหรือเยี่ยมชมฟอรัม ด้านพลิกคือเมื่อฉันเป็นโปรแกรมเมอร์ฉันเรียนรู้วิธีที่จะไม่เขียนโปรแกรม นั่นอาจหมายถึงพื้นฐานหรือความเชื่อของฉันกำลังเติบโต ฉันทำงานให้กับ บริษัท เล็ก ๆ เพราะฉันเป็น coder ที่มีประสบการณ์มากที่สุดและเมื่อมีโครงการที่ต้องทำใน X Days ฉันไม่มีทางเลือกนอกจากต้องตัดมุมพื้นฐานเหล่านั้น เอกสารอินไลน์ที่ดีนั้นจำเป็นสำหรับเมื่อคุณเห็นมันอีกครั้งและไปที่ "WT ??"
TecBrat

3
หากสิ่งที่น่าเกลียดที่สุดที่คุณเห็นIf TestEnvironment.IsTesting thenนั้นเป็นรหัสที่ค่อนข้างดี

คำตอบ:


21

ฉันรู้ว่าไม่ได้ตอบคำถามของคุณโดยตรง แต่ฉันยังรู้สึกว่ามันมีค่ามากกว่าความคิดเห็น:

เมื่อคุณทำเช่นการสัมภาษณ์งานที่คุณกำลังสัมภาษณ์พวกเขามากที่สุดเท่าที่พวกเขาจะสัมภาษณ์คุณ เลิกนิสัยที่เห็นการสัมภาษณ์เป็นสิ่งที่คุณคลานไปที่ท้องขอร้องให้พวกเขาเสนออะไรบางอย่างให้คุณ พวกเขาชำระเงินให้คุณ แต่คุณก็ชำระเงินด้วย หากพวกเขาไม่ชอบคุณพวกเขาจะไม่จ้างคุณ หากคุณไม่ชอบพวกเขาอย่าไปทำงานที่นั่น

ใช่ในอุตสาหกรรมที่มีรหัสฐานสิบปีที่แฮ็กไปเมื่อเวลาผ่านไปโดยนักพัฒนาสามโหลที่มีภูมิหลังทักษะและความหลงใหลต่างกันขับเคลื่อนโดยกำหนดเวลาที่เข้มงวดขาดทรัพยากรและข้อ จำกัด ทางการเงิน ดูวิธีการที่คุณ (ควร) ได้เรียนรู้มันควรจะดู คุณจะต้องทำสัมปทาน แต่มีกี่ตัวที่คุณวาดเส้นตรงนั้นขึ้นอยู่กับคุณ
แน่นอนว่างานนั้นยากกว่าที่จะหาสัมปทานที่น้อยลง แต่พวกเขาอาจจะสนุกมากขึ้น

FWIW ฉันมีจนถึงตอนนี้ (มากกว่า 10 ปีในอุตสาหกรรม) ไม่เคยทำงานใน บริษัท ใหญ่ที่มีนักพัฒนาหลายคน (นักพัฒนา ~ 30 คนเป็นคนที่ดีที่สุดนับเป็นบรรทัดฐาน) เพราะมันมีโอกาสมากที่คุณจะเปลี่ยนอะไรเล็ก ๆ น้อย ๆ บริษัท. ตราบใดที่ฉันทำเงินได้มากพอที่จะไม่ทำให้เด็กอดอยากฉันก็ไม่อยากเป็นล้อเฟืองเล็ก ๆ ใน บริษัท ใหญ่ ๆ ที่ซึ่งฉันต้องทำทั้งหมดก็คือการซิงค์กับอุปกรณ์อื่น ๆ
ฉันปฏิเสธข้อเสนองานหลังจากเห็นการทดสอบที่พวกเขาต้องการให้ฉันผ่าน ฉันเป็นนักพัฒนา C ++ และมีการทดสอบ C ++ มากมายที่นั่นแย่มากมันทำให้เล็บเท้าของคุณขดตัวด้วยความขยะแขยงและฉันไม่ต้องการใช้เวลาต่อสู้กับกังหันลมเพราะพวกเขาจ้าง morons ที่ไม่สามารถเขียนโค้ดที่สะอาดได้
ฉันได้ออกจากงานหลังจากสองสามเดือนเพราะปรัชญาการเขียนโปรแกรมของพวกเขา (เป้าหมายระยะสั้นไม่เป็นไรในปีหน้า) ไม่เหมาะสมกับความสามารถของฉัน (เสถียรภาพของรหัสระยะยาว) แม้ว่าพวกเขาจะพูดแตกต่างกันในการสัมภาษณ์


เกิดอะไรขึ้นกับการทดสอบ C ++
คุกกี้แป้งข้าว

2
@ ข้าว: พวกเขามีข้อบกพร่องในคำถาม
sbi

3
ฉันจะเพิ่มว่าถ้าคุณเดินเข้าไปใน บริษัท ที่ให้ความสนใจกับสิ่งที่คุณเรียนรู้ในโรงเรียนคุณจะได้เรียนรู้มากกว่าทำงานใน บริษัท ที่คุณต้องให้ความรู้เกี่ยวกับพื้นฐาน
กุสตาฟ Bertram

1
ความคิดเห็นของฉันอาจจะเป็นวง แต่คำตอบของคุณทำให้ฉันเข้าใจว่าทำไมไม่ควรตกหลุมพราง "บริษัท ใหญ่" และทำไมการออกจาก บริษัท ใหญ่ในเวลาไม่กี่เดือนด้วยเหตุผลที่คุณอธิบายไว้ข้างต้น ขอบคุณสำหรับสิ่งนั้น
Tarun

5

อย่าเขียนโค้ดที่ใช้งานได้ อย่างไรก็ตามเต็มใจที่จะตรวจสอบหลักคำสอนของคุณอย่างเท่าเทียมกัน เพียงเพราะคุณเรียนในโรงเรียนไม่ได้หมายความว่ามันเป็นความคิดปัจจุบันหรือแม้แต่ความคิดที่ถูกต้อง วงจรชีวิตการออกแบบซอฟต์แวร์ล้าสมัยเนื่องจากการเขียนโปรแกรมจะต้องมีปฏิกิริยาต่อโลกธุรกิจมากขึ้น บางครั้งซอฟต์แวร์โซลูชันที่เชื่อมโยงอย่างเชื่องช้ามีการเชื่อมโยงอย่างเชื่องช้าเนื่องจากชิ้นส่วนถูกแทนที่ตามเวลาที่อนุญาต

นี่คือรายการปัญหาที่ฉันได้รวบรวมซึ่งจะกำหนดว่าคุณเหมาะสมกับไลฟ์สไตล์การเขียนโปรแกรมของ บริษัท ได้ดีเพียงใด

  1. พวกเขาให้ความสำคัญกับการตั้งค่าเวลาในการปรับโครงสร้างใหม่และทำให้รหัสฐานเป็นปัจจุบัน วิธีที่พวกเขาดูการอัปเดตรหัสฐานจะเป็นปัจจัยกำหนดที่สำคัญในการที่คุณเหมาะสม
  2. บ่อยครั้งที่พวกเขาซื้อบุคคลที่สามแทนการเข้ารหัสในบ้าน
  3. พวกเขาคิดอย่างไรกับซอฟต์แวร์โอเพนซอร์ซ พวกเขารู้หรือไม่ว่าพวกเขามีความยืดหยุ่นในการเปลี่ยนรหัส พวกเขาดูเช่นเดียวกับการซื้อบุคคลที่สามหรือไม่
  4. คุณจะทำงานในเลเยอร์นามธรรมที่แน่นอน ทีมงานที่คุณติดต่อประสานงานกับคุณจะกำหนดอินเทอร์เฟซสำหรับคุณหรือไม่ เลเยอร์ / ทีม / อินเทอร์เฟซใดมีอำนาจในการตัดสินใจมากกว่า
  5. หัวหน้างานรับฟังโปรแกรมเมอร์มากน้อยเพียงใดเมื่อตัดสินใจ เมื่อโปรแกรมเมอร์โยนธงแดงผู้ดูแลจะหยุดและทบทวนการตัดสินใจของพวกเขา
  6. คุณพิจารณาโปรแกรมเมอร์ที่มีประสบการณ์ด้านการจัดการหรือไม่? พวกเขาดูประสบการณ์ของพวกเขาอย่างไร? ประสบการณ์ของพวกเขาถูกต้องหรือไม่? พวกเขาปล่อยให้ประสบการณ์ที่ล้าสมัยส่งผลกระทบต่อการตัดสินใจหรือไม่?
  7. รหัสฐานเหนียวแค่ไหน?
  8. พวกเขาอัพเดตเครื่องมือการเขียนโปรแกรมบ่อยแค่ไหน (IDE, ฯลฯ )

คำตอบสำหรับคำถามเหล่านี้ดีกว่าเหมาะสมกับวิธีที่คุณจะให้ความสำคัญกับไลฟ์สไตล์การเขียนโปรแกรมของพวกเขากว่าดูว่าพวกเขาตรงกับความเชื่อของคุณ

Dogma จะพังอย่างหลีกเลี่ยงไม่ได้ (เราไม่มีเวลาอัปเดต X) อย่างไรก็ตามลำดับความสำคัญจะกำหนดว่าคุณปะทะกับสไตล์และการตัดสินใจของพวกเขามากแค่ไหน


4

ฉันคิดว่าคุณต้องชั่งน้ำหนักสิ่งนี้เป็นส่วนหนึ่งของทั้งหมด ฉันจำได้ว่าหนึ่งในงานแรกของฉันคือตำแหน่งในกลุ่มที่บอกฉันว่าพวกเขากำลังทำ C ++ เชิงวัตถุ - ซึ่งเป็นสิ่งที่ฉันเพิ่งทำไปหลายปีในโรงเรียน

การประเมินตนเองของพวกเขาผิด - พวกเขากำลังทำสิ่งที่ค่อนข้างเป็นก้อน C. มันยังคงได้รับการออกแบบให้ใช้งานได้ตามธรรมชาติและฉันต้องไปรับหนังสือ C เพื่อสอนตัวเอง printf และ getf และกลไก C อื่น ๆ ที่ฉันไม่เคยเรียนรู้ ความจริงที่ว่าไม่มีใครในทีมรู้ได้อย่างไรว่ารหัสที่ชอบของพวกเขาคืออะไรชี้ให้เห็นว่าเครื่องหมาย "การออกแบบ C ++" นี้ลดลงได้อย่างไร เป้าหมายของฉันในเวลานั้นคือการพัฒนา OO ดังนั้นนี่จึงเป็นเรื่องที่ไม่น่าสนใจ

แต่ในที่สุดฉันก็ดีใจที่ติดอยู่กับทีม พวกเขาเป็นกลุ่มที่มีพลวัตของคนที่ฉลาดมากและฉันทำให้ฉันเปียกด้วยปัญหามากมายฉันต้องทำงานตลอดวงจรชีวิตและสิ่งที่ฉันได้เรียนรู้เกี่ยวกับโดเมนปัญหา (PKI) เป็นแรงผลักดันอาชีพของฉันนับตั้งแต่ งานที่ทีมทำในพื้นที่การทำงานนั้นยอดเยี่ยมมากและฉันก็ยังคิดว่าผลิตภัณฑ์และประสบการณ์นั้น ๆ ยังดีกว่า - ฉันยังคงทำงานกับคนเหล่านี้บางคนในวันนี้ (หลาย บริษัท ในภายหลัง) พวกเขายังคงเป็นแรงบันดาลใจและเรายังคงทำงานได้ดี

ฉันไม่คิดว่าการใช้งานที่สมบูรณ์แบบของแนวปฏิบัติที่ดีที่สุดของภาษาการเข้ารหัสคือการสร้างหรือทำลายประสบการณ์การทำงานที่ดีหรือเป็นทีมที่ดี - งานที่กระตุ้นอาชีพมีมากขึ้นกว่านั้นและหากผลิตภัณฑ์มีความเหมาะสม คุณภาพทีมงานมีสภาพการทำงานที่ดี (เช่น Joel Test) และทีมงานเต็มไปด้วยผู้คนที่ฉลาดและทำสิ่งต่าง ๆ ได้อย่างสมบูรณ์แบบ นำปัจจัยต่าง ๆ ออกไปเช่นการทำงานที่ดีคนดีสภาพการทำงานที่ดี - และมันก็ไม่คุ้มค่าที่จะเกาะติด - ไม่ว่าจะมีการใส่รหัสแปลก ๆ หรือไม่ก็ตาม


ฉันต้องเลื่อนลงเพื่อดูว่าฉันไม่ได้เขียนสิ่งนี้!

4

วิธีการพื้นฐานหรือดันทุรังควรเป็นอย่างไร โปรแกรมเมอร์ควรยึดติดกับหลักการของเขาหรือเธอในระดับใดหรือเพียงแค่เขียนโค้ดที่ทำงานได้?

สิ่งสำคัญที่สุดที่ต้องจำไว้ที่นี่คือจุดประสงค์ของคุณคืออะไร

ใน บริษัท ส่วนใหญ่จุดประสงค์ในชีวิตของคุณคือการไม่เขียนโค้ดที่สมบูรณ์แบบ จุดประสงค์ของคุณคือส่งมอบคุณค่าให้กับผู้ใช้ การเขียนโค้ดที่ดีมักเป็นวิธีที่ดีที่สุดในการส่งมอบผลิตภัณฑ์ที่ดีซึ่งง่ายต่อการดูแลรักษาปัญหาและการพัฒนา

รหัสที่ดีคือเครื่องมือที่คุณควรนำไปใช้ซึ่งจะให้ผลตอบแทนการลงทุนที่ดีแก่คุณ

ตัวอย่างบางส่วน:

  1. ฉันจะใช้เวลามากมายในการออกแบบและเขียนโค้ด API โดยเฉพาะ API ระดับธุรกิจของฉัน โปรแกรมเมอร์อื่น ๆ จำนวนมากกำลังใช้งานอยู่และจะช่วยประหยัดเวลาและปัญหาได้มากหากออกแบบมาอย่างเหมาะสม
  2. ฉันจะผ่อนคลายกฎเล็กน้อยในเลเยอร์การนำเสนอของฉัน ที่นั่นฉันจะมีแนวโน้มที่จะเสียสละรหัส "ความสมบูรณ์แบบ" เพื่อสนับสนุนการเพิ่มคุณสมบัติเพิ่มเติม

บรรทัดล่างคุณต้องมีหลักการ แต่คุณควรมีความยืดหยุ่นเพียงพอที่จะทำลายหลักการเหล่านั้นเมื่อพวกเขานำอันตรายมากกว่าคุณค่า


3

ฉันทำงานให้กับผู้ค้าปลีกอีคอมเมิร์ซมาสองสามปี เมื่อฉันเริ่มต้นที่นั่นรหัสสำหรับแอปพลิเคชันภายในของพวกเขาทั้งหมดเขียนใน VB สำหรับ MS Access และมันก็น่ากลัวที่จะพูดน้อยที่สุด ฉันมีทีมนักพัฒนา 3 คนและในอีกไม่กี่ปีข้างหน้าเราแทนที่มันด้วยแอปพลิเคชั่น VB.Net ที่เหมาะสม

แต่เนื่องจากงบประมาณการจ้างงานของฉันมี จำกัด อย่างมากฉันสามารถทำได้แค่โปรแกรมเมอร์ระดับต้น ๆ เท่านั้น และแน่นอนว่ารหัสที่พวกเขาผลิตนั้นไม่ได้ยอดเยี่ยมเท่านี้ แต่มันใช้งานได้และ บริษัท ใช้โปรแกรมเหล่านี้เพื่อทำเงินทุกวัน

จากนั้นฉันก็เริ่มทำงานกับพวกของฉัน การฝึกอบรมเล็กน้อยใน OOD ในการออกแบบฐานข้อมูลใน MVC และ C # และหลายปีที่ผ่านมาสิ่งต่าง ๆ ก็ดีขึ้น เมื่อฉันจากไป 4 ปี codebase ก็ยังไม่ดี แต่มันดีกว่าตอนที่ฉันเริ่ม 100 เท่า

สถานการณ์เช่นเดียวกับที่คุณอธิบายมักเป็นผลมาจากการที่ต้องทำกับทรัพยากรที่มีอยู่ เราไม่ได้อยู่ในโลกอุดมคติ ในเวลาเดียวกันนี่เป็นโอกาสที่ดีที่จะสร้างความแตกต่าง

BTW: แอปพลิเคชั่นเหล่านี้บางส่วนยังคงใช้งานอยู่แทบไม่เปลี่ยนแปลงเมื่อประมาณ 3 ปีที่ผ่านมาและยังคงทำเงินอยู่


สิ่งที่ดีเกี่ยวกับกล่องดำคือคนไม่สามารถมองเห็นความมืดภายใน

3

ฉันคิดว่าการยึดมั่นในหลักการของคุณเป็นสิ่งสำคัญมาก คุณควรพยายามสร้างรหัสที่ดีที่สุดเท่าที่จะทำได้ภายในข้อ จำกัด ที่ให้ไว้ อย่างไรก็ตามหากคุณเพิ่ม "ไม่ควรอ่านหรือเปลี่ยนรหัสที่ไม่ดี" ในรายการหลักการของคุณคุณจะมีปัญหาในการหางานจำนวนมาก จำไว้ว่าโปรแกรมเมอร์ 50% จบการศึกษาในครึ่งล่างของชั้นเรียน แม้แต่ในทีมชายคนหนึ่ง "วันนี้คุณ" มีคุณสมบัติที่ดีกว่าในการแก้ปัญหามากกว่า "เมื่อเดือนที่แล้ว" ความสามารถในการทำงานกับโค้ดที่ไม่เหมาะเป็นเพียงส่วนหนึ่งของงาน

นายจ้างจำนวนมากรับรู้ว่าดังนั้นพวกเขาจึงให้พวกเขาอ่านรหัสอาจเป็นตัวแทนของรหัสที่เลวร้ายที่สุดในฐานรหัสของพวกเขามากกว่าที่ดีที่สุดของพวกเขา หากไม่ชัดเจนจากบริบทคุณควรถาม เพื่อนร่วมงานคนหนึ่งที่ฉันสัมภาษณ์ในบางครั้งมีหน้ารหัสที่เขาตั้งใจเขียนไม่ดีเพียงเพื่อใช้เป็นคำถามสัมภาษณ์


2

ใน 99% เปอร์เซ็นต์ของกรณีคุณควรติดอยู่กับ« dogma »ตามที่คุณเรียกมันว่า ความเชื่อถูกสร้างขึ้นโดยบุคคลที่มีประสบการณ์ในการฝึกฝนมานานหลายปีและสิ่งที่ดูเหมือนเป็นประโยชน์ในบางครั้งมักจะไม่ใช่ นี่มักจะเกี่ยวข้องมากกว่าความจริงที่ว่าคุณไม่ดีพอที่จะจัดการกับปัญหานั้นได้อย่างถูกต้อง

อย่างไรก็ตามอย่าทำตามคำแนะนำอย่างเด็ดขาด โปรดจำไว้ว่าข้อสรุปใดที่ทำให้คนติดตามความเชื่อนั้น เพราะคุณจะพบกรณีเล็ก ๆ น้อย ๆ ที่ไม่ควรติดตาม อย่างไรก็ตามกรณีเหล่านี้จะหายากมากและคุณควรปรึกษากับโปรแกรมเมอร์ที่มีประสบการณ์บางคนก่อนตัดสินใจ


ฉันคิดว่าคุณสับสน "dogma" กับ "แนวปฏิบัติที่ดีที่สุด"
Toby

นี่คือเหตุผลที่ฉันเขียน« dogma »และไม่ใช่แค่ dogma
deadalnix

ว้าวฉันไม่ได้มีสองปุ่มเหล่านั้นบนแป้นพิมพ์ของฉัน ไม่น่าแปลกใจที่ฉันไม่ได้ใช้

2

จงเข้มงวดเมื่อมันสำคัญ รั้งสไตล์ (หรือการประชุมการเข้ารหัสอื่น ๆ )? มันไม่สำคัญ ใช้ที่ร้านใช้ การแยก encapsulation (หรือหลักการการเขียนโปรแกรมพื้นฐานอื่น ๆ ) โดยไม่มีเหตุผลที่ดี? ไม่น่ารำคาญเลย

การแลกเปลี่ยนแบบสแต็กใช้ตารางสำหรับโครงร่าง (เช่นเดียวกับเว็บไซต์สำคัญอื่น ๆ อีกมากมายที่สร้างรายได้ ) นั่นทำให้ควันออกมาจากหูของนักปราชญ์หรือไม่? แน่นอนมันทำ แต่ลัทธิปฏิบัตินิยมชนะความบริสุทธิ์ทุกครั้ง การจัดส่งสินค้าเป็นเรื่องที่สมบูรณ์แบบทุกครั้ง

เลเยอร์ทั้งโดเมน, ชั้นการคงอยู่, ชั้นการนำเสนอ, การทดสอบหน่วยยังค่อนข้างใหม่จากมุมมองทางประวัติศาสตร์ มีซอฟต์แวร์จำนวนมากที่ยังคงใช้รูปแบบไคลเอนต์ / เซิร์ฟเวอร์และจะไม่ถูกเปลี่ยนเป็นรูปแบบสถาปัตยกรรมล่าสุดเพียงเพราะเป็น "ดีกว่า"

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.