Tôi không thể đếm tất cả các công cụ không mã mà tôi đã chơi với. Tôi cũng không thể đếm tất cả các ngôn ngữ và thư viện mà tôi đã từng làm việc.

Tuy nhiên, đây là những sai lầm điển hình nhất được thực hiện khi sử dụng không mã mà tôi nhận thấy, theo quan điểm tương đối nhỏ của tôi.

1) Hiểu biết không tốt về các mối quan hệ cơ sở dữ liệu, và nó sẽ ảnh hưởng như thế nào đến công việc kinh doanh.

Thông thường, các nhà sản xuất không nghĩ quá nhiều về cách dữ liệu của họ cùng tồn tại với nhau. Họ không biết điều này sẽ làm họ chậm lại bao nhiêu trong thời gian dài, quyết định tồi tệ sớm với không mã không ít tốn kém hơn với mã. Một số phải trả giá cho những sai lầm như vậy nhiều năm sau khi thực tế xảy ra.

💡 Không có mã tạo ra nợ kỹ thuật, giống như cách mã thực tế làm.

Một số công cụ, chẳng hạn như Airtable, không giúp thực hiện các cuộc gọi phù hợp. Đặc biệt, Airtable là một trong những cơ sở dữ liệu tồi tệ nhất mà tôi từng làm việc. Trong khi giao diện người dùng thật tuyệt vời, thì phần phụ trợ cũng kinh khủng không kém. Cảm giác như nó được xây dựng bởi một nhóm thực tập sinh say xỉn trong kỳ nghỉ hè . Những thứ đơn giản, như quan hệ, cho phép quan hệ nhiều-nhiều ngay cả khi bạn chỉ định bạn muốn quan hệ một-nhiều. Không có cơ sở dữ liệu nào khác làm điều đó, và vì những lý do rất chính đáng.

💡 Đây là vấn đề tôi thấy nhiều nhất và rất khó giải quyết , vì không có "cách đúng". Cách thức phù hợp phụ thuộc vào tình trạng kinh doanh tại thời điểm đó và cách nó có thể phát triển. Ngoài ra, nó hầu như sẽ luôn phát triển khác với những gì bạn nghĩ khi đó, khi doanh nghiệp trưởng thành.

Có một người có kinh nghiệm, người hiểu cách các mối quan hệ hoạt động với các công cụ không mã mà bạn sử dụng (rất khác với cách chúng thường hoạt động với mã!), Sẽ là người thay đổi cuộc chơi.

Các quyết định thiết kế cơ sở dữ liệu tồi không phải đợi nhiều năm nữa mới có lại được, đôi khi một vài tuần là đủ để bạn tự đối mặt với cảm giác “nếu tôi đã biết”.

2) Chọn đúng công cụ không mã, cho công việc sai

Điều này không khác gì việc các nhà phát triển chọn “xây dựng trình biên dịch nhanh nhất” bằng cách sử dụng Node thay vì Rust, bởi vì họ chỉ đơn giản là “quen thuộc nhất với Node”.

Các công cụ chỉ tuyệt vời để sử dụng khi được sử dụng cho mục đích mà chúng được tạo ra.

Ví dụ: sử dụng Airtable khi bạn cần hàng triệu bản ghi là một ý tưởng tồi tệ sẽ giết chết doanh nghiệp của bạn hoặc buộc bạn phải di chuyển khi bạn cần tập trung vào việc mở rộng quy mô.

Không phải vì điều gì đó có thể xảy ra mà đó là một ý kiến ​​hay.

💡 Khi tìm kiếm các công cụ không mã, hãy đảm bảo rằng bạn đã chuẩn bị sẵn danh sách “yêu cầu chức năng”, với sự suy nghĩ kỹ lưỡng về “cần có” và “tốt là có”. Điều này sẽ giúp bạn loại bỏ rất nhiều ứng viên sớm, do đó sẽ giúp bạn tiết kiệm rất nhiều thời gian.

Trò chuyện nhanh với chuyên gia, người hiểu rõ cơ sở của một công cụ không mã cụ thể có thể giúp bạn xác nhận / loại bỏ ứng viên rất nhanh chóng!

3) Không dành đủ thời gian để phân tích các công cụ không mã để tìm "SỰ phù hợp tốt"

