Bạn sẽ xem xét các công cụ quy trình thực hành tốt nhất để phát triển ứng dụng web (PHP) là gì? [đóng cửa]

Tôi thực sự hy vọng ai đó có nhiều kinh nghiệm hơn có thể chỉnh sửa câu hỏi theo ví dụ về câu trả lời của tôi:

• sử dụng kiểm soát phiên bản
• hướng phát triển thử nghiệm
• mã gỡ lỗi (xdebug cho php)
• sử dụng sơ đồ UML
• sử dụng OOP cho mã duy trì, có thể tái sử dụng
• sử dụng các khung (như Zend Framework cho php) để phát triển ứng dụng nhanh chóng

Bất cứ điều gì khác hoặc một công phu của những gì tôi đã đề cập ở trên?

Về cơ bản, tôi đang ở giữa một nhóm các nhà phát triển (bản thân tôi là một nhà phát triển) và tôi muốn có một lời khuyên về cách các lập trình viên / nhà thiết kế chuyên nghiệp, v.v. nên làm việc cùng nhau và họ nên sử dụng các tiêu chuẩn / mô hình nào.

Ngoài ra, nếu bất cứ ai có bất kỳ cuốn sách hoặc liên kết về chủ đề này, tôi hoan nghênh điều đó!

Tôi đã tìm thấy cái này mà tôi đoán thỏa mãn những gì tôi đang tìm kiếm, hoặc ít nhất là một phần của nó:

http://www.ibm.com/developerworks/websphere/l Library / Techarticles / 0306_perks / perks2.html

sử dụng kiểm soát phiên bản

SVN là rất phổ biến, nhưng mercurial đẹp trai hơn, mạnh mẽ hơn và có hỗ trợ gui vững chắc.

hướng phát triển thử nghiệm

tốt, nếu bạn làm bài kiểm tra đơn vị, bạn đã ở bên chiến thắng. đối với các công cụ, đó là một vấn đề lựa chọn. việc kiểm tra phải dễ dàng nhất có thể, đó là lý do tại sao tôi bỏ PHPUnit cho SimpleTest.

mã gỡ lỗi

với các bài kiểm tra đơn vị, bạn sẽ khó cần xdebug. tôi thường sử dụng xdebug để chỉ hồ sơ. (kiểm tra KCachegrind btw)

sử dụng sơ đồ UML

vấn đề lớn nhất với mọi thứ phản ánh logic mã là nó có rất nhiều công việc thủ công để giữ đồng bộ. bạn có thể tự động hóa một số tác vụ, nhưng nó không hữu ích, vì bạn thường muốn sử dụng uml trước khi bạn có bất cứ điều gì. vấn đề khác là các công cụ sơ đồ khó sử dụng hơn nhiều so với bút và giấy hoặc bảng trắng. sử dụng uml nếu bạn phải giao tiếp một vấn đề với nhiều nhà phát triển hoặc nếu bạn cần một sự trừu tượng cho chính mình. ("dia" là một công cụ miễn phí tốt. Ngoài ra, các công cụ bản đồ tư duy rất tiện dụng cho việc động não, một số thực sự có thể cạnh tranh bằng bút và giấy.)

sử dụng OOP cho mã duy trì, có thể tái sử dụng

tốt, oop làm việc ở một mức độ nào đó. :) một lời khuyên tốt: thành phần> thừa kế. kế thừa là một công cụ mạnh mẽ để tái sử dụng ngay từ cái nhìn đầu tiên, nhưng bảo trì và khớp nối lỏng lẻo sẽ phải chịu đựng nó. Lời khuyên tốt thứ hai: bảo trì> tái sử dụng. một hệ thống trừu tượng có thể rất mạnh mẽ, nhưng cũng khó bảo trì.

sử dụng các khung (như Zend Framework cho php) để phát triển ứng dụng nhanh chóng

