Theo con đường của những gì tôi biết, sau đó cố gắng thực hiện các thực hành mã hóa chính xác, hoặc bắt đầu với các thực tiễn mã hóa tốt và cố gắng vượt qua?

Trước hết, tôi muốn nói rằng tôi đã quen làm Lập trình thủ tục như sở thích của mình - Tôi đang cố gắng học OOP bằng một vài ngôn ngữ và hiểu lý thuyết , không phải là thực hành.

Tôi có một dự án thú cưng mà tôi muốn xây dựng, cụ thể là trong PHP với phần phụ trợ cơ sở dữ liệu (không quan tâm cái nào). Lý do chính của tôi là để ứng dụng được sử dụng trên mọi thiết bị, vì vậy một ứng dụng Web có vẻ như là sự lựa chọn hợp lý.

Tôi hiểu rằng để xây dựng các WebApps PHP có thể bảo trì, nó nên sử dụng OOP, Classes, Frameworks, Library, v.v ... Điều này nghe có vẻ hợp lý, vì vậy tôi quyết định thử một vài trong số những cái phổ biến. Tuy nhiên, sau toàn bộ cuối tuần chỉ thử chúng và cố gắng vượt qua các hướng dẫn, tôi vừa bối rối vừa thất vọng khi cố gắng điều chỉnh các hướng dẫn cho dự án nhỏ của mình.

Tôi đã quyết định, chủ yếu cho một bằng chứng về khái niệm, để xây dựng ứng dụng trong một chương trình khác (Microsoft Access) và hoàn thành các mục tiêu chính của tôi chỉ trong vài giờ - ngoại trừ phần Web.

Câu hỏi của tôi là, tôi có nên đi theo con đường của những gì tôi biết, sau đó thử thực hiện các thực hành mã hóa chính xác hay tôi nên bắt đầu với các thực tiễn mã hóa tốt và cố gắng vượt qua? Đối với dự án này, tôi muốn nó được mở Sourced trên GitHub, vì vậy tôi sẽ mở cho những người khác sử dụng và thay đổi mã của mình, nhưng tôi cũng biết rằng nếu mã được viết kém, sẽ khó thu thập được các lập trình viên để giúp đỡ.

Thực tiễn tốt nhất chủ yếu là các đề xuất và đề xuất được thu thập từ kinh nghiệm để giúp làm cho các dự án dễ dàng hơn * có thể.

Các khía cạnh quan trọng của IMHO này là phần kinh nghiệm. Mặc dù những thực tiễn tốt nhất này là cách tốt để những người có nhiều kinh nghiệm chia sẻ nó với người mới bắt đầu, tôi nghĩ người ta vẫn cần một mức độ kinh nghiệm tối thiểu để thực sự hiểu điều gì làm cho đây là một thực tiễn tốt nhất. Làm khác đi theo họ một cách mù quáng như là quy tắc của pháp luật mà cuối cùng tôi nghĩ sẽ làm chậm việc học của bạn khi bạn từ từ để người khác làm suy nghĩ cho bạn.

Trong mọi trường hợp, điều tối quan trọng nhất đối với tôi trong một dự án phần mềm đối với tôi là ... ờ ... hoàn thành nó, vận chuyển nó ... trong ngắn hạn làm cho nó hoạt động!

Bất cứ điều gì trước thời điểm đó là phần mềm, một điều tưởng tượng của bạn. Chỉ khi bạn có thứ gì đó hiệu quả, bạn mới có thể thực sự đánh giá nếu nó chậm, khó bảo trì, khó kiểm tra, v.v. Quá trình làm cho nó hoạt động sẽ phơi bày những thứ mà có lẽ, có một thực tiễn tốt nhất sẽ giúp bạn suy nghĩ lại theo cách làm cho nó dễ dàng đạt được mục tiêu đó.

Vì vậy, có, bắt đầu với những gì bạn biết đầu tiên, lưu ý những điều bạn làm là khó khăn. Khi bạn va vào một bức tường hãy lùi lại một bước và nhìn vào bức tường đó, tìm hiểu nó được làm từ gì. Trong rất nhiều trường hợp, bạn sẽ nhận ra rằng BẠN là gốc rễ của vấn đề. Sự thiếu hiểu biết của bạn về một số vấn đề bạn đang cố gắng giải quyết, sự thiếu hiểu biết của bạn về cách bạn có thể tận dụng tốt hơn các công cụ bạn có hoặc sự thiếu hiểu biết của bạn về các công cụ khác ngay trong mũi bạn nhưng không sẵn sàng bắt đầu làm chủ của họ.

