2009-07-07 29 views
15

Xuất phát từ nền tảng CNTT, tôi đã tham gia vào các dự án phần mềm nhưng tôi không phải là lập trình viên. Một trong những thách thức lớn nhất của tôi là có rất nhiều kinh nghiệm về CNTT, mọi người thường quay sang tôi để quản lý các dự án bao gồm phát triển phần mềm. Các dự án thường được thuê ngoài và không có ngân sách cho một kiến ​​trúc sư toàn thời gian hoặc PM, khiến tôi ở vị trí để đánh giá công việc đang được thực hiện.CNTT đánh giá chất lượng mã hóa - làm thế nào để chúng ta biết điều gì là tốt?

Tôi đã xoay sở để vượt qua điều này trong quá khứ, tôi (với lý do chính đáng) không thoải mái về việc chấp nhận những trách nhiệm này.

Câu hỏi của tôi là, từ quan điểm về kinh nghiệm kỹ thuật nhưng không có trong lập trình, làm thế nào tôi có thể đánh giá liệu mã hóa được viết tốt hay không chỉ xác định xem nó có hoạt động hay không? Có phương pháp, thủ thuật, thủ đoạn thương mại, cờ, biển báo, bất cứ điều gì có thể nói - hey đây là rác hay hey đây là khá damn tốt?

+0

Cũng cho rằng tôi có thể sẽ không có cơ hội để ký hợp đồng với anh ta ... một số cách hay để đánh giá khác là gì? – Krevin

+1

Đây sẽ là một câu hỏi dễ dàng hơn nhiều nếu nhà nước của nghệ thuật sẽ ngồi yên trong một phút. – quillbreaker

Trả lời

1

làm thế nào tôi có thể đánh giá liệu mã hóa được viết tốt

Có nhiều cách/số liệu để xác định 'well'or 'tốt', ví dụ:

  • Delivered đúng thời hạn
  • Đã gửi nhanh
  • Không có lỗi nào sau khi giao hàng
  • Dễ cài đặt
  • Vâng ghi
  • Chạy nhanh chóng
  • Sử dụng phần cứng giá rẻ
  • Sử dụng phần mềm giá rẻ
  • Không tốn nhiều để viết
  • Dễ dàng quản lý
  • Dễ sử dụng
  • Dễ thay đổi (tức là thêm các tính năng mới)
  • Dễ cảng đến phần cứng mới
  • ... vv ...

Trong số này, các lập trình viên có xu hướng đánh giá "dễ thay đổi": bởi vì, của họ công việc là thay đổi phần mềm hiện có.

+0

Đó là tất cả những điểm tốt ... nhiều trong số đó tôi đã sử dụng vì tôi không có phương tiện đánh giá mã trực tiếp. Có cách nào tốt để đánh giá mã trực tiếp không? Hoặc thậm chí quan trọng hơn, nếu tôi đánh giá một nhà phát triển trong quá trình tuyển dụng, tôi nên tìm kiếm điều gì để xác định trình độ của họ? – Krevin

+0

Tại sao bạn đang cố gắng "đánh giá mã": bạn sẽ làm gì với đánh giá đó nếu bạn đã có nó? Bạn đang cố gắng nói "điều này là/không tốt"? Để nói những gì cần phải được cải thiện? Để quyết định có trả tiền cho những gì được nhận không? Để viết các thông số kỹ thuật cho phần mềm, phần mềm này sẽ được sử dụng làm đầu vào/yêu cầu của nhóm phát triển và từ đó họ sẽ phát triển phần mềm? Để lựa chọn giữa các đội thi đấu? Để đánh giá liệu một dự án có đúng tiến độ không? ...? – ChrisW

+0

@chris - cũng có cho hầu hết các câu hỏi đó. Nhưng chủ yếu cho mục đích thuê hoặc mục đích dự án. Tôi cần phải xác định xem ai đó có thẩm quyền để cung cấp cho họ một dự án, và sau đó tôi cần phải xác định xem họ đã thực hiện tốt dự án. Tôi có thể dễ dàng xác định xem nó có phải là thông số kỹ thuật ở cấp độ bề ngoài hay không, trong đó nó có ý nghĩa gì, nhưng câu hỏi đặt ra là xác định xem nó có được thiết kế tốt hay không. Tôi nghĩ bạn đã đạt được một điểm tuyệt vời trong việc định giá liệu nó có dễ thay đổi không ... nhưng bạn sẽ làm gì trước khi dự án bắt đầu? – Krevin

