Ruby on Rails ข้อเสียและ caveats [ปิด]

นี่ไม่ใช่การเปิดช่องทางสำหรับการทุบตี RoR - ซื่อสัตย์!

ฉันเรียนรู้กรอบ Ruby และ Rails ดูเหมือนว่าพรีม่าจะดูเท่ห์และเป็นประสบการณ์ที่ยอดเยี่ยมเมื่อเทียบกับ PHP (อันที่จริงมันทำให้ฉันนึกถึงวันที่มีความสุขมากขึ้นด้วย C # และ. NET)

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

(บางทีนี่อาจจะทำให้ชุมชนเป็น wiki?)

นี่คือประสบการณ์การเรียนรู้การเรียนรู้อย่างต่อเนื่องและการเขียนแอปพลิเคชันที่ค่อนข้างง่ายใน Rails

1) Curve การเรียนรู้

Rails นั้นหลอกลวงง่าย บทเรียนวิดีโอและหนังสือทั้งหมดแสดงให้เห็นว่าคุณสามารถใช้งานแอปพลิเคชั่น (ถ้าน่าเกลียด) ได้รวดเร็วแค่ไหน แต่สิ่งเหล่านี้เป็นเพียงรอยขีดข่วนบนพื้นผิว พวกเขามักจะพึ่งพาการสร้างรหัสอย่างมากและ "การนั่งร้าน" ซึ่งเป็นที่ยอมรับว่าเป็นเครื่องมือที่ดีเมื่อเรียนรู้

ไม่ผิดพลาด Rails เป็นเรื่องยากที่จะเชี่ยวชาญ เมื่อคุณได้รับข้อมูลพื้นฐานเบื้องต้น (เพิ่มเติมในภายหลัง) คุณจะต้องวิ่งไปที่กำแพงหากคุณต้องการฟังก์ชั่น "แอพตัวอย่าง" ที่เรียบง่ายซึ่งคุณเห็นว่ามีการโน้มน้าว คุณสามารถรับความรู้พื้นฐานของ Ruby ในขณะที่เรียนรู้ได้ แต่คุณต้องรีบรับ Ruby มิฉะนั้นคุณจะต้องอยู่ในที่สูงและแห้ง (และไม่ใช่ประเภทที่ดีDRY) หากคุณต้องการออกไปข้างนอกข้อ จำกัด ของ Rails

ทางรถไฟเป็นอย่างที่ผมชอบที่จะเรียกมันในทางที่รักการวาดโดยตัวเลขการเขียนโปรแกรม หากคุณติด 100% ของการประชุม (เช่นอยู่ในเส้นและใช้สีที่คุณบอกให้ใช้) คุณสามารถสร้างแอปพลิเคชันที่เหมาะสมได้อย่างรวดเร็วและง่ายดาย ถ้าและเมื่อไหร่ที่คุณต้องเบี่ยงเบนแม้ว่า Rails สามารถเปลี่ยนจากเพื่อนที่ดีที่สุดไปเป็นศัตรูที่เลวร้ายที่สุดของคุณได้

2) เมื่อสิ่งที่คุณมีคือค้อน ...

Rails ใช้งาน CRUD อย่างง่ายได้ดีมาก ปัญหาเกิดขึ้นเมื่อแอปของคุณต้องทำมากกว่าอ่าน / เขียนจากฐานข้อมูล ตอนนี้สำหรับบันทึกรุ่น Rails ล่าสุดที่ฉันใช้คือ 2.3.4 ดังนั้นสิ่งต่าง ๆ อาจเปลี่ยนแปลงไปตั้งแต่นั้นมา แต่ฉันพบปัญหาสำคัญเมื่อความต้องการทางธุรกิจเปลี่ยนไปดังนั้นแอปพลิเคชันจึงต้องมีระบบเวิร์กโฟลว์ขนาดเล็กติดตั้งอยู่ภายใน แอปพลิเคชั่น PHP รุ่นเก่า การประชุม Rails ของ "หนึ่งรูปแบบหนึ่งแบบจำลอง" ใช้ได้ดีสำหรับแอพพลิเคชั่นเล็ก ๆ น้อย ๆ และแอพพลิเคชั่นการป้อนข้อมูล แต่ไม่มากเมื่อคุณต้องการประมวลผลเชิงตรรกะหรือมีเวิร์กโฟลว์หรืออะไรก็ตามที่ไม่ใช่ "ผู้ใช้ทั่วไป ฟิลด์ข้อความสองสามรายการส่ง "ประเภทของสิ่งต่างๆ มันสามารถทำได้ แต่มันไม่ได้หมายความว่า "ง่าย" หรือมากกว่านั้น