Đồng thời, tiếp tục đọc về những cách mới để làm việc. Đọc những thực tiễn tốt nhất này và thử xem chúng có áp dụng cho bất cứ điều gì bạn đang gặp khó khăn trong dự án của mình không. Nếu không, hãy nhớ sự tồn tại của chúng và thỉnh thoảng xem lại chúng. Hãy tò mò. Trong thời gian, bạn sẽ thấy rằng các quan sát được thực hiện ở trên chỉ cần nhấp một cách tự nhiên với kiến ​​thức bạn có được ở đây.

Thử nghiệm cuối cùng với những gì bạn đã học và xem liệu nó có làm mọi thứ đơn giản hơn không. giữ ở đây và cuối cùng bạn sẽ đọc thực hành tốt nhất cho những gì họ đang có. Chỉ cần lời khuyên đơn giản từ những người đã chịu đựng và học một cách để làm cho nó dễ dàng hơn. Heck bạn thậm chí có thể không đồng ý với một số trong số họ và thấy rằng cách của bạn thực sự làm việc tốt hơn cho bạn. Nhưng không có kiến ​​thức bạn chỉ là mù quáng đi bộ.

chúc may mắn

TL; DR

Bạn sẽ không bao giờ biết tất cả. Có khá nhiều luôn luôn có chiều sâu và chiều rộng hơn xung quanh mỗi "điều" cá nhân mà bạn có thể biết. Học khi bạn đi. Áp dụng "thực hành tốt nhất" mà bạn nghĩ là có liên quan ngay bây giờ. Phạm sai lầm. Chỉ cần cố gắng để tránh phạm sai lầm thực sự tốn kém . Tìm người cố vấn nếu dự án của bạn có thể dẫn đến những sai lầm tốn kém.

Và bây giờ câu trả lời dài ...

1. "Phần mềm làm việc là thước đo chính của sự tiến bộ." ( Tuyên ngôn nhanh nhẹn )

Nếu bạn có thể nhìn thấy các khía cạnh của kiến ​​thức của bạn, đó là tuyệt vời! Theo đuổi các cạnh! Hãy tiếp tục học hỏi! Nhưng hãy nhớ, bạn có thể học và phân tích mãi mãi .

Xây dựng một cái gì đó.

2. Học hỏi và mắc lỗi; nhưng đừng làm những cái "xấu". *

Tiếp tục đẩy ranh giới của kiến ​​thức / kỹ năng của bạn. Bạn sẽ phạm sai lầm. Bạn có thể học hỏi từ họ. Nhưng, bạn không cần phải liều lĩnh .

Thời gian bạn dành cho việc tìm kiếm và làm việc với các nhà phát triển và cố vấn có kinh nghiệm hơn sẽ tăng tỷ lệ thuận với giá trị kinh doanh và hồ sơ rủi ro của dự án.

Nếu bạn đang tạo một CLI nhỏ cho chính mình : Làm cho nó hoạt động theo cách bạn muốn.

Nếu bạn đang viết cổng thông tin web của ngân hàng: Bao quanh bạn với các nhà phát triển có nhiều kinh nghiệm.

3. "Thực hành tốt nhất" nên được viết bằng dấu ngoặc kép và nói bằng một cái nháy mắt.

"Thực tiễn" được quảng bá thành "thực tiễn tốt nhất" khi chúng được quan sát là thành công trong việc hoàn thành X trong ít nhất một số trường hợp. Ai đó nhận ra lợi ích của Thực hành A để đạt được Lợi ích X và tuyên bố rằng thực tiễn là "cách thực hành tốt nhất" trên internet. Những người khác đồng ý - thường vì lý do tốt. Nhưng, từ thời điểm đó, chúng ta thường đánh mất lý do tại sao một số thực tiễn là "thực tiễn tốt nhất" và một số khác là "phản hạt" hoặc "hôi thối".

Vấn đề là, một "thực hành tốt nhất" không bao giờ tự phục vụ. "Antipotypes" thực sự không phải là bệnh tiểu đường. Và, ngay cả một "mùi hôi thối" đôi khi chỉ đến từ thối rữa. Đôi khi, mùi hôi thối đó chỉ là một loại phô mai thơm ngon, lạ mắt ...