RAD là một điều tốt để đưa ứng dụng của bạn ra sớm. nhưng một số thành phần - đặc biệt là ORM - sẽ bắn vào chân bạn, ít nhất là nếu nói đến khả năng mở rộng. vấn đề chính ở đây là bạn buộc logic miền của mình hoạt động với các đối tượng, điều này trở nên rất khó để xác định nếu bạn cần một giải pháp tối ưu hóa cơ sở dữ liệu có thể mở rộng thuần túy. lưu ý điều đó và khuyến khích các nhà phát triển của bạn sử dụng cơ sở dữ liệu mà không cần các lớp trừu tượng cao. trừu tượng hóa cơ sở dữ liệu là một huyền thoại, orm là một lời nói dối.

HÔN

những người mới đến thường muốn áp dụng tất cả những thực tiễn tốt nhất xung quanh, thiết lập các tiêu chuẩn mã hóa, sử dụng tất cả các chuỗi công cụ đẹp, bất cứ điều gì. nó hoạt động cho một số nhà phát triển, nhưng một số sẽ gặp phải sự phong tỏa về mặt tinh thần nếu mọi thứ quá nghiêm ngặt. thử nghiệm đơn vị và scm thực sự là phải có, nhưng ai đó mới thử nghiệm đơn vị thực sự cần phải tìm hiểu giá trị của nó trước khi anh ta yêu thích nó. đừng lạm dụng, hãy áp dụng các thực hành từng bước một và xem nó hoạt động ra sao. KISS cũng sôi sục để mã. đôi khi cách tốt nhất để giải quyết một vấn đề khó khăn là giải quyết nó sai. bạn cần một khoảng cách sáu độ thuật toán ? chỉ cần chọn một số bạn bè ngẫu nhiên. bạn có thể tạo một ứng dụng hoàn chỉnh xung quanh nó, với logic sai. Nếu cuối cùng khách hàng quyết định bỏ nó, mọi người đều tiết kiệm được rất nhiều tiền.

nhanh nhẹn

tìm hiểu về các phương pháp nhanh, lập trình cực đoan, scrum, v.v ... có rất nhiều sách ngoài kia. bất kỳ cuốn sách nào cũng sẽ làm cho nhóm của bạn tốt hơn, nhưng đó là cách tốt nhất để đưa mọi đồng đội vào đó.

• Kiểm soát phiên bản: Nếu trên windows, TortoiseSVN là ứng dụng tốt nhất, trực quan nhất và dễ sử dụng nhất theo kinh nghiệm của tôi.

• Khung: CodeIgniter . Thực hiện trên nền tảng phát triển web tốt nhất cho PHP.

• IDE: Netbeans là IDE tốt nhất cho PHP mà tôi đã sử dụng trên windows.

• Kiểm tra đơn vị: Có một số tùy chọn, một tìm kiếm google sẽ xuất hiện nhiều. CodeIgniter cũng có sẵn trình kiểm tra đơn vị riêng.

• Trình gỡ lỗi: Xdebug.

• Thư viện Javascript: Jquery

• Chương trình FTP: FileZilla

• Quản trị cơ sở dữ liệu: PhpMyAdmin

• Wireframing: Balsimus Mockup, hoặc sử dụng bảng trắng.

• Misc: Sử dụng WAMP nếu trên windows để dễ dàng cài đặt, khởi động, dừng và khởi động lại apache, mysql và php tất cả trong một gói.

Ngoài ra, nếu bạn sẽ làm việc trên nhiều trang web khác nhau và hầu hết các trang web đó sẽ có một số chức năng phổ biến như đăng ký, đăng nhập / đăng xuất, phần quản trị để tìm kiếm người dùng, v.v., tôi khuyên bạn nên xây dựng một dự án nhỏ trong bất kỳ khung nào bạn chọn và sử dụng dự án đó làm cơ sở cho mọi dự án mới mà bạn bắt đầu. Thông thường tôi gọi dự án này là 'bộ xương'. Nếu tôi bắt đầu làm việc trên xyz.com, tôi sẽ sao chép thư mục skeleton và đổi tên thành 'xyz.com', điền vào một số tệp cấu hình và tôi có một bản sao của xyz.com với một số tính năng đã làm việc rồi.

Tôi đồng ý chủ yếu với bài đăng của Click Upvote, tuy nhiên nếu bạn đang làm việc trên một trang web tương đối lớn, tôi chắc chắn sẽ khuyên bạn nên sử dụng khung Symfony kết hợp với ORM của Doctrine.