นอกจากนี้ Rails ไม่ชอบที่จะเล่นได้ดีกับแอพพลิเคชั่นอื่น ๆ ที่ไม่ได้ใช้มันเป็นวิธีการเข้าถึงข้อมูลที่ต้องการ; หากคุณต้องติดต่อกับแอพพลิเคชั่นที่ไม่มี API สไตล์ "Web 2.0" คุณจะต้องหลีกเลี่ยง Rails แทน ฉันพูดจากประสบการณ์ที่นี่อีกครั้งเพราะนี่คือสิ่งที่เกิดขึ้นกับฉัน

3) มันใหม่

ในที่สุด Rails ยังคงเป็น "เด็กใหม่บนบล็อก" ในหลายพื้นที่ สิ่งนี้ไม่สำคัญสำหรับการใช้งานส่วนตัวหรือ "ฉันคิดว่ามันเจ๋งและต้องการเรียนรู้" ประเภทของสถานการณ์ แต่พูดเป็นคนที่ต้องการใช้ Rails ในงานประจำวันของฉันถ้าคุณไม่ได้อยู่ในสถานที่ที่ Rails อยู่ มันอาจเป็นเรื่องยากมากที่จะหางานเต็มเวลาในฐานะผู้พัฒนา Rails มันยังคงเป็นโดเมนหลักของ "hip, startups ใหม่" และไม่ใช่ผู้เล่นหลักในพื้นที่ส่วนใหญ่ ระยะทางของคุณอาจแตกต่างกันในเรื่องนี้ แต่ฉันรู้ว่าพื้นที่ของฉัน (แทมปา) ทางรถไฟนั้นไม่มีอยู่จริง

4) ไฟและการเคลื่อนไหว

Rails เปลี่ยนแปลงตลอดเวลา นี่เป็นทั้งสิ่งที่ดีและไม่ดี; เป็นเรื่องที่ดีเพราะชุมชนวิวัฒนาการและรวบรวมแนวคิดใหม่ มันไม่ดีเพราะชุมชนวิวัฒนาการและรวบรวมแนวคิดใหม่ อาจเป็นเรื่องยากสำหรับมือใหม่ที่เพิ่งเปิดตัว Rails เพราะโดยทั่วไปเมื่อคุณพบเจอปัญหาและมองไปรอบ ๆ คุณจะเห็นคนที่แนะนำอัญมณีที่มีคุณสมบัติเช่นนี้เพื่อแก้ไขมันหรือบอกว่ามันแย่มากและคุณไม่ควร อย่าใช้นี่เป็นวิธีที่ดีกว่า ... และคุณจะได้รับรายการเครื่องมือเพิ่มเติมเพื่อเรียนรู้พร้อมกับ Rails เพื่อติดตามความรู้ของ Rails สิ่งที่ชอบGit, BDD/RSpec, Cucumber,Haml/Sassและความอุดมสมบูรณ์ของสิ่งอื่น ๆ ลอยอยู่รอบ ๆ และได้รับการผลักดันให้เป็น "วิธีการที่เหมาะสมที่จะทำสิ่ง" ใน Rails ที่ดินและพูดจากประสบการณ์ที่คุณอาจจะจบลงด้วยการถูกล้นมือพยายามที่จะเรียนรู้โหลหรือเทคโนโลยีอื่น ๆ อีกมากมายนอกจากนี้การรถไฟ เพราะการใช้ชุดเครื่องมือ Rails มาตรฐานรู้สึกว่า "ผิด"