Bạn không thực hành những thứ như "tiêm phụ thuộc" (DI) vì "tiêm phụ thuộc" vốn có giá trị đối với doanh nghiệp. Nó thậm chí không cần thiết từ xa để xây dựng một sản phẩm làm việc. Nó hoàn thành một cái gì đó mà bạn có thể muốn trong sản phẩm cuối cùng của bạn. Nhưng, nó cũng có thể khiến công việc của bạn mất nhiều thời gian hơn mà không có lợi ích gì ...

Hừm ...

Vì vậy, bạn nên làm theo "thực hành tốt nhất?" Ngay cả khi bạn không hiểu họ? ... Ơ ... vâng. Ý tôi là không. Nhưng có. Nhưng, chỉ những cái thực sự áp dụng cho bạn và phần mềm của bạn và mục đích của nó.

Gọi POAP ! ^{(Vâng. Blog của tôi.)}

Nguyên tắc, mô hình và thực hành không phải là mục đích cuối cùng.

Do đó, ứng dụng tốt và phù hợp của mỗi người được truyền cảm hứng và hạn chế bởi một mục đích cao cấp hơn, cuối cùng. Bạn cần hiểu lý do tại sao bạn đang làm những gì bạn đang làm!

(POAP không được miễn trừ khỏi POAP.)

Vì vậy, bạn có thể không hoàn toàn hiểu mọi sắc thái của DI, ví dụ. Nhưng, nếu bạn hiểu ý định, bạn sẽ biết nếu bạn "nên" sử dụng DI, và bạn sẽ hiểu rõ hơn về DI.

Và, một khi bạn đã phát hành sản phẩm, bạn có thể suy nghĩ xem liệu DI (hoặc bất cứ điều gì) có thực sự có lợi hay không. Nếu vậy, nói rõ tại sao bằng văn bản. Nếu không, hãy nói rõ tại sao bằng văn bản ...

Thưởng đọc / Một số có liên quan:

Phân tích tê liệt là một điều. Bạn cần phân tích và học hỏi; nhưng, bạn cũng cần phải hoàn thành công việc Thăng bằng.

Bạn có thể luôn cảm thấy như một lập trình viên cao bồi .

^{* Bạn thực sự sẽ phạm sai lầm nếu bạn làm bất cứ điều gì đáng chú ý. Nhưng, tôi là con người, tôi giả sử. Vì vậy, chúng tôi tha thứ cho bạn trước thời hạn ... Hoặc, ít nhất là tôi làm. Có lẽ. ... Chà ... Chúng ta sẽ thấy.}

Câu hỏi của tôi là, tôi có nên đi theo con đường của những gì tôi biết, sau đó thử thực hiện các thực hành mã hóa chính xác hay tôi nên bắt đầu với các thực tiễn mã hóa tốt và cố gắng vượt qua?

Có thể cố gắng hết sức nhưng vẫn gửi một cái gì đó? Có hai lực khác nhau giữa cách người dùng đánh giá chất lượng và sự hấp dẫn của sản phẩm và cách các nhà phát triển đằng sau đánh giá chất lượng của mã. Hãy cố gắng làm cho hai lực lượng này hài hòa nhất có thể. Tập trung vào một cái quá nhiều với chi phí khác thường là cách bạn kết thúc với các tuyến đường phản tác dụng nhất.

Chà, trước hết, tôi sẽ đề nghị rằng việc áp dụng các thực hành mã hóa tốt không phải là sai lầm ... Bí quyết là hiểu mục đích của mỗi thực tiễn và cách thực hiện đúng.

Môi trường phát triển ứng dụng nhanh chóng rất quyến rũ, bởi vì bạn có thể hoàn thành rất nhiều việc trong một thời gian thực sự ngắn. Tôi đã xây dựng toàn bộ hệ thống kế toán trong Access một lần. Nhưng bạn đã tự nói điều đó: bạn không thể đưa một ứng dụng như thế lên web mà không cần viết lại và các công cụ bạn cần ở đó thực sự khác biệt.

Có nhiều lý do tại sao không ai sử dụng các công cụ thiết kế trực quan như Access hoặc Visual Basic nữa. Họ có xu hướng cách ly bạn khỏi mã thực sự hoàn thành một cái gì đó. Truy cập là một công cụ tốt, nhưng nó đòi hỏi điều mà các ứng dụng web được thiết kế đặc biệt để tránh: cài đặt. Tùy chỉnh sự xuất hiện của nó có thể khó khăn; ngay cả khi bạn không cần nó trên web, một ứng dụng Access sẽ luôn trông rất giống với bất kỳ ứng dụng Access nào khác. Hầu hết những người viết ứng dụng Access đầu tiên của họ không biết đủ để viết một ứng dụng tốt và Access giúp bạn dễ dàng viết một ứng dụng xấu.

