Lebih Sedikit Fail, Lebih Banyak Baris lwn. Lebih Banyak Fail, Lebih Sedikit Baris Kod

Ah, perbahasan pembangun klasik: **"Lebih sedikit fail dengan lebih banyak baris" lwn. "Lebih banyak fail dengan lebih sedikit baris." Ia seperti memilih topping piza—semua orang mempunyai pilihan mereka dan tiada siapa yang pernah berpuas hati sepenuhnya.

Apabila mengatur kod untuk permintaan tarik (PR), sesetengah orang lebih suka kesederhanaan untuk menyimpan sesuatu di satu tempat, manakala yang lain memilih untuk memecahkannya menjadi fail yang lebih kecil dan terfokus.

Akhirnya, ini bukan hanya tentang anda—ia tentang menyelamatkan masa depan-anda dan pasukan anda daripada menguraikan pangkalan kod yang tidak kemas kemudian.

Mari kita mendalami senario praktikal. Bayangkan pembangun ditugaskan untuk memaparkan senarai widget pada halaman papan pemuka. Berikut ialah pelaksanaan awal:

// Dashboard.js
export default function Dashboard() {
 const widgets = getWidgets();

  // Handles widget deletion
  const handleDelete = (id) => {};

  // Handles widget title update
  const handleUpdate = (id, newTitle) => {};

  return (
    <div>
      <h1>Dashboard</h1>
      <div className="widget-container">
        {widgets.map((widget) => (
          <div className="widget">
                  <h2>{widget.title}</h2>
                  <p>{widget.description}</p>
                  <span onClick={handleDelete}>?️</span>
                  <span onClick={handleUpdate}>✎</span>
          </div>
        ))}
      </div>
    </div>
  );
}

Semasa semakan, seseorang mencadangkan untuk memisahkan logik untuk memaparkan widget individu ke dalam komponen mereka sendiri. Pembangun memfaktorkan semula kod seperti berikut:

// Dashboard.js
export default function Dashboard() {
  const widgets = getWidgets();

  // Handles widget deletion
  const handleDelete = (id) => {};

  // Handles widget title update
  const handleUpdate = (id, newTitle) => {};

  return (
    <div>
      <h1>Dashboard</h1>
      <div className="widget-container">
        {widgets.map((widget) => (
          <Widget
            key={widget.id}
            widget={widget}
            onDelete={handleDelete}
            onUpdate={handleUpdate}
          />
        ))}
      </div>
    </div>
  );
}

// Widget component for individual widget
function Widget({ widget, onDelete, onUpdate }) {
  return (
    <div className="widget">
      <h2>{widget.title}</h2>
      <p>{widget.description}</p>
      <button onClick={() => onDelete(widget.id)}>?️</button>
      <button onClick={() => onUpdate(widget.id, "New Title")}>✏️</button>
    </div>
  );
}

// Can be even further moved to a separate file
// Widget.js
export default function Widget({ widget, onDelete, onUpdate }) {
  return (
    <div className="widget">
      <h2>{widget.title}</h2>
      <p>{widget.description}</p>
      <button onClick={() => onDelete(widget.id)}>?️</button>
      <button onClick={() => onUpdate(widget.id, "New Title")}>✏️</button>
    </div>
  );
}

Bukankah pelaksanaan awal kelihatan lebih mudah dan lebih mudah, terutamanya apabila logik tambahan—seperti pengendalian analitik—berkait rapat dengan widget, yang membawa kepada peningkatan prop dan penukaran konteks? ? Ini menimbulkan persoalan penting: pendekatan manakah yang harus diambil oleh komponen Papan Pemuka? Sekiranya ia mengekalkan pelaksanaan sebaris, mengguna pakai struktur pemfaktoran semula, atau memilih pendekatan hibrid? ?

---

Bila Perlu Menyimpan Komponen dalam Fail Yang Sama