ตอนนี้ถูกรวมเข้าด้วยกันมากขึ้นโดย Rails 3.1 ทำให้ Sass และ CoffeeScript ทุกอย่างเป็นค่าเริ่มต้นดังนั้น Rails ที่เพิ่งเริ่มต้นใหม่ไม่เพียง แต่ต้องเรียนรู้ Ruby และ Rails เท่านั้น แต่ Sass (ง่าย ๆ ถ้าคุณรู้ CSS) และ CoffeeScript (ไม่ใช่เรื่องยาก แตกต่างจาก JavaScript ดิบ) อย่างน้อยที่สุดเพื่อเริ่มต้นใช้งานรวมทั้งสามารถสันนิษฐานได้ว่า Git แม้จะไม่มีแฟคตอริ่งใน RSpec และเพื่อน ๆ รวมถึงอัญมณีที่คุณมักจะลงท้ายด้วยนั่นก็คือสิ่งต่าง ๆ4อย่างที่คุณต้องเรียนรู้ก่อนที่คุณจะเริ่มเขียนแอพพลิเคชั่นของ Rails ได้อย่างจริงจัง เปรียบเทียบสิ่งนี้กับภาษาเช่น C # หรือ Java หรือแม้กระทั่ง PHP ที่ความรู้ HTML / CSS / JavaScript / SQL ของคุณจะไม่เปลี่ยนแปลงและคุณเพียงแค่ต้องเรียนรู้ภาษาเองและบางทีความแตกต่างของกรอบงาน

เอกสาร

ในขณะที่Rails Guideเป็นแหล่งการเรียนรู้ที่ยอดเยี่ยมการอ้างอิงของ Rails (และ Ruby โดยทั่วไป) ไม่ใช่เรื่องง่าย บอกว่าคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับbelongs_toวิธีการ แม้ว่ามันจะถูกใช้กับActiveRecord::Baseคลาสย่อย (โมเดลหนึ่งชิ้น) มันไม่ได้บันทึกไว้ในActiveRecord::Baseเอกสาร แต่เป็นมิกซ์อินที่คลาสนำเข้า เป็นหลักคุณไม่สามารถดูรายการที่ครอบคลุมของวิธีการทั้งหมดที่คุณสามารถใช้กับวัตถุในที่เดียว (ยกเว้นเมื่อคุณยิงขึ้นirbและตรวจสอบวัตถุเอง)

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

Ruby on Rails มีช่วงการเรียนรู้ที่สำคัญ ก่อนอื่นคุณต้องเรียนรู้ภาษาแปลก ๆ จากนั้นเรียนรู้กรอบจากนั้นเรียนรู้วิถีทางของการทำสิ่งต่างๆแล้วเรียนรู้เกี่ยวกับอัญมณีที่ใช้กันทั่วไปมากมาย

อย่างไรก็ตามเมื่อคุณได้เรียนรู้สิ่งเหล่านั้นมันจะเกิดขึ้นอย่างไม่น่าเชื่อ ในความเป็นจริงกรอบอื่น ๆ เริ่มรู้สึกเหมือนเป็นภาระ

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

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

TDD ไม่รู้สึกเหมือนเป็นงานเพิ่มเติมใน RoR มันรู้สึกเหมือนเป็นวิธีเดียวที่จะทำงาน

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

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

จากประสบการณ์ส่วนตัวของฉันปวดหัวที่สำคัญคือรอบการทำงานร่วมกัน

เมื่อ:

• มีการxติดตั้งโครงการราง
• แต่ละโครงการใช้yอัญมณี
• ในขณะที่มีnรุ่นของราง
• รวมถึงmเวอร์ชั่นของอัญมณีที่ติดตั้ง
• กับseveralรุ่นของทับทิม
• บนกล่อง Linux หนึ่งกล่องเป็นเครื่องใช้งานจริง
• โปรแกรมเมอร์ทำงานบนโน้ตบุ๊กพัฒนา OS X เครื่องอื่น