Thông thường, các nhà xây dựng muốn xây dựng và xây dựng nhanh chóng. Tuy nhiên, như đã chỉ ra trước đây, bất cứ thứ gì bạn xây dựng sẽ chỉ tốt bằng bất kỳ công cụ không mã nào bạn chọn cho công việc. Tìm kiếm sự phù hợp tốt là rất quan trọng. Và, vì rất khó để hiểu tất cả các hạn chế của mọi công cụ hiện có và cân nhắc rằng những hạn chế đó có thể thay đổi bất cứ lúc nào, nên rất khó để chắc chắn 100% các công cụ bạn chọn sẽ thực hiện được công việc ngay bây giờ. , trong 6 tháng và trong 2 năm. Không ai có thể biết điều đó.

Về khía cạnh này, phần mềm nguồn mở (OSS) có thể đáng tin cậy hơn nhiều so với các công cụ do công ty sản xuất. Không phải nó không thể chết khi bạn cần mở rộng quy mô, nhưng ngay cả khi có, nó sẽ luôn cung cấp cho bạn cách tự lưu trữ mọi thứ trong khi chuyển đổi sang một nhà cung cấp mới. Các công cụ do công ty sản xuất có thể chết và chết cứng, khiến bạn không còn cách nào khác ngoài việc xây dựng lại mọi thứ cùng một lúc bằng cách sử dụng một ngăn xếp mới, điều này cực kỳ căng thẳng và thường cảm thấy không thể.

💡 Không được đánh giá thấp thời gian cần thiết để thực hiện một phân tích như vậy.

Lần cuối cùng tôi phải làm điều đó, tôi đã dành 3–4 tháng để POC xung quanh với nhiều công cụ khác nhau, phân tích khoảng 30, thử khoảng 12 và POCed khoảng 6 trong số đó, để cuối cùng đưa ra quyết định có ý thức về lý do tại sao chúng tôi chọn những công cụ đó.

Trớ trêu thay, đó là công cụ cuối cùng mà tôi thấy phù hợp nhất với công việc kinh doanh của chúng tôi, sau 3 tháng cố gắng và thất bại. Tôi rất vui vì tôi đã không từ bỏ nhiệm vụ này cho đến khi tôi tìm thấy những gì tôi đang tìm kiếm, nhưng chết tiệt đó là khó khăn về tinh thần.

4) Không sử dụng bất kỳ quy ước nào, hoặc những quy ước được lựa chọn kém

Quy ước xấu thậm chí còn có hại hơn là không có quy ước nào cả. Các quy ước có ý nghĩa về lâu dài và tiết kiệm rất nhiều thời gian, đồng thời tránh được những sai lầm của con người.

Ví dụ, Airtable có các quy ước tích hợp rất kém (thực tế là không có). Chúng hoàn toàn không giúp cài đặt bất kỳ quy ước nào và giao diện “thân thiện” của chúng cũng không giúp được gì. Mọi người nghĩ rằng họ đang viết văn bản thông thường khi đặt tên bảng và cột, và họ không nhận thức được tất cả các vấn đề mà điều này có thể gây ra. Tệ hơn nữa, Airtable khuyến khích điều này bằng cách coi tên cột là nhãn và không cho phép tạo ra sự khác biệt giữa “tên nội bộ” và “nhãn hiển thị”.

Chắc chắn, việc đặt tên cho cột của bạn companyNamehay nameOfCompanykhông sẽ không phải là vấn đề nhiều khi bắt đầu, cho đến khi người khác (hoặc chính bạn!) Thay đổi ý định và bắt đầu trộn lẫn cả hai quy ước đặt tên. Từ đó, bạn sẽ gặp khó khăn trong việc tìm kiếm các cột của mình, và bạn sẽ có nhiều khả năng mắc lỗi khi viết tự động hóa và những điều đó có thể có tác dụng phụ khủng khiếp.

💡 Trong công ty nhỏ của tôi, tôi không phải là người duy nhất sử dụng Airtable, nhưng tất cả các cột mới đều được tôi xem xét. Đồng đội của tôi có thể thêm nhiều cột hơn nếu họ muốn , nhưng chúng tôi thường đồng ý về việc đặt tên cho các trường mới trước đây, trong giai đoạn “thiết kế” của chúng tôi. Khi cần gấp, họ tự làm, nhưng yêu cầu tôi xem lại cách đặt tên.