1. Projek Kecil atau Tanggungjawab Tunggal:
   • Jika komponen Papan Pemuka digandingkan rapat dengan komponen Widget dan projek anda kecil, mengekalkannya bersama mengurangkan kerumitan yang tidak perlu.
2. Kebolehgunaan semula tidak mungkin:
   • Apabila komponen Widget tidak akan digunakan semula di tempat lain, mengasingkannya memberikan sedikit faedah.
3. Kebolehbacaan:
   • Untuk komponen yang lebih kecil, satu fail memudahkan untuk memahami hubungan antara komponen tanpa penukaran konteks.
4. Mengelakkan Overhed:
   • Komponen sebaris menghapuskan penyata import/eksport tambahan, mengurangkan kod boilerplate dalam persediaan mudah.

---

Bila Menggunakan Fail Berasingan

1. Kebolehgunaan semula:
   • Jika komponen Widget mungkin digunakan di tempat lain, fail yang berasingan menjadikannya lebih mudah diakses dan diurus.
2. Kebolehbacaan Kod dan Organisasi:
   • Apabila fail semakin besar, memecahkannya kepada bahagian yang lebih kecil, logik meningkatkan navigasi dan mengurangkan beban kognitif, terutamanya dalam projek yang lebih besar.
3. Pengujian dan Penyelenggaraan:
   • Komponen terpencil dalam fail berasingan lebih mudah untuk diuji unit, membawa kepada liputan ujian dan kebolehselenggaraan yang lebih baik.
4. Pemisahan Kebimbangan:
   • Mengikut prinsip tanggungjawab tunggal, fail berasingan memastikan setiap komponen mempunyai tujuan yang jelas dan berbeza—penting untuk kebolehselenggaraan jangka panjang.
5. Skalabiliti:
   • Memecahkan komponen kepada fail berasingan memastikan pangkalan kod kekal terurus apabila projek berkembang, membolehkan penambahan ciri baharu yang lancar tanpa mengganggu fungsi sedia ada

---

Membuat Keputusan

Untuk contoh Papan Pemuka ini, pilihan anda bergantung pada skala projek dan peranan komponen yang dimaksudkan. Oleh kerana ini adalah contoh kecil di mana Widget tidak akan digunakan semula, satu fail berfungsi dengan baik:

// Dashboard.js
export default function Dashboard() {
 const widgets = getWidgets();

  // Handles widget deletion
  const handleDelete = (id) => {};

  // Handles widget title update
  const handleUpdate = (id, newTitle) => {};

  return (
    <div>
      <h1>Dashboard</h1>
      <div className="widget-container">
        {widgets.map((widget) => (
          <div className="widget">
                  <h2>{widget.title}</h2>
                  <p>{widget.description}</p>
                  <span onClick={handleDelete}>?️</span>
                  <span onClick={handleUpdate}>✎</span>
          </div>
        ))}
      </div>
    </div>
  );
}

Untuk projek yang lebih besar atau semakin berkembang, memisahkan Widget akan memberi manfaat dari segi fleksibiliti dan kebolehselenggaraan

Pengambilan Utama

Mengimbangi "lebih banyak baris dalam satu fail" berbanding "lebih banyak fail dengan lebih sedikit baris" bergantung pada skop projek anda, saiz pasukan dan trajektori pertumbuhan. Pertimbangkan perkara berikut semasa membuat keputusan:

• Adakah komponen mungkin akan digunakan semula?
• Seberapa komplekskah fail induk?
• Adakah projek mengikut konvensyen atau corak reka bentuk tertentu?
• Adakah skala pangkalan kod menjadi ketara dari semasa ke semasa?

Jika seseorang mencadangkan untuk memindahkan komponen ke fail berasingan semasa semakan PR, semak semula sama ada faedah sejajar dengan pertimbangan ini.

Atas ialah kandungan terperinci Lebih Sedikit Fail, Lebih Banyak Baris lwn. Lebih Banyak Fail, Lebih Sedikit Baris Kod. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!