7

Câu hỏi hay. Nên nhận được một số phản ứng tốt.

  1. Mã sạch sẽ (thụt tốt, tổ chức tập tin, cấu trúc thư mục)
  2. Vâng nhận xét (không chỉ là ý kiến ​​nội tuyến, nhưng các biến mà nói những gì họ đang có, chức năng mà nói những gì họ làm, vv)
  3. chức năng dễ hiểu nhỏ/phương pháp (không điên 300 phương pháp dòng mà làm tất cả các loại vật với lồng nhau nếu logic ở khắp mọi nơi)
  4. Làm theo SOLID principles
  5. là số lượng mã kiểm tra đơn vị tương tự về kích thước và chất lượng làm cơ sở mã của dự án
  6. Mã giao diện tách biệt với mã logic kinh doanh mà phải tách biệt với mã truy cập cơ sở hạ tầng (email, cơ sở dữ liệu, dịch vụ web, hệ thống tệp, v.v.)
  7. một công cụ phân tích hiệu suất suy nghĩ về mã (NDepend, NDoc, NCover, v.v.)

Còn rất nhiều thứ nữa ... nhưng điều này giúp bạn bắt đầu.

+0

heh +1 cho lời khen, và thông tin của khóa học ... Tôi hy vọng chúng tôi có thể nhận được một số phản hồi tốt ở đây. Tôi nghĩ đây là một câu hỏi rất lớn trong ngành công nghiệp giữa chúng ta với các anh chàng IT và các anh chàng lập trình viên ... nếu chúng ta có thể thu hẹp khoảng cách tốt hơn một chút, thì tất cả chúng ta sẽ tốt hơn. – Krevin

+0

Sẽ là +1 ngoại trừ mã kiểm tra đơn vị có kích thước tương tự với cơ sở mã dự án. Tôi cho một trong những câu hỏi đó như là một chỉ số của mã tốt. Tôi đang ở trong trại Joel & Jeff đủ công bằng để viết các bài kiểm tra Đơn vị cho các giao diện/apis nhưng viết các bài kiểm tra đơn vị cho mọi kịch bản có thể chỉ là quá mức cần thiết. Bên cạnh đó là danh sách tốt của nó .... vì vậy OK +1 anyway ... – MadMurf

+1

+1 Đặc biệt là số 4 "Theo nguyên tắc RẮN". Là một thử nghiệm tốt, hãy thêm một số tính năng vào ứng dụng hoặc thực hiện bất kỳ sửa đổi nào về tính năng hiện tại của ứng dụng.Nếu mã hóa theo nguyên tắc SOLID, thì những thay đổi được thực hiện cho ứng dụng sẽ không ảnh hưởng lớn đến ứng dụng –

3

Đầu tiên, đặt ra các quy tắc nền tảng (tất cả những người lập trình đăng ký) nói rằng điều gì là 'tốt' và điều gì không. Tự động kiểm tra cho những người mà bạn có thể đo lường (ví dụ: chức năng ít hơn một số dòng, sự phức tạp của McCabe, thành ngữ mà các lập trình viên của bạn thấy khó hiểu). Sau đó, chấp nhận rằng 'mã hóa tốt' là điều bạn biết khi bạn thấy chứ không phải thứ gì đó bạn có thể ghim xuống với một bộ quy tắc và cho phép mọi người đi chệch khỏi tiêu chuẩn được cung cấp họ nhận được thỏa thuận từ một người có nhiều kinh nghiệm hơn. Tương tự, các tiêu chuẩn như vậy phải là tài liệu sống, được điều chỉnh khi đối mặt với phản hồi.

Đánh giá mã cũng hoạt động tốt, vì không phải tất cả các quy tắc 'kiểu tốt' như vậy đều có thể được xác định tự động. Các lập trình viên có kinh nghiệm có thể nói những gì họ không thích về mã lập trình thiếu kinh nghiệm - và bạn phải làm cho các tác giả ban đầu thay đổi nó để họ học từ những sai lầm của họ - và lập trình viên thiếu kinh nghiệm có thể nói những gì họ thấy khó hiểu về mã của người khác - và, bằng cách buộc phải đọc mã của người khác, họ cũng sẽ học các thủ đoạn mới. Một lần nữa, điều này sẽ cung cấp cho bạn thông tin phản hồi về tiêu chuẩn của bạn.