ในฐานะที่เป็นอิสระที่ไม่ได้หรูหราเพื่อปรับปรุง / อัพเกรดมากที่สุดของสิ่งที่จะต้องเผชิญกับจำนวนมากของปัญหาความเข้ากันจากตัวแปรข้างต้น ... ในขณะที่rails, gemsและrubyให้เปลี่ยน / พัฒนา

ความเร็วเป็นปัญหาอย่างแน่นอน ความยืดหยุ่นที่สุดขีดของรูบี้มาพร้อมกับประสิทธิภาพที่ยอดเยี่ยม

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

เมื่อเปรียบเทียบกับ RoR นั้นช้ามาก เวลาในการจัดการคำของ่าย ๆ มีความสำคัญและเป็นปัญหาในการจัดการกับลูกค้าจำนวนมาก (นี่คือทั้งหมดที่จะเห็นได้ในความสัมพันธ์กับทางเลือกที่เร็วกว่า)

เพื่อประโยชน์ในการวางแนวที่คลุมเครือนี่คือตัวเลขบางส่วนเปรียบเทียบภาษาอื่น ๆ ที่เหมาะสมสำหรับการพัฒนาเว็บกับ Ruby:

• ไป
• Clojure
• JavaScript V8 ( node.js )
• JRuby (ทางเลือกที่ไม่ควรลืม - ขึ้นอยู่กับพื้นที่ที่คุณมีปัญหา JRuby อาจเป็นทางเลือกที่ดีกว่าหรือแย่กว่าในการใช้แอพพลิเคชั่นทางรถไฟ)
• สกาล่า
• ชวา
• C #

โปรดทราบว่านี่ไม่ได้หมายความว่าถ้าคุณใช้ Framework X สำหรับ Java ว่าจะเร็วกว่า RoR 200 เท่า แต่ความแตกต่างความเร็วที่วัดได้ในเกณฑ์มาตรฐานเหล่านี้มีผลกระทบสำคัญต่อประสิทธิภาพโดยรวมของแอปของคุณ

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

ฉันคิดว่านี่เป็นสิ่งที่เข้าใจผิดมาก คุณสามารถเรียกใช้ Rails ในโหมดมัลติเธรด เมื่อทำงานในโหมดมัลติเธรดคุณควรใช้ไลบรารี IO ที่ปล่อย GIL (ตัวอย่างเช่นอัญมณี 'mysql2') มิฉะนั้นจะกลายเป็นไร้จุดหมาย

หากคุณกำลังใช้ jRuby คุณสามารถเรียกใช้กระบวนการรางเดี่ยวในโหมดมัลติเธรดและใช้พลังงาน CPU ที่มีอยู่ทั้งหมด อย่างไรก็ตามหากคุณใช้ MRI (Ruby 1.8.x หรือ 1.9.x) คุณต้องรันหลายกระบวนการเพื่อใช้งาน CPU อย่างเต็มที่ซึ่งเป็นกรณีที่มี node.js เช่นกัน

• Rails มีจำนวนมากที่ซ่อนความซับซ้อนจากคุณ (การเชื่อมโยง ActiveRecord การตรวจสอบทั้งหมด / ระยะเวลาการบันทึกการแปลความหมายของข้อมูลคำขอตามส่วนหัวที่ให้ไว้) เมื่อคุณเพิ่งเริ่มต้นสิ่งนี้ยอดเยี่ยมมาก ในขณะที่คุณเติบโตคุณจะพบว่าคุณเริ่มปรับแอพของคุณให้เหมาะกับ "ทางรถไฟ" ในการจัดการสิ่งต่าง ๆ - บางครั้งมันก็ดีบางครั้งมันไม่เป็นอันตรายและบางครั้งมันก็ต่อต้านสิ่งที่คุณพยายามทำ ไม่ใช่ตารางฐานข้อมูลทั้งหมดที่ควรเป็นแบบจำลองเป็นวัตถุขั้นตอนการตรวจสอบอาจต้องเกิดขึ้นที่อื่นเป็นต้นโปรแกรมเมอร์ Rails จำนวนมากหลีกเลี่ยงการต่อสู้กับเฟรมเวิร์ก (ซึ่งมักฉลาด) แต่ผลกระทบระยะยาวคือ ... คุณ จะนำพานิสัยของ Rails ไปกับคุณในสถานที่ที่ไม่จำเป็นต้องเรียกหา