Nếu dự án của bạn đáo hạn vào năm tới, tôi sẽ nói hãy dành thời gian đầu tư vào Symfony2 và Doctrine2.

Ngoài ra, tôi không thể nhấn mạnh đủ tầm quan trọng của việc phát triển trên hệ thống dựa trên unix, Ubuntu là sở thích của tôi và là một máy chủ web tuyệt vời. Tôi làm việc chủ yếu trên windows nhưng phát triển trên Ubuntu chạy trong máy ảo VMWare trên máy tính để bàn của tôi (hoặc máy chủ khi tôi đang làm việc).

Đối với IDE, tôi thực sự khuyên bạn nên sử dụng NuSphere PHPEd hoặc Storm PHP, thật đáng buồn giống như tất cả những điều tuyệt vời mà chúng không miễn phí.

Sử dụng sơ đồ UML là tốt nhưng hoàn toàn tùy chọn. Bất kỳ sơ đồ sẽ làm miễn là nhóm của bạn hiểu ý nghĩa của chúng. Cố gắng sử dụng tiêu chuẩn không ai thực sự biết rõ có thể dẫn đến các vấn đề và mất thời gian.

Tôi khuyên bạn nên bắt đầu mỗi trang từ một mockup ( http://balsamiq.com ) hoặc nhờ nhà thiết kế của bạn vẽ nó cho bạn. Đừng hy vọng các nhà phát triển sẽ giỏi về thẩm mỹ thị giác và tạo ra những trang tốt từ hư không.

Có ai đó được giao nhiệm vụ đánh giá mã, nếu bạn có một vài thành viên trong nhóm seniour - làm cho họ thực hiện đánh giá luân phiên ( Hội đồng Đánh giá )

Khi giải quyết công việc hợp tác bạn cần:

• sử dụng kiểm soát phiên bản: tôi nghĩ rằng Git hoặc Subversion sẽ hoạt động khá trơn tru

• phát triển theo hướng kiểm tra: Tôi bắt đầu tìm hiểu điều này là bắt buộc, nhưng đừng đưa nó đến mức cực đoan

• mã gỡ lỗi (xdebug cho php): xdebug là lựa chọn của tôi

• sử dụng sơ đồ UML: Điều này giúp ích khi mọi người đều có kiến ​​thức làm việc về Lập trình OO và DesignPotype, tuy nhiên, đây luôn là một cách thực hành tốt

• sử dụng OOP cho mã có thể bảo trì, có thể tái sử dụng: Và LINH HOẠT, tôi nghĩ đây là khía cạnh quan trọng của OOP.

• sử dụng các khung (như Zend Framework cho php) để phát triển ứng dụng nhanh chóng: Lời khuyên của tôi là SYMFONY, khung php đầu tiên (không phải là bộ công cụ). Nó có một cộng đồng rất lớn, rất nhiều tài liệu và hoàn toàn được thực hiện trên php. Tôi đã làm việc với nó được một năm và nó hoàn toàn gắn bó với OOP

• bạn cũng có thể cần một hệ thống để theo dõi lỗi, yêu cầu tính năng, v.v. như: Thần chú hoặc Theo dõi . Sistems này khá dễ dàng và đơn giản. Họ cũng cho phép bạn ràng buộc lật đổ của bạn và liên quan đến cam kết của bạn với các tính năng nhất định hoặc lỗi mà mọi người đăng.

Cuối cùng, điều quan trọng là nếu bạn sẽ dẫn dắt một nhóm phát triển tổ chức một cuộc họp nhỏ định kỳ để mọi người biết tình trạng của hệ thống tại một thời điểm nhất định và có thể theo cách đó bạn sẽ có khả năng lập kế hoạch hoặc xem mọi thứ đang hoạt động như thế nào.

Trong công ty của tôi, tôi phải gửi email mỗi ngày để nói về những gì tôi đã làm việc và nếu có bất kỳ biến chứng nào.

May mắn nhất!

• Framework : codeigniter, không có nghi ngờ. Nó có tất cả các chức năng bạn đã bao giờ có thể cần, và không buộc bạn phải sử dụng bất kỳ trong số họ, trừ khi bạn làm cần họ;
• Kiểm soát phiên bản, IDE : Tôi khá già đi học và tôi không nghĩ câu trả lời của tôi thực sự có thể giúp bạn;
• Wireframing, UML : trường học cũ cũng vậy, nhưng thực sự: bảng trắng giành chiến thắng. Chúng linh hoạt, có thể mở rộng và hỗ trợ bất kỳ quy ước nào bạn có thể thấy phù hợp;
• Quản trị cơ sở dữ liệu : phpmyadmin;
• Hệ điều hành máy chủ phát triển : Tôi có thể bị cấm, nhưng: Ubuntu. Cài đặt máy chủ LAMP trong vài giây; đừng hoảng sợ về việc thêm các thư viện mới (hình ảnh đáng sợ: một lệnh, đã hoàn thành); nếu bạn thích PHP, có lẽ bạn sẽ làm việc trên máy chủ linux trong sản xuất để tốt hơn là bắt đầu thực hành. (Tuyên bố miễn trừ trách nhiệm: Ubuntu không phải là bản phân phối yêu thích của tôi).
• Misc : grep có thể cực kỳ hữu ích khi gỡ lỗi mã của người khác (bạn muốn biết có bao nhiêu bộ điều khiển sử dụng một mô hình nhất định không? Xong!).

biên tập

Tôi quên điều quan trọng nhất: thông số kỹ thuật. Viết thông số kỹ thuật thực sự cho dự án của bạn trước khi chạm vào bất kỳ mã nào. Có tất cả các sơ đồ tương tác người dùng trong tâm trí. Nó sẽ giúp bạn tiết kiệm hàng thế kỷ.

Kiểm soát phiên bản Vì bạn đang làm việc trong một nhóm, điều quan tâm nhất là bạn đi với thứ gì đó được phân phối. Ứng cử viên của bạn là Git và Mercurial. Điều này có nghĩa là nhóm của bạn có thể cam kết cục bộ mà không phá vỡ dự án, nhưng vẫn theo dõi công việc của họ, sau đó đẩy các cam kết này đến máy chủ trung tâm. Nó cũng nhanh hơn nhiều và có ít xung đột hợp nhất hơn do mã được theo dõi dưới dạng các tập thay đổi thay vì sửa đổi. Đọc mặc dù hướng dẫn hginit (được viết bởi người đồng sáng lập stack overflow) và bạn sẽ hiểu thêm một chút về DVCS là gì. http://hginit.com/

Bạn cũng nên sử dụng kho lưu trữ để triển khai thay vì rsync hoặc ftp.

Kiểm tra hướng phát triển Tùy thuộc vào những gì bạn đang làm thử nghiệm có thể lãng phí rất nhiều thời gian. Tôi không nói rằng bạn nên hoàn toàn bỏ qua nó, đối với các dự án nhỏ hơn đó là chi phí chung. Nếu bạn đang viết một thư viện hoặc dự án dài hạn lớn, hãy chắc chắn viết các bài kiểm tra cho nó. Các xét nghiệm sẽ giúp trong giai đoạn bảo trì. Xin lưu ý rằng TDD không thể tìm thấy tất cả các lỗi của bạn. Sẽ có vấn đề về trải nghiệm người dùng, vấn đề bố trí, vấn đề hiệu suất và như vậy.

Gỡ lỗi Xdebug về cơ bản là sự lựa chọn duy nhất của bạn ở đây. Nó tích hợp tốt với Netbeans. Nếu bạn cảm thấy cần phải in các biến ra, bạn nên sử dụng tệp nhật ký. Sử dụng chức năng ghi nhật ký khung, điều này an toàn hơn nhiều trong sản xuất.

Lập kế hoạch / Sơ đồ Nếu bạn đang sử dụng một khung công tác tốt, bạn không cần phải tạo sơ đồ chi tiết quá nhiều. Giữ cho nó đơn giản và làm việc trong các chu kỳ phát hành ngắn hơn, thật dễ dàng để lên kế hoạch. Các yêu cầu và thông số kỹ thuật của một dự án chắc chắn sẽ thay đổi, vì vậy tôi sẽ không dành toàn bộ thời gian của bạn cho chúng. Hãy nhớ rằng mã đặc tả IS ở mức chi tiết nhất.

Sử dụng công cụ theo dõi lỗi của bạn (xem bên dưới) để chia đặc tả thành các nhiệm vụ mà bạn có thể chỉ định cho các thành viên trong nhóm. Sử dụng một công cụ trung tâm để ghi lại các dự án, trình theo dõi lỗi có thể sẽ có wiki.

Bạn có thể sử dụng một công cụ như Mysql Workbench để thiết kế các lược đồ cơ sở dữ liệu trong sơ đồ và xuất chúng dưới dạng SQL.

Khung và OOP Đây có lẽ là phần quan trọng nhất. Tìm cho mình một khung phổ biến sẽ hỗ trợ phát triển nhanh và tái sử dụng mã. Một số người sẽ không thích tôi nói điều này, nhưng một khuôn khổ sẽ quyết định cách bạn làm việc. Nó nên cung cấp cấu trúc để một nhà phát triển có thể chuyển đổi dự án và biết chính xác vị trí của bộ điều khiển cho một trang nhất định, chính xác các biến mẫu là gì và cách truy vấn mô hình. Một số khung cho phép quá linh hoạt ở đây và bạn sẽ thấy rằng các nhà phát triển không luôn sử dụng khung theo cùng một cách. Tôi thích triết lý trăn; nên có một cách rõ ràng để làm mọi thứ. Đây là lý do tại sao tôi thích django và rails, họ khá quan tâm và điều này có nghĩa là tôi có thể nhìn vào mã của ai đó và hiểu những gì nó làm. Symfony có vẻ là lựa chọn tốt nhất ở đây,

Có rất nhiều câu hỏi 'khung công tác' nào về lỗi tràn stack như thế này: /programming/2648/what-php-framework-would-you-choose-for-a-new-application-and-why

Theo dõi lỗi Nhận nhóm của bạn một trình theo dõi lỗi tốt được tạo cho các nhà phát triển. Đừng sử dụng một cái gì đó đơn giản hóa như basecamp. Redmine và Unfuddle là hai ví dụ về trình theo dõi lỗi tuyệt vời, chúng cũng có thể theo dõi thời gian và tích hợp với kho lưu trữ của bạn. Nhóm của bạn nên sử dụng công cụ này để liên lạc về các vấn đề thay vì email hoặc IM. Nó giúp nhà phát triển mới dễ dàng hơn khi có sẵn lịch sử lỗi và tài liệu. Bài viết này giải thích chính xác những gì bất kỳ trình theo dõi lỗi tốt cần phải làm và tại sao. http://www.joelonsoftware.com/articles/fog0000000029.html

Tôi khuyên bạn nên xem Bazaar để kiểm soát phiên bản. So với Git, nó có ưu điểm chính là nó thực sự dễ sử dụng và cài đặt trên Windows, Mac OS và Linux. Ngoài ra, các lệnh bzr rất giống với các đối tác svn của nó, do đó ai đó đã từng làm việc với Subversion trước đây có thể dễ dàng sử dụng Bazaar mà không cần phải học nhiều. Tôi đang nhìn bạn Git.

Ngoài ra, tôi là một người tin tưởng mạnh mẽ vào việc không ép buộc bất cứ điều gì đối với các nhà phát triển của bạn. Con ong nói rằng hãy để họ sử dụng IDE, hệ điều hành và cứ thế mà họ thích.

Ngoài ra, tôi thực sự khuyên bạn nên thực hiện các bài kiểm tra wirte cho tất cả mã của mình, bất kể điều đó có tẻ nhạt đến mức nào.

Quyết định cho hoặc chống lại một khung imho không phải là điều bạn có thể làm dựa trên các khuyến nghị được đưa ra ở đây. Tôi đề nghị bạn liệt kê những ứng dụng có vẻ hứa hẹn với bạn dựa trên các tính năng của chúng và sau đó viết một ứng dụng thử nghiệm nhỏ trong mỗi ứng dụng. (Viết cùng một lần mỗi lần.)