Trên một số điểm, độ phức tạp và kích thước chức năng cụ thể của bạn hoạt động tốt, cũng như độ bao phủ mã trong thử nghiệm lặp lại (đơn vị), nhưng điểm cuối cùng đi kèm với báo trước: trừ khi bạn đang làm việc một điều cần thiết (mã nhúng, như một ví dụ, hoặc mã quan trọng về an toàn) bảo hiểm mã 100% có nghĩa là bạn đang thử nghiệm 10% đường dẫn mã đáng giá để kiểm tra và 90% hầu như không bao giờ bị mã hóa sai ở nơi đầu tiên . Các bài kiểm tra đáng giá là những bài kiểm tra lỗi và cải thiện khả năng bảo trì.

+0

điểm tốt .. vì vậy có một cái gì đó để suy nghĩ về như xa như lợi nhuận giảm dần trong thử nghiệm ... kiểm tra những gì 'testworthy' và không nhận được quá bị cuốn vào thử nghiệm tất cả mọi thứ. Cảm ơn vì sự thấu hiểu. – Krevin

1

nó một khó khăn và có thể là nơi yêu cầu phi chức năng của bạn sẽ giúp bạn

  • xác định các yêu cầu hiệu suất của bạn: giao dịch mỗi giây, thời gian đáp ứng, dự kiến ​​ghi DB theo thời gian,
  • yêu cầu giao hàng để bao gồm kết quả từ công cụ phân tích hiệu suất
  • chỉ định máy ứng dụng sẽ chạy, bạn không cần phải nâng cấp phần cứng để chạy ứng dụng

Đối với nhãn cầu mã và làm việc có hay không bằng văn bản của nó khó khăn hơn, các câu trả lời từ @Andrew & @ Chris che nó khá nhiều ... bạn muốn mã có vẻ tốt, rất dễ dàng để duy trì và là performant.

2

Tôi nghĩ thật tuyệt khi bạn đang cố gắng đánh giá một thứ gì đó thường không được đánh giá. Đã có một số câu trả lời hay ở trên rồi. Bạn đã cho thấy mình trưởng thành hơn trong việc đối phó với phần mềm bằng cách chấp nhận rằng vì bạn không thực hành phát triển cá nhân, bạn không thể giả định rằng phần mềm viết dễ dàng.

Bạn có biết nhà phát triển có công việc mà bạn tin tưởng không? Có lẽ người đó là một phần của quá trình đánh giá.

5

Mã có 2 khán giả chính:

  • Những người sử dụng nó
  • Những người phát triển nó

Vì vậy, bạn neeed 2 bài kiểm tra đơn giản:

  • Chạy mã. Bạn có thể làm cho nó để làm công việc đó là nghĩa vụ phải làm gì?
  • Đọc mã. Bạn có thể hiểu được ý định chung của nhà phát triển không?

Nếu bạn có thể trả lời có cho cả hai, đây là mã tuyệt vời.

Khi đọc mã, đừng lo lắng rằng bạn không phải là lập trình viên. Nếu mã được viết/tài liệu rõ ràng, ngay cả người không lập trình cũng có thể thấy được nhiều dự đoán của nó.

BTW: Câu hỏi hay! Tôi muốn nhiều người không lập trình quan tâm đến chất lượng mã.

+0

Lời khuyên tốt tổng thể, nhưng tôi sẽ cẩn thận về giả định rằng chỉ vì mã là có thể đọc được rằng nó là tuyệt vời. Có rất nhiều điều vượt quá khả năng đọc mã có ảnh hưởng đến yếu tố bảo trì của nó, mặc dù tôi đồng ý rằng mã bạn có thể hiểu là một heck tốt hơn rất nhiều so với mã bạn không thể. –

+0

@Bernard: Bạn nghĩ gì? – Kramii

+0