Vì vậy, bây giờ bạn đã từ chức để học một công nghệ mới để có được ứng dụng của bạn trên web. Bạn có nên xây dựng nó đúng cách ngay từ đầu? Tất nhiên. Nhưng học một môi trường phát triển và triết lý mới cũng giống như học bất kỳ thứ gì khác; bạn phải dốc nó lên một lúc để có được mọi thứ đúng.

Đó là lý do tại sao tôi nghĩ rằng bạn đã đặt ra một sự phân đôi giả. Không ai học được tất cả các "thực hành tốt nhất" đầu tiên. Họ học chúng khi họ đi. Nhưng để làm việc hiệu quả trong bất kỳ ngôn ngữ OOP nào, tôi nghĩ bạn sẽ cần biết một số OOP hoặc ít nhất là cách các lớp học hoạt động cơ bản.

Đối với những gì nó có giá trị, tôi không nghĩ PHP là sự lựa chọn tốt nhất của bạn. PHP hấp dẫn bởi vì nó "nông cạn", nghĩa là bạn không cần phải biết nhiều để viết một chương trình làm việc. Các thực tiễn tốt nhất được dành phần lớn cho nhà phát triển, điều đó có nghĩa là PHP sẽ không giúp bạn viết các chương trình "tốt". Đây không phải là một điều xấu, nhưng điều đó có nghĩa là, giống như Access, cuối cùng bạn cũng có thể từ bỏ PHP để có một nền tảng mạnh mẽ hơn.

Hãy xem xét OOP như một mô hình khác mà bạn có thể áp dụng vào đúng thời điểm. OOP không phải là một khung có thể giải quyết một cách có phương pháp mọi nhiệm vụ. Một điều như vậy không tồn tại trong công nghệ phần mềm.

Cũng lưu ý rằng những gì mọi người tuyên bố là thực hành tốt đôi khi là nghi vấn. Tôi thường thấy các nhà phát triển thiếu kinh nghiệm áp dụng các mẫu lập trình rất phức tạp không cần thiết cho vấn đề đã cho. Độ phức tạp của mã phải phù hợp với độ phức tạp của vấn đề. Đơn giản là một giá trị quan trọng.

Các bài viết trên web, tuyên bố từ các chuyên gia trong ngành và lời khuyên từ các đồng nghiệp cao cấp cũng có thể sai. Tôi đã thấy điều này rất nhiều.

Do đó tôi khuyên bạn nên áp dụng giải pháp đơn giản nhất để giải quyết vấn đề của mình. Có khả năng, điều này sẽ bao gồm việc sử dụng một trong các khung phổ biến trong không gian của bạn. Trong giới hạn này, bạn có thể tự do chọn loại mã bạn thích. Không chỉ đơn giản nghĩ rằng họ cách làm việc đó có phù hợp với bạn như vậy.

Ngoài ra, hiểu tại sao một số kỹ thuật được khuyến khích. Ví dụ, OOP là về đóng gói. Bạn có thể gói gọn theo những cách khác (thủ tục cũng là về đóng gói).

Một ví dụ tiêu cực: Đôi khi mọi người viết một lớp truy cập dữ liệu để trừu tượng hóa cơ sở dữ liệu. Ở đây, bản chất của mẫu này là trở nên độc lập với kho dữ liệu cụ thể và để lộ một giao diện đơn giản hơn với các lớp mã cao hơn. Nhưng nếu bạn không cần những lợi ích này thì bạn không cần lớp truy cập dữ liệu và có thể lưu công việc. Tuy nhiên, nhiều chuyên gia khuyên bạn luôn luôn thực hiện một DAL là một khuyến nghị không chính xác.

Tôi thấy rằng mã tốt thường là thú vị để làm việc với. Thật thú vị vì bạn có thể làm việc theo yêu cầu thực tế thay vì quan tâm đến các mối quan tâm về cơ sở hạ tầng. Nếu bạn thấy rằng những gì bạn đang làm là quá nhiều công việc nặng nề thì có khả năng bạn đã chọn sai bộ mẫu.