Điều này nghe có vẻ ngớ ngẩn, nhưng nếu chúng tôi không dành thời gian đó cho việc này, chúng tôi sẽ không thể có cùng một quy ước đặt tên trên cơ sở dữ liệu 3 airtable và hơn 2000 cột của chúng tôi.

Tuy nhiên, tôi không nói rằng chúng tôi đã làm điều đó một cách hoàn hảo, nhưng chúng tôi đã giảm được nhiều khoản nợ kỹ thuật về mặt này bằng cách làm theo cách này!

5) Không ghi lại mọi thứ, hoặc không thể phát hiện ra nó

Tài liệu khó, rất khó viết, thậm chí còn khó làm cho nó đúng và thậm chí còn khó tạo hơn nếu có thể khám phá và thực sự hữu ích cho những người cần nó khi họ cần!

Không phải vì lý do gì mà tài liệu hướng dẫn quá tệ đối với các sản phẩm nội bộ, đặc biệt là những sản phẩm được viết bằng mã thực tế!

💡 Là một nhà tư vấn, tôi có thể cho bạn biết hầu hết các dự án nội bộ, cho dù chúng được xây dựng bởi các “chuyên gia” hay các thực tập sinh thiếu tài liệu tốt. Hầu hết thời gian, tài liệu đó thậm chí không bao gồm những điều cơ bản nhất như “dự án này dùng để làm gì? nó làm gì?".

Tài liệu về không mã không khác biệt và một lần nữa, các công cụ không mã không phải lúc nào cũng đặc biệt giúp làm cho mọi thứ trở nên đúng đắn.

Ngay cả khi tài liệu ở đó, được viết tốt và cập nhật, nó cũng vô ích nếu người cần nó không thể tìm thấy nó. Nó phải được khám phá.

💡 Điều này có thể gây ngạc nhiên cho nhiều người không phải là nhà phát triển, nhưng các dự án được ghi chép tốt nhất hiện có thường là các dự án mã nguồn mở!

Tại sao? Bởi vì sẽ chẳng ai coi thường một dự án nếu họ không hiểu nó để làm gì và sử dụng nó như thế nào! Đó là lý do tại sao OSS luôn có tài liệu tuyệt vời, bởi vì chúng hiếm khi nổi tiếng khi không có, cho dù phần mềm đó có tốt đến đâu!

Tìm ra cách phù hợp để ghi lại các dự án của bạn, một dự án phù hợp với mọi người, là một thách thức. Nó mất thời gian, thường cảm thấy vô ích và lãng phí thời gian, nhưng nếu không được thực hiện đúng cách, nó sẽ làm chậm quá trình mở rộng quy mô của bạn, không phải về mặt kỹ thuật mà là về mặt con người. Bạn sẽ không thể thu hút những người mới một cách hiệu quả nếu mọi thứ không được ghi chép đúng cách.

Ngoài ra, nó còn khó hơn khi sử dụng nhiều công cụ không mã, như Airtable, Zapier, Integromat, N8n và để toàn bộ công việc kinh doanh của bạn được tạo ra từ đó và điều đó. Nó làm cho mọi thứ thực sự khó hiểu và có một cái nhìn tổng quan là một thách thức khá lớn.

<aside> 💡 Chúng tôi ghi lại tất cả các công thức và tự động hóa của Airtable (Airtable, Zapier, Integromat) vào một kho lưu trữ GitHub chuyên dụng. Có vẻ như thật lãng phí thời gian để cập nhật liên tục, nhưng nó cũng giúp chúng tôi tiết kiệm được kha khá thời gian.

Ví dụ: khi xóa / đổi tên một cột trong Airtable, đó là cách duy nhất để dễ dàng và nhanh chóng biết các tự động hóa / công thức nào bị ảnh hưởng. Một "tìm kiếm trong dự án" đơn giản và chúng tôi có được toàn bộ tổng quan về mọi thành phần bị ảnh hưởng. Điều này mang lại cho tôi một tâm trí tuyệt vời để duy trì những thứ mà tôi chỉ có thể khuyên bạn làm như vậy, mặc dù tôi ước nó đơn giản hơn và tự động hơn.

Có rất nhiều “sai lầm điển hình” khác với không có mã, nhưng đây là top 5 của tôi. Đừng ngần ngại chia sẻ suy nghĩ và phản hồi của bạn!