Những thứ như phân vùng ứng dụng, tầm cỡ xử lý ngoại lệ và thiết kế chung. Đó là những điều bạn không thể lúc nào cũng chỉ nói từ những phần được đọc dễ đọc. Lưu ý rằng tôi không đồng ý với bạn, chỉ cần thêm một số ngữ cảnh. –

0

Tóm tắt

Sử dụng Joel Test.

Tại sao?

Cảm ơn câu hỏi khó. Tôi sắp viết một câu trả lời dài về thành tích đánh giá mã trực tiếp và gián tiếp, hiểu bối cảnh tổ chức của bạn, quan điểm, tìm ra quy trình và đặt tiêu chí cho mã là đủ tốt, và sau đó sự khác biệt giữa mã hoàn hảo và chỉ đủ tốt mà vẫn có thể có nghĩa là "rất ấn tượng". Tôi sắp tham khảo Steve McConnell’s Code Complete và thậm chí đề xuất ủy quyền kiểm toán mã cho ai đó vô tư, bạn có thể tin tưởng, ai đủ hiểu biết về kinh doanh và lập trình để nắm bắt bối cảnh, phối cảnh, áp dụng các tiêu chí một cách hợp lý và báo cáo kết quả gọn gàng lại cho bạn . Tôi sẽ khuyên bạn nên xem xét các phần của giao diện người dùng thông thường nằm ngoài tầm với của người dùng cuối giống như cách để đánh giá chất lượng làm sạch bằng cách kiểm tra bụi bẩn ở những nơi khó tiếp cận.

Vâng, và sau đó nó đánh tôi: mục tiêu cuối cùng là gì? Trong hầu hết, nhưng rất ít kịch bản mã hóa cao bồi cạnh, do kết quả của việc kiểm tra, bạn có thể khám phá ra rằng mã này tốt hơn rác, nhưng chắc chắn không phải là tốt, có thể chỉ thấp hơn một chút so với nhãn hiệu đủ tốt. Và sau đó là gì tiếp theo? Có thể sẽ có một vài lựa chọn:

  1. Thay đổi nhà cung cấp.
  2. Nhấn mạnh vào mã đang được tính lại.
  3. Rời khỏi mọi thứ khi chúng đến và từ thời điểm đó để yêu cầu mã tốt hơn.

Thật không may, không có tùy chọn nào là lý tưởng hoặc rất tốt.Nhà cung cấp thay đổi đầu tư là tốn kém và khá rủi ro: một phần của tính toàn vẹn khái niệm phần mềm sẽ bị mất, công ty của bạn sẽ phải, mặc dù gián tiếp, nuốt chi phí không thể tránh khỏi của nhà cung cấp mới tiếp quản phát triển và đi qua đường cong học tập (đối lập chính xác với hầu hết các nhà cung cấp sẽ yêu cầu bạn thử và đặt chân vào cửa). Và sẽ có một nguy cơ lớn bị thiếu thời hạn ban đầu.

Tùy chọn nhấn mạnh việc tính lại mã không hoàn hảo. Sẽ có một câu hỏi về chi phí và rất có thể vì nhiều lý do hợp đồng và lịch sử khác nhau, bạn sẽ không thấy mình ở vị trí thương lượng tốt. Trong mọi trường hợp, phần mềm viết lại có khả năng ảnh hưởng đến thời hạn và tổ chức những gì không thể thực hiện công việc ngay lần đầu tiên là rất khó có thể tạo ra mã tốt hơn cho lần thử thứ hai. Sau này là thích hợp với lựa chọn thứ ba tôi sẽ không rõ ràng của bất kỳ công ty sản xuất một mã tốt hơn mà không có một số, thường xuyên đáng kể, thay đổi tổ chức. Rời khỏi mọi thứ vì chúng không tốt: một đoạn mã thối trừ khi hoàn toàn bị cô lập sẽ cuối cùng sẽ gây độc cho phần còn lại của nguồn.

này mang lại cho tôi đến kết luận thực tế, hoặc trong thực tế hai:

  1. Tập trung vào chọn các công ty phần mềm phù hợp ở một nơi đầu tiên, kể từ khi đi về phía trước tùy chọn sẽ được phần nào bị hạn chế.
  2. Sử dụng kiến ​​thức CNTT và quản lý để chọn một công ty tập trung vào việc thu hút và giữ lại các nhà phát triển tốt, tạo môi trường làm việc và văn hóa phù hợp để sản xuất mã chất lượng tốt thay vì dựa vào phân tích thực tế.