• ชุมชนมีนิสัยในการเขียนซอฟต์แวร์ที่ถูกเรียกว่า "วิเศษ" - การแคช libs ที่ใช้งานได้อย่างน่าอัศจรรย์! เหตุการณ์ I / O ที่ทำให้คุณเร็วขึ้นอย่างน่าอัศจรรย์! เวทมนตร์เวทย์มนตร์! สิ่งที่มักจะเกิดขึ้นในกรณีนี้คือ API ที่น่าดึงดูดใจมีไว้สำหรับโซลูชันทางเทคนิคที่ขาดหายไปและคุณจะถูกหลอกโดยตัวอย่างที่สวยงามมากว่าสิ่งนั้นทำในสิ่งที่คุณตั้งใจและต่อมาพบว่ามันครอบคลุมโซลูชันที่ไม่สมบูรณ์ วัฏจักรของเรื่องนี้ค่อนข้างคงที่และคุณเรียนรู้ที่จะม้วนมัน แต่คุณควรทำความคุ้นเคยกับแนวคิดในการอ่านล็อตและรหัสมากมายที่คุณต้องพึ่งพา (เป็นสิ่งที่ดี!) โซลูชันเวทย์ชุมชนของ Rails นั้นไม่ได้วิเศษอย่างที่ README อาจแนะนำ

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

• ลัทธิขนส่งสินค้าเป็นปัญหาที่มีราง แต่อาจเป็นจริงกับชุมชนกรอบ / lang ทั้งหมด ดูเหมือนจะเด่นชัดกว่า (สำหรับฉัน) ใน Rails และมีแนวโน้มที่จะให้รหัส generational ดูแปลก ๆ เมื่อคุณทำงานในโครงการ Rails ที่แตกต่างกันคุณจะสังเกตเห็นแนวโน้มบางอย่างที่มีแนวโน้มที่จะทรยศต่อช่วงเวลาที่พวกเขาถูกสร้างขึ้น . ในขณะที่คุณสามารถเดาได้จากคำแถลงดังกล่าวชุมชนมีแนวโน้มที่จะดำเนินไปอย่างรวดเร็วในการนำโซลูชันใหม่มาใช้และเลิกใช้วิธีเก่า คุณควรอยู่ด้านบนของข่าว Ruby ของคุณเพียงเพื่อทำความเข้าใจโค้ดบางส่วนที่คุณจะได้รับในแต่ละวัน

• โดยทั่วไปฉันคิดว่าปัญหาการเกิดขึ้นพร้อมกันของข้อมูลมักจะไม่ได้รับการตอบรับที่ดีจากชุมชน - เมื่อคุณสร้างแอพขึ้นมาเมื่อคุณถึงจุดที่คุณจำเป็นต้องใช้ข้อมูล, การย้อนการเปลี่ยนแปลงทางกายภาพระยะไกลและล็อคการเข้าถึงข้อมูล การปรับจูนด้วยมือเพิ่มขึ้นเล็กน้อยซึ่งทำให้ Rails ดูดีสิ่งที่คุณได้รับทั้งหมด muddied up w / ความจำเป็นทางเทคนิคของความแม่นยำ Rails ไม่ได้แก้ปัญหาทุกปัญหาที่คุณมีกับเว็บแอปฉันเดาว่าฉันกำลังพูดอยู่และในขณะที่ผู้สร้างไม่ได้เทศนาข้อความนั้นมันง่ายที่จะถูกหลอกให้คิดว่ามันส่อให้เห็น

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

หากคุณกำลังพัฒนาอย่างแข็งขันคุณจะมีนิ้วอยู่กับสิ่งนี้