Để nghiêm khắc hay thực dụng?

Tôi bắt đầu nhận ra rằng việc phát triển phần mềm là (trong số những thứ khác) là một quá trình liên tục tự đặt câu hỏi cho chính mình. Các câu hỏi liên quan đến chất lượng mã, tách các mối quan tâm, giảm thiểu sự phụ thuộc, ...

Nhưng câu hỏi chính là: bạn có thể đi bao xa mà không phải vào bệnh viện tâm thần?

Tôi đang xin việc mới. Hôm qua tôi đã ở với một chủ nhân tương lai có thể muốn kiểm tra khả năng lập trình của tôi. Một trong những bài tập là: giải thích những gì mã này làm. Tôi đã xem qua một số mã của ứng dụng (winforms trong vb.net) mà họ phát triển (đó là một ứng dụng hành chính cho bệnh viện). Điều này đã cho tôi cơ hội để thực sự thấy cách họ tiếp cận mọi thứ và nó khá thất vọng.

Vài ví dụ:

• Tôi đã thấy ở đâu đó: Gọi [chèn tên của chương trình con vào đây] -> Tôi bị đánh: đó không phải là thứ gì đó từ VB6?
• Họ có một bộ dữ liệu riêng, sử dụng ado.net, nhưng một phương thức tôi phải kiểm tra sẽ trả về một tập dữ liệu cho lớp gọi. Vì vậy, riêng biệt datalayer hay không, ứng dụng được gắn với ado.net (điều này cũng không bao giờ có thể là vấn đề nếu họ không bao giờ chuyển sang cách tiếp cận truy cập dữ liệu khác).
• Bộ dữ liệu đó được đọc nguyên trạng, vì vậy nó vẫn là một cách tiếp cận tập trung vào dữ liệu (tất nhiên, người ta có thể tranh luận mức độ logic / hành vi bạn có thể đặt trong các lớp như "Bệnh nhân" hoặc "LabAnalysisRequest".
• Tôi cũng tin rằng đã thấy việc xây dựng một truy vấn sql bằng cách nối chuỗi.
• Họ sử dụng các thủ tục được lưu trữ (mà theo tôi, có nghĩa là: phân tán logic)
• không đề cập đến lượt xem / bộ điều khiển: tất cả đều do hình thức điều khiển
• Điều xấu xí nhất tôi thấy là:

      Nếu TestEnFE.IsTesting thì
         someVar = [một số giá trị được mã hóa cứng]
      khác
         someVar = [một số giá trị được lấy động]
      kết thúc nếu
      [phần còn lại của chức năng ở đây]
  

Tất cả đều khác với những gì tôi học được ở trường: lớp miền (thuyết bất khả tri), lớp kiên trì, lớp trình bày, kiểm tra đơn vị, ...

Vì vậy, tôi viết lại câu hỏi của mình: một người nên giáo dục cơ bản hay giáo điều như thế nào? Ở mức độ nào thì một lập trình viên nên tuân thủ các nguyên tắc của mình hoặc chỉ viết mã thực hiện công việc?

Tôi biết rằng không trả lời trực tiếp câu hỏi của bạn, nhưng tôi vẫn cảm thấy điều này đáng giá hơn một nhận xét:

Khi bạn thực hiện một cuộc phỏng vấn xin việc, bạn đang phỏng vấn họ nhiều như họ đang phỏng vấn bạn . Hãy bỏ thói quen xem một cuộc phỏng vấn như một cái gì đó bạn bò lên bụng cầu xin họ cung cấp cho bạn một cái gì đó. Họ kiểm tra bạn, nhưng bạn cũng kiểm tra họ . Nếu họ không thích bạn, họ sẽ không thuê bạn. Nếu bạn không thích họ, đừng đi làm việc ở đó.

Vâng, trong ngành, với một cơ sở mã di sản mười năm đã bị tấn công theo thời gian bởi ba chục nhà phát triển với nền tảng, kỹ năng và niềm đam mê khác nhau, bị thúc đẩy bởi thời hạn chặt chẽ, thiếu nguồn lực và hạn chế tài chính, mã sẽ không bao giờ nhìn theo cách mà bạn (nên) đã học nó nên nhìn. Bạn sẽ phải thực hiện một số nhượng bộ. Nhưng có bao nhiêu, và nơi bạn vẽ đường, điều đó hoàn toàn phụ thuộc vào bạn.
Tất nhiên, công việc khó hơn để tìm ra ít nhượng bộ bạn thực hiện. Nhưng họ có thể thú vị hơn.

FWIW, cho đến nay (> 10 năm trong ngành) chưa bao giờ làm việc trong một công ty lớn với nhiều nhà phát triển (~ 30 nhà phát triển là nhiều nhất, hàng tá chỉ tiêu), bởi vì rất có thể bạn sẽ thay đổi một thứ gì đó nhỏ Công ty. Miễn là tôi kiếm đủ tiền để không bỏ đói bọn trẻ, tôi sẽ không muốn trở thành một bánh răng nhỏ trong một công ty lớn, nơi tất cả những gì tôi phải làm là đồng bộ với các bánh răng còn lại.
Tôi đã từ chối lời mời làm việc sau khi xem các bài kiểm tra mà họ muốn tôi vượt qua. Tôi là một nhà phát triển C ++ và có rất nhiều bài kiểm tra C ++ rất tệ, điều đó khiến móng chân của bạn cong lên một cách kinh tởm và tôi không muốn dành thời gian của mình để chiến đấu với cối xay gió vì họ đã thuê những kẻ ngu ngốc không thể viết mã sạch.
Tôi cũng đã nghỉ việc sau vài tháng vì triết lý lập trình của họ (mục tiêu ngắn hạn, không bận tâm vào năm tới) không phù hợp với khả năng của tôi (ổn định mã dài hạn), mặc dù họ nói khác nhau trong cuộc phỏng vấn.

Không bao giờ viết mã mà chỉ làm công việc. Tuy nhiên, hãy sẵn sàng để kiểm tra học thuyết của bạn. Chỉ vì bạn đã học nó ở trường, không có nghĩa đó là suy nghĩ hiện tại, hoặc thậm chí là suy nghĩ hợp lệ. Vòng đời thiết kế phần mềm trở nên lỗi thời, do lập trình phải phản ứng nhiều hơn với thế giới kinh doanh. Đôi khi các giải pháp phần mềm được liên kết lúng túng được liên kết một cách vụng về vì các bộ phận đã được thay thế khi thời gian cho phép.

Dưới đây là danh sách các vấn đề tôi đã biên soạn sẽ xác định mức độ phù hợp với lối sống mã hóa của một công ty.

1. Họ coi trọng việc đặt thời gian sang một bên để tái cấu trúc và cập nhật cơ sở mã của họ. Cách họ xem cập nhật cơ sở mã sẽ là một yếu tố quyết định chính trong việc bạn phù hợp với mức độ nào.
2. Tần suất họ mua bên thứ 3 thay vì mã hóa trong nhà.
3. Họ nghĩ gì về phần mềm nguồn mở. Họ có nhận ra rằng họ có sự linh hoạt trong việc thay đổi mã. Họ có xem nó giống như cách mua bên thứ 3 không.
4. Bạn sẽ làm việc trên một lớp trừu tượng nhất định. Đội bạn có giao diện xác định giao diện cho bạn không? Lớp / đội / bên nào của giao diện có nhiều quyền lực hơn trong việc ra quyết định.
5. Làm thế nào nhiều giám sát lắng nghe các lập trình viên khi đưa ra quyết định. Khi một lập trình viên ném cờ đỏ, giám sát sẽ dừng lại và xem xét quyết định của họ.
6. Bạn có xem xét các lập trình viên có kinh nghiệm quản lý? Làm thế nào để họ xem kinh nghiệm của họ? Kinh nghiệm của họ có hợp lệ không? Có phải họ để cho kinh nghiệm lỗi thời ảnh hưởng đến việc ra quyết định?
7. Làm thế nào dính là cơ sở mã?
8. Tần suất họ cập nhật các công cụ lập trình của họ (IDE, v.v.)

Các câu trả lời cho những câu hỏi này phù hợp hơn với cách bạn sẽ coi trọng lối sống lập trình của họ, hơn là xem liệu chúng có phù hợp với giáo điều của bạn không.

Giáo điều chắc chắn sẽ bị phá vỡ (chúng ta không có thời gian để cập nhật X). Tuy nhiên, các ưu tiên sẽ xác định mức độ bạn đụng độ với phong cách và ra quyết định của họ.

Tôi nghĩ bạn phải cân nhắc điều này như một phần của toàn bộ. Tôi nhớ rằng một trong những công việc đầu tiên của tôi là một vị trí trong một nhóm nói với tôi rằng họ đang làm C ++ hướng đối tượng - đó là những gì tôi đã làm trong vài năm ở trường.

Sự tự đánh giá của họ là sai - họ đã làm việc hơi mập mạp C. Nó vẫn được thiết kế rất chức năng trong tự nhiên và tôi phải tự đi lấy một cuốn sách C để dạy bản thân printf và getf và các cơ chế C khác mà tôi chưa từng học. Thực tế là không ai trong nhóm thậm chí nhận ra C như mã của họ đã chỉ ra làm thế nào mà dấu hiệu "thiết kế C ++" này đã giảm. Mục tiêu của tôi lúc đó là phát triển OO, vì vậy điều này thật tuyệt vời.

Nhưng tôi rất vui, cuối cùng, tôi đã bị mắc kẹt với đội. Họ là một nhóm năng động gồm những người rất thông minh và tôi bị ướt chân với rất nhiều vấn đề khó khăn, tôi phải làm việc trong suốt vòng đời và những điều tôi học được về lĩnh vực vấn đề (PKI) đã thúc đẩy sự nghiệp của tôi kể từ đó. Công việc mà nhóm đang làm trong không gian chức năng thật tuyệt vời và tôi vẫn nghĩ rất thích sản phẩm đó và kinh nghiệm làm việc đó. Tốt hơn nữa - tôi vẫn làm việc với một số người trong số họ ngày hôm nay (một số công ty sau này), họ vẫn là nguồn cảm hứng và chúng tôi vẫn đang làm việc tốt.

Tôi không nghĩ rằng việc thực hiện hoàn hảo các thực tiễn tốt nhất của ngôn ngữ mã hóa là tạo ra hoặc phá vỡ trải nghiệm làm việc tốt hoặc một nhóm tốt - công việc mang lại sự nghiệp nhiều hơn thế, và nếu sản phẩm có phong nha chất lượng, nhóm có điều kiện làm việc tốt (như Joel Test) và nhóm có đầy đủ những người thông minh và hoàn thành công việc, sau đó sự hoàn hảo của việc thực hiện chỉ là thứ yếu. Loại bỏ các yếu tố như công việc tốt, người tốt, điều kiện làm việc tốt - và không đáng để dính vào - liệu mã có được đặt kỳ quặc hay không.

làm thế nào cơ bản hoặc giáo điều nên được một? Ở mức độ nào thì một lập trình viên nên tuân thủ các nguyên tắc của mình hoặc chỉ viết mã thực hiện công việc?

Điều quan trọng nhất cần nhớ ở đây là mục đích của bạn là gì?

Trong hầu hết các công ty, mục đích của bạn trong cuộc sống không phải là viết mã hoàn hảo. Mục đích của bạn là cung cấp giá trị cho người dùng. Viết mã tốt thường là tốt nhất cách để cung cấp một sản phẩm tốt cũng dễ bảo trì, xử lý sự cố và phát triển.

Mã tốt là một công cụ mà bạn nên áp dụng khi nó mang lại cho bạn ROI tốt.

Vài ví dụ:

1. Tôi sẽ dành nhiều thời gian để thiết kế và mã hóa các API của mình, đặc biệt là API cấp doanh nghiệp của tôi. Rất nhiều lập trình viên khác sẽ sử dụng chúng và nó sẽ tiết kiệm rất nhiều thời gian và vấn đề nếu chúng được thiết kế đúng
2. Tôi sẽ thư giãn các quy tắc một chút trong lớp trình bày của tôi. Ở đó tôi sẽ có xu hướng hy sinh mã "hoàn hảo" hơn để ủng hộ thêm nhiều tính năng

Điểm mấu chốt, bạn cần phải có nguyên tắc nhưng bạn cũng nên đủ linh hoạt để phá vỡ những nguyên tắc đó khi chúng mang lại nhiều tác hại hơn giá trị.

Tôi đã làm việc cho một nhà bán lẻ thương mại điện tử trong một vài năm. Khi tôi bắt đầu ở đó, mã cho các ứng dụng nội bộ của họ đều được viết bằng VB cho MS Access, và thật kinh khủng khi nói ít nhất. Tôi đã có một nhóm gồm 3 nhà phát triển và trong vài năm tới chúng tôi đã thay thế điều này bằng các ứng dụng VB.Net thích hợp.

Nhưng vì ngân sách tuyển dụng của tôi vô cùng hạn chế, tôi chỉ có thể chi trả cho các lập trình viên cơ sở. Và, tất nhiên, mã họ tạo ra không tuyệt vời đến thế. Nhưng nó đã hoạt động và công ty đã sử dụng các ứng dụng này để kiếm tiền mỗi ngày.

Và sau đó tôi bắt đầu làm việc với các bạn của tôi. Một chút đào tạo trong OOD, về thiết kế cơ sở dữ liệu, trong MVC và C #. Và qua nhiều năm, mọi thứ được cải thiện. Khi tôi rời đi sau 4 năm, codebase vẫn không tuyệt vời, nhưng nó tốt hơn 100 lần so với khi tôi bắt đầu.

Một tình huống như tình huống bạn mô tả thường là hậu quả của việc phải thực hiện với các tài nguyên có sẵn. Chúng ta không sống trong một thế giới lý tưởng. Đồng thời, đây là một cơ hội tuyệt vời để thực sự tạo ra sự khác biệt.

BTW: một số ứng dụng này vẫn đang được sử dụng, hầu như không thay đổi so với khoảng 3 năm trước và chúng vẫn kiếm được tiền.

Tôi nghĩ rằng việc tuân thủ các nguyên tắc của bạn là rất quan trọng. Bạn nên luôn luôn cố gắng để tạo ra mã tốt nhất có thể trong các ràng buộc được đưa ra. Tuy nhiên, nếu bạn thêm "không bao giờ phải đọc hoặc thay đổi mã xấu" vào danh sách các nguyên tắc của mình, bạn sẽ gặp rất nhiều khó khăn khi tìm việc. Hãy nhớ rằng 50% lập trình viên đã tốt nghiệp ở nửa dưới của lớp. Ngay cả trong một nhóm một người, "hôm nay bạn" có trình độ tốt hơn để giải quyết vấn đề so với "tháng trước bạn". Có thể làm việc với mã không lý tưởng chỉ là một phần của công việc.

Rất nhiều nhà tuyển dụng nhận ra điều đó, vì vậy họ mã họ đưa cho bạn đọc có thể là đại diện cho mã tồi tệ nhất trong cơ sở mã của họ, chứ không phải là tốt nhất của họ. Nếu điều đó không rõ ràng từ bối cảnh, bạn nên hỏi. Một đồng nghiệp mà tôi thỉnh thoảng phỏng vấn có một trang mã anh ta cố tình viết kém chỉ để sử dụng như một câu hỏi phỏng vấn.

Trong 99% trường hợp, bạn nên tuân theo «giáo điều» khi bạn gọi nó. Giáo điều được tạo ra bởi những người có kinh nghiệm qua nhiều năm thực hành, và những gì có vẻ thực dụng ở một số điểm thực sự thường không. Điều này thường có liên quan nhiều hơn thực tế là bạn không đủ tốt để xử lý vấn đề đó đúng cách.

Tuy nhiên, đừng theo giáo điều một cách mù quáng. Hãy nhớ những kết luận nào dẫn mọi người đi theo giáo điều đó. Bởi vì bạn sẽ tìm thấy một phần nhỏ các trường hợp không nên theo dõi. Dù sao, những trường hợp đó sẽ rất hiếm và bạn nên luôn luôn thảo luận với một số lập trình viên có kinh nghiệm khác trước khi đưa ra quyết định như vậy.

Hãy nghiêm khắc khi nó quan trọng. Phong cách cú đúp (hoặc các quy ước mã hóa khác)? Nó không thành vấn đề. Sử dụng một trong những cửa hàng sử dụng. Phá vỡ đóng gói (hoặc các nguyên tắc lập trình cơ bản khác) không có lý do chính đáng? Không tầm thường như vậy.

Stack Exchange sử dụng các bảng để bố trí (cũng như nhiều trang web lớn khác đang kiếm tiền ). Điều đó làm cho khói ra khỏi tai những người theo chủ nghĩa thuần túy? Chắc chắn là có. Nhưng chủ nghĩa thực dụng chiến thắng sự tinh khiết, mọi lúc. Vận chuyển sản phẩm thắng trong việc làm cho nó hoàn hảo, mọi lúc.

Toàn bộ lớp miền, lớp kiên trì, lớp trình bày, điều thử nghiệm đơn vị vẫn còn tương đối mới, từ quan điểm lịch sử. Có rất nhiều phần mềm ngoài kia vẫn sử dụng mô hình Máy khách / Máy chủ và sẽ không được thay đổi thành kiểu kiến ​​trúc mới nhất chỉ vì nó "tốt hơn".