Không cần phải mở rộng tầm quan trọng của việc chọn đúng công ty ngay từ đầu thay vì đánh giá tổng kết dự án được phân phối; hy vọng rằng điểm đã được thực hiện.

Vâng, làm sao chúng ta biết công ty phần mềm là đúng? Ở đây tôi hoàn toàn đăng ký triết lý được truyền giảng bởi Joel Spolsky: chất lượng của phần mềm trực tiếp phụ thuộc vào chất lượng của những người liên quan mà nó đã được indicated by several studies có thể thay đổi theo thứ tự độ lớn. Và thông qua hoạt động của các nhà phát triển thị trường tự do, các công ty sẽ tập trung vào các công ty dựa trên số tiền mà một công ty cụ thể quan tâm đến việc thu hút và giữ lại chúng.

Như một quy tắc chung của cuộc sống, các lập trình viên tốt nhất sẽ làm việc với những người giỏi nhất, tốt với trung bình, tốt với trung bình và cao bồi với các lập trình viên cao bồi khác. Tuy nhiên có một lời cảnh báo. Hầu hết các công ty sẽ có ít nhất một hoặc hai nhà phát triển rất tốt mà họ quan tâm và cố gắng hết mình để giữ lại. Những devs luôn luôn đặt trên một tiền tuyến: để chữa cháy, để thu hút một khách hàng, để chứng minh tiềm năng tổ chức và thẩm quyền. Làm việc giữa các đồng nghiệp trung bình, trải qua nhiều dự án, và được coi là hoàng tộc, thật đáng buồn, những lập trình viên ngôi sao này thường xuyên chạm vào thực tế và trở thành prima donnas, những người sẽ không "bẩn" bàn tay của họ với bất kỳ công việc lập trình thực tế nào.

Thật không may, tài năng lập trình không quy mô và không chắc rằng prima donna sẽ làm việc trên dự án của bạn qua giai đoạn ban đầu được thiết kế để thu hút và khóa bạn trong vai trò khách hàng. Cuối cùng, mã sẽ được sản xuất bởi một đồng nghiệp ít tài năng hơn và kết quả là bạn sẽ có được những gì bạn sẽ nhận được.

Giải pháp là tìm kiếm một công ty có tài năng nhà phát triển phù hợp hơn và mọi người đều đủ tốt để sản xuất đúng chất lượng mã. Và khi nói đến việc chọn một tổ chức như vậy, nơi Joel Test trở nên hữu ích. Tôi tin rằng nó đặc biệt thích hợp cho ứng dụng của một người không có kinh nghiệm lập trình nhưng hiểu rõ về CNTT và quản lý.

Điểm số của công ty nhiều hơn trên Bài kiểm tra Joel càng có nhiều khả năng thu hút và giữ chân các nhà phát triển giỏi và quan trọng nhất là cung cấp cho họ các điều kiện để tạo mã chất lượng. Và vì hầu hết các nhà phát triển giỏi thực sự yêu thích lập trình nên cần phải hợp tác, tạo môi trường làm việc tốt và hỗ trợ, mục tiêu đáng tin cậy (hoặc thậm chí tuyệt vời hơn) và họ sẽ bắt đầu tung ra mã chất lượng cao. Nó đơn giản mà. Vâng, điều duy nhất là công ty có điểm số đầy đủ mười hai điểm trong Bài kiểm tra của Joel có khả năng sẽ tính phí nhiều hơn một cửa hàng bán đồ có giá trị chỉ bằng 3 hoặc 5 (mức trung bình ngành tự ước tính). Tuy nhiên, lợi ích của việc có sức mạnh tổng hợp của các hoạt động hiệu quả và bespoke phần mềm không gặp khó khăn thúc đẩy các mục tiêu chiến lược chắc chắn sẽ tạo ra lợi tức đầu tư vượt trội và vượt qua mọi rào cản vượt xa mọi chi phí dự án. Ý tôi là, vào cuối ngày công việc của công ty có thể sẽ đáng giá tiền, mỗi xu của nó.

Cũng hy vọng rằng ai đó sẽ tìm thấy câu trả lời dài đáng giá này.

Các vấn đề liên quan