Một lập trình viên nên có bao nhiêu tự do trong việc lựa chọn một ngôn ngữ và khuôn khổ?

Tôi bắt đầu làm việc tại một công ty chủ yếu theo định hướng C #. Chúng tôi có một vài người thích Java và JRuby, nhưng phần lớn các lập trình viên ở đây thích C #. Tôi đã được thuê bởi vì tôi có nhiều kinh nghiệm xây dựng các ứng dụng web và vì tôi nghiêng về các công nghệ mới hơn như JRuby trên Rails hoặc nodejs.

Gần đây tôi đã bắt đầu một dự án xây dựng một ứng dụng web với trọng tâm là hoàn thành nhiều thứ trong một khoảng thời gian ngắn. Phần mềm dẫn đã ra lệnh rằng tôi sử dụng mvc4 thay vì đường ray. Điều đó có thể ổn, ngoại trừ tôi không biết mvc4, tôi không biết C # và tôi là người duy nhất chịu trách nhiệm tạo máy chủ ứng dụng web và giao diện người dùng phía trước.

Sẽ không có ý nghĩa khi sử dụng một khung mà tôi đã biết rất rõ (Rails) thay vì sử dụng mvc4? Lý do đằng sau quyết định này là người lãnh đạo công nghệ không biết về đường ray / đường ray và sẽ không có cách nào để sử dụng lại mã.

Đối số truy cập:

• Anh ấy sẽ không đóng góp cho mã và, thẳng thắn, không cần thiết cho
  dự án này. Vì vậy, nó không thực sự quan trọng nếu anh ta biết JRuby / rails hay không.

• Chúng tôi thực sự có thể sử dụng lại mã vì chúng tôi có rất nhiều ứng dụng java mà JRuby có thể lấy mã từ và ngược lại. Trên thực tế, anh ta đã dành một số tài nguyên để chuyển đổi thư viện Java sang C #, thay vì chỉ chạy thư viện Java trên ứng dụng JRuby on Rails. Tất cả chỉ vì anh ấy không thích Java hay JRuby

Tôi đã xây dựng nhiều ứng dụng web, nhưng sử dụng một cái gì đó không quen thuộc đang gây ra một số spin-up và tôi không thể xây dựng một ứng dụng tuyệt vời trong một thời gian ngắn như tôi đã từng sử dụng. Điều này sẽ ổn thôi; học các công nghệ mới là quan trọng trong lĩnh vực này. Vấn đề là, đối với dự án này, chúng ta cần hoàn thành nhanh chóng.

Tại thời điểm nào một nhà phát triển nên được phép chọn công cụ của mình? Điều này có phụ thuộc vào công ty không? Công ty của tôi hút hay điều này được coi là bình thường? Có đồng cỏ xanh hơn tồn tại? Tôi đang nhìn điều này sai cách?

Tôi muốn nói rằng bạn phải nói chuyện với trưởng nhóm và nói điều gì đó như:

Tôi biết các bạn là một cửa hàng .NET, nhưng tôi thực sự được thuê cho các kỹ năng Java / JRubyRails của tôi. Tôi có thể xây dựng ứng dụng mới này trong X lượng thời gian bằng những công cụ mà tôi đã biết. Tôi có thể học C # / mvc4 như bạn muốn, nhưng sẽ mất >> X lượng thời gian. Bạn muốn gì?

Điều này đặt ra vấn đề "kỹ năng-bạn-đã- ​​(giả định) đã mệt mỏi vì" so với "kỹ năng bạn cần bây giờ" và cũng cho thấy rằng bạn sẵn sàng học các kỹ năng mới, nhưng điều đó sẽ mất lâu hơn để phát triển ứng dụng mới vì bạn chưa quen với bộ công cụ này. Và bạn làm muốn chứng tỏ rằng bạn sẵn sàng để học các kỹ năng mới. Không cởi mở để học các kỹ năng mới là một cách tốt để đảm bảo việc làm của bạn kết thúc khi các kỹ năng của bạn không còn cần thiết nữa.

Khi câu hỏi của bạn ở cuối:

Tại thời điểm nào một nhà phát triển nên được phép chọn công cụ của mình? Điều này có phụ thuộc vào công ty không? Công ty của tôi hút hay điều này được coi là bình thường? Có đồng cỏ xanh hơn tồn tại? Tôi đang nhìn điều này sai cách?

Nó thường phụ thuộc vào công ty. Nếu một công ty mua các công cụ MS và chuẩn hóa mọi thứ trên nền tảng VisualStudio và .NET framework, thì có thể sẽ rất khó xử nếu một nhà phát triển khăng khăng sử dụng Linux và C. Điều đó là bình thường. Các ngoại lệ có thể tồn tại khi công ty ít cầu kỳ hơn về các biên tập viên, chẳng hạn như cho phép các nhà phát triển chọn Vi so với Emacs, miễn là đầu ra giống nhau. Tôi biết một số công ty thậm chí cho phép các nhà phát triển chọn Windows so với Linux, nhưng ngôn ngữ họ làm việc có sự hỗ trợ và thời gian chạy rất tốt cho cả hai hệ điều hành.

Tại sao các công ty làm điều này? Kiên định là một lý do. Có thể rất khó để gỡ lỗi mọi thứ khi ứng dụng là một bản vá nhị phân được xây dựng bằng các ngôn ngữ / khung yêu thích của các nhà phát triển khác nhau, được xây dựng trong các công cụ khác nhau và thử nghiệm trên các hệ thống rất khác nhau. Nếu tất cả các nhà phát triển làm việc trên hầu hết các thiết lập tương tự, các loại vấn đề đó sẽ được giải quyết.

Trong trường hợp của bạn, có vẻ như bạn được thuê để làm việc trong công nghệ không chuẩn trong công ty này. Điều này có vẻ lạ đối với tôi và bạn có thể muốn nói chuyện với người đã thuê bạn về lý do tại sao họ muốn điều đó.

Tại thời điểm nào một nhà phát triển nên được phép chọn công cụ của mình?

Khi họ không tác động đến đội của bạn.

Tôi đang nhìn điều này sai cách?

Chắc chắn rồi.

Vâng, bạn có một thời hạn ngắn. Có, bạn có thể hoàn thành nó nhanh hơn trong Rails. Nhưng toàn bộ công ty cần triển khai và duy trì ứng dụng. Nếu công ty có sự ổn định của các nhà phát triển C # tốt, thì có lẽ sẽ rẻ hơn (và mang lại chất lượng tốt hơn) để duy trì ứng dụng C #.

Các DBA và nhân viên quản trị khác của bạn có thể đã quen thuộc với ngăn xếp đó và có các quy trình để triển khai và cập nhật ngăn xếp đó . Ngay cả khi bạn có thể hoàn thành mã nhanh hơn, có thể sẽ mất nhiều thời gian hơn khi bạn tính đến tất cả các chi phí cần thiết để có được một ứng dụng web chuyên nghiệp và chạy.

Hãy nhớ rằng, bạn sẽ dành nhiều thời gian hơn để duy trì ứng dụng của mình hơn là viết nó. Tối ưu hóa cho chi phí đó.

1. Bạn rõ ràng đã được thuê vì khả năng thích ứng với các công nghệ "mới". C # là không khác nhau, về vấn đề đó. Bạn có chắc chắn không muốn có cơ hội học hỏi điều gì mới không?

2. ASP.NET MVC rất giống với Ruby on Rails, theo nhiều cách.

3. Bạn sẽ không ở tốc độ của ốc sên mãi mãi. Nếu bạn đã biết ROR, ASP.NET MVC sẽ là một cinch cho bạn. Bí quyết là học C #.

Đối số để ở với Java / JRuby

Rất có thể, ông chủ của bạn muốn bạn sản xuất. Họ thuê bạn để bạn có thể gia tăng giá trị cho công ty. Đảm bảo rằng họ hiểu rằng bằng cách buộc bạn sử dụng một khung mà bạn không quen thuộc, họ sẽ khiến bạn phải:

1. Tạo ra kết quả với tốc độ chậm hơn
2. Tạo mã chất lượng thấp hơn

Ngay cả những lập trình viên giỏi nhất cũng cần thời gian làm nóng với các ngôn ngữ / khung mới.

Đối số cho việc học MVC4 và C #

Học ngôn ngữ mới là tốt. Đầu tư vào các kỹ năng của bạn với tư cách là một lập trình viên chỉ là một rủi ro nếu ngôn ngữ / nền tảng bạn đang học sẽ biến mất trong tương lai gần và với Microsoft đang theo đuổi, tôi không nghĩ đó là vấn đề. Cả C # và MVC đều có các bản cập nhật gần đây cải thiện cả hai, thậm chí còn có nhiều bản cập nhật hơn.

Làm cho bạn, cá nhân, một nhà phát triển tròn trịa hơn sẽ giữ bạn khỏi bị đặt vào tình huống này một lần nữa. Phần tốt nhất? Sếp của bạn sẽ trả tiền cho bạn để học những điều này, nghĩa là bạn được trả tiền để khiến bản thân đáng giá hơn.

Điểm mấu chốt

Bạn có thể sẽ chiến thắng trong cuộc chiến này, nhưng bạn sẽ bị làm việc với những đồng nghiệp bất mãn. Chỉ cần giải thích những ưu và nhược điểm của từng người với người quản lý của bạn và sau đó cả hai sẽ đi ra đầu kia hạnh phúc hơn.

Tại thời điểm nào một nhà phát triển nên được phép chọn công cụ của mình?

Khi nói nhà phát triển là người dẫn đầu phần mềm.

Chắc chắn, bạn có thể (và nên) đưa ra trường hợp sử dụng bộ công cụ khác nhau nếu bạn quan tâm đến năng suất, nhưng hãy chuẩn bị cho câu trả lời mà bạn không thích. Có thể có một lý do chính đáng tại sao khách hàng tiềm năng của bạn muốn bạn sử dụng một bộ công cụ cụ thể, có thể là khả năng tương thích với kiến ​​trúc hiện tại, mối quan tâm về bảo trì, vấn đề cấp phép, v.v.

BTW, cụm từ

tập trung vào việc hoàn thành nhiều thứ trong một khoảng thời gian ngắn

chịu trách nhiệm cho nhiều ợ nóng và hỗn loạn trong ngành công nghiệp phần mềm hơn bất cứ thứ gì khác.

Tôi lưu ý rằng bạn không nói rằng bạn đã được thuê làm lập trình viên Java hoặc Java.

Đây là lý do tại sao bạn nói rằng bạn đã được thuê: "[B] vì tôi có nhiều kinh nghiệm xây dựng các ứng dụng web và vì tôi nghiêng về các công nghệ mới hơn như JRuby trên Rails hoặc nodejs."

Nói cách khác, họ thích trải nghiệm web của bạn và sự sẵn lòng của bạn để tìm hiểu các công nghệ mới.

Bây giờ họ đang yêu cầu bạn sử dụng trải nghiệm web của mình và tìm hiểu công nghệ mới.

Vì vậy, câu hỏi là, bạn sẽ làm điều đó, hay không?

Chi phí lớn nhất trong phần mềm là trong việc bảo trì nó

Tôi đọc rằng chi phí lớn nhất (80%) là trong việc bảo trì phần mềm. Sự phát triển ban đầu chỉ bằng 20% ​​tổng chi phí phát triển.

Tôi đã đọc một trường hợp về một nhà phát triển đã phát triển mã và nhận xét bằng ngôn ngữ mẹ đẻ của mình (không phải tiếng Anh) và khi các thành viên khác trong nhóm cải tiến và duy trì mã, điều đó là không thể vì ngôn ngữ (không phải ngôn ngữ lập trình nào) là tiếng nước ngoài đối với họ.

Tương tự, nếu bạn phát triển mã bằng ngôn ngữ lập trình theo lựa chọn của riêng bạn, sẽ rất khó để các thành viên khác trong nhóm duy trì.

Giải pháp: Lập trình cặp

Cân nhắc việc yêu cầu nhà tuyển dụng của bạn ghép bạn với một người khác biết ngôn ngữ lập trình cần thiết và bạn có thể làm việc cùng nhau. Bạn có thể học hỏi lẫn nhau và nếu một trong hai bạn rời khỏi công ty, người kia sẽ biết mã.

Bài viết trên Wikipedia về "Lập trình cặp": http://en.wikipedia.org/wiki/Pair_programming

Nhiều công ty chỉ đơn giản thích gắn bó với những gì họ đã luôn làm hoặc những gì "an toàn". Có một lý do Java và PHP vẫn rất phổ biến. Hiện tại, việc tìm kiếm "COBOL" trên really.com trả về 2144 danh sách ... điều đó thực sự có thể nói lên điều đó. Ngành công nghiệp không quan tâm đến mã tốt, nó quan tâm đến mã mà nó có thể vắt sữa càng lâu càng tốt (điều này không có nghĩa là C # là xấu, thực sự không phải vậy).

Hãy suy nghĩ về điều này: mã sẽ tồn tại lâu hơn bạn. Có một cơ hội tốt để người khác sẽ duy trì mã của bạn và C # là đặt cược an toàn hơn Node.js và Rails. Tôi sẽ không ngạc nhiên nếu trong 5 hoặc 6 năm nữa, số lượng lập trình viên Ruby giảm một nửa, sau tất cả những điều tương tự đã xảy ra với Perl và bất kỳ ngôn ngữ nào khác đã được xem xét tại một thời điểm nào đó là ngôn ngữ web "nó". Javascript không có khả năng biến mất nhưng chúng ta đã bắt đầu thấy nó được sử dụng như một loại ASM (hoặc thậm chí C) của web - một ngôn ngữ trung gian mà các ngôn ngữ khác có thể biên dịch để viết mã phía máy chủ trong đó có thể rất tốt trở nên lỗi thời.

Mối quan tâm chính của tôi với các nhà phát triển chọn cách thực hiện mục tiêu của họ, là họ thường cho rằng họ sẽ chỉ sửa mã. Nhìn vào nó theo cách này, 12 tháng sau họ có thể cần thay đổi; bạn không có mặt (rời công ty hoặc thực sự bận rộn với nhiệm vụ khác) và nhà phát triển khác phải khuấy mã của bạn. Nếu đó là một cửa hàng C #, thì sử dụng bộ công cụ của họ là tinh thần đồng đội tốt. Các công nghệ mới nên được nghiên cứu và thực hiện, nhưng chỉ khi người dẫn đầu nghĩ rằng thời gian là đúng, vì họ đã để mắt đến nhiều mục tiêu không chỉ một.

Hãy quay lại, làm ơn. Hãy tưởng tượng bạn là người thuê một nhà phát triển Ruby và họ khăng khăng triển khai công việc của họ trong Asp.net/MVC.

Bạn sẽ nói gì với họ? Đây là chồng của chúng tôi, người đàn ông. Học cách sống với nó.

Quy tắc vàng, đây là, cô ấy có vàng làm nên quy tắc.

Có một số mục tiêu mâu thuẫn và vấn đề là tìm ra sự thỏa hiệp tốt nhất. Chúng tôi có thời hạn, chúng tôi có một nhóm trưởng yêu cầu một bộ công cụ nhất định và chúng tôi có một nhà phát triển thiếu kinh nghiệm với bộ công cụ đó nhưng đã cam chịu sản xuất một cái gì đó trong khung thời gian (rõ ràng là ngắn).

Điều quan trọng là phải hiểu, rằng trưởng nhóm có thể có một số lý do chính đáng tại sao anh ta yêu cầu chính xác bộ công cụ này (một trong số đó thực sự có thể khiến bạn quen với bộ công cụ này vì một số lý do mà bạn có thể chưa biết). Điều tốt nhất bạn có thể làm trong lần chạy đầu tiên là tìm hiểu xem, những lý do này chính xác là gì.

Đặt vào vị trí của bạn, tôi sẽ cố gắng nói chuyện với trưởng nhóm và cố gắng giải thích tình huống, theo quan điểm của bạn, và các lựa chọn và kết quả nào (bao gồm các hiệu ứng kinh tế ngắn hạn và dài hạn) sẽ được tạo ra theo từng lựa chọn này Ví dụ: một nhà phát triển có kinh nghiệm khác có thể được chỉ định để huấn luyện bạn, có thể với một số phiên lập trình cặp hoặc tương tự.

Trừ khi nhóm trưởng của bạn là một kẻ ngốc hoàn toàn, bạn sẽ có thể tìm thấy sự đồng thuận có ý nghĩa đối với dự án và các mục tiêu chung của công ty.

Bah Mọi người đều sai.

Hãy là một nhà phát triển tốt hơn những người một nền tảng đó và bạn sẽ có nhiều lựa chọn thú vị hơn bao giờ hết. Vì vậy, bây giờ, hãy học MVC. Và trên thời gian của riêng bạn, tìm hiểu thêm về các nền tảng thực sự quan tâm đến bạn. Xây dựng kỹ năng Node của bạn. Tìm hiểu một số Django. Hãy chú ý đến bất kỳ trình duyệt Java hoặc tiền xử lý .NET .NET nào mà bạn tiếp xúc và sau đó chạy trốn nhưng ít nhất là học đủ để có thể chỉ trích và giải thích bạn đã nghĩ bao nhiêu vào định kiến ​​ghét bị che giấu của bạn về những nền tảng đó. (được rồi, có lẽ tôi đang chiếu ở đó)

Và bây giờ cho lời khuyên quan trọng. Nếu bạn tiếp tục trau dồi các chuyên môn của mình đồng thời đa dạng hóa chuyên môn của mình trong các lĩnh vực khác, cuối cùng bạn sẽ ở một nơi mà bạn có thể tìm công việc mới vào bất kỳ thời điểm nào trong năm trong vòng chưa đầy hai tuần tại bất kỳ thành phố lớn nào. chủ yếu là thú vị ít nhất một nửa thời gian. Khi bạn thấy mình ở nơi này, đừng tiếp tục với những công việc mà họ nói rằng họ muốn điều này và đến ngày thứ hai, họ sẽ làm điều đó mà không hy vọng có thể thấy trước được trong tương lai lâu dài. Chỉ cần lịch sự giải thích và xin lỗi nhưng không, bạn thực sự không muốn làm điều đó và nói nhiều như vậy trong cuộc phỏng vấn của bạn và sau đó! thực tế là họ đã trình bày sai vị trí cho bạn và từ chối thừa nhận điều đó.

Nhưng hãy tin tôi, tìm một buổi biểu diễn mới luôn tốt hơn nhiều so với việc bị kích thích nghiêm trọng và không vui trong bất kỳ khoảng thời gian nào kéo dài hơn 5 phút. Nhưng tất nhiên, đầu tiên bạn phải trả phí để bạn có thể làm điều đó. Một số người sẽ không bao giờ Đó là lý do tại sao họ muốn mọi thứ trong những thứ mà họ biết rõ nhất. Và tất nhiên những câu trả lời khác không thực sự sai. Thật có ý nghĩa cho một cửa hàng .NET đi với .NET nếu họ phải duy trì điều ngớ ngẩn.

Tất nhiên, điều không có ý nghĩa là tại sao họ lại đa dạng hóa với nhà phát triển Rails / JS / UI và chỉ có anh ta làm các ứng dụng MVC. Nhưng bây giờ. Bạn có thể cần phải nhặt nó lên và trả lệ phí của bạn. Và như tôi đã nói trong các bình luận, MVC thực sự không tệ đến thế. Một lựa chọn thực sự tồi tệ cho tất cả các lựa chọn nhưng chắc chắn không phải là tồi tệ nhất. Điều này khá đơn giản, không ném 10.000 lớp trừu tượng lên trên tất cả mọi thứ đang thực sự xảy ra và không bị vặn vẹo với phía khách hàng đến nỗi bạn sẽ nguyền rủa tên của các kỹ sư MS chịu trách nhiệm nếu có ai làm phiền để tìm hiểu chúng.

Vì vậy, hãy đến nơi mà bạn có thể rời đi khi bạn muốn nếu bạn chưa có và thậm chí bạn có thể thấy bạn có con mắt hoài nghi hơn về những thứ bạn hiện đang thích. Bạn thậm chí có thể thấy mình không thích đường ray nhiều như tôi. Không có gì sai với Ruby (tất nhiên không phải là thông dịch viên của nó).

Tùy thuộc vào tình huống của bạn, có thể nguy hiểm khi cho rằng bạn biết lý do tại sao họ thuê bạn, và thậm chí còn hơn để giả sử người quản lý của bạn biết điều đó và đồng ý rằng thuê người có kỹ năng của bạn là một ý tưởng tốt.

Tôi sẽ hỏi hãy đưa ra lời khuyên ở trên và đưa ra một trường hợp kinh doanh tại sao bạn nên đi với JRuby qua C #, có thể lập luận và thời gian của bạn có nghĩa là thoát khỏi những cách cũ có ý nghĩa. Tôi sẽ không chỉ cho rằng nó ổn hay không, đưa cho người quản lý hoặc dẫn dắt sự thật và để họ đưa ra quyết định, đó là những gì họ đang được trả nhiều tiền, cộng với một chút CYA.

Theo ý kiến ​​trung thực của tôi, một trong những điều tách biệt các nhà phát triển giỏi là khả năng thích ứng với công nghệ mới. Chúng ta đang sống trong một thế giới phát triển nhanh, nơi công nghệ hàng đầu ngày nay sẽ trở nên lỗi thời vào ngày mai. Do đó, một nhà phát triển không sẵn sàng thích nghi sẽ bị hạn chế sử dụng cho công ty. Điều này sẽ ổn thôi, nếu không phải vì một thực tế nhỏ rằng việc tìm kiếm và tuyển dụng những người giỏi thực sự rất khó thực hiện và khi một công ty tìm thấy viên ngọc của họ, họ sẽ lên kế hoạch lâu dài.

Tôi đã thấy các công ty tuyển dụng trong phạm vi công nghệ của họ và họ làm điều đó vì lý do chính xác như vậy. Họ muốn có được những nhà phát triển tuyệt vời, ngay cả khi điều đó có nghĩa là chờ đợi họ thích nghi với công nghệ mới.

Bây giờ đến tình huống của bạn. Là một người mới trong nhóm, tôi sẽ rất cẩn thận với những gì tôi nói và không nói với cấp trên. Chắc chắn, bạn sẽ thoát khỏi rất nhiều dựa trên giả định rằng bạn vẫn đang trong quá trình thích nghi với môi trường mới. Tuy nhiên, làm suy yếu thẩm quyền và sự kiên trì ngoan cố trong công nghệ ưa thích của bạn sẽ chỉ khiến cấp trên của bạn nghĩ rằng họ đã sai lầm khi thuê bạn và bạn không sẵn sàng rời khỏi vùng an toàn của bạn.

Những gì bạn sẽ chọn là tùy thuộc vào bạn, nhưng tôi sẽ đề nghị bạn cố gắng học công nghệ mới. Nó sẽ không đau, tôi hứa.

Tôi sẽ giả định rằng bạn đã trung thực trước cuộc phỏng vấn về sự thiếu hiểu biết về C # của bạn, bởi vì nếu bạn không thì bạn có thể đang ở một vị trí rất bấp bênh từ quan điểm pháp lý.

Lập trình viên giỏi biết lập trình. Mặc dù không ai rõ ràng có thể thành thạo tất cả các ngôn ngữ và khung, nhưng có một số điểm chung đáng kể giữa hầu hết chúng. Trừ khi bạn được yêu cầu làm việc trong một ngôn ngữ khác biệt lớn so với những gì tạo nên dòng chính ngày nay (ví dụ Lisp), thì một lập trình viên giỏi sẽ có thể thích nghi.

Tự nhiên có một đường cong học tập. Nếu nhà tuyển dụng thuê bạn thì họ phải tự tin vào khả năng của bạn để đi theo đường cong đó trong một khoảng thời gian hợp lý (một lần nữa, giả sử bạn đã trung thực lên phía trước về việc không biết C #). Ngôn ngữ C # vay mượn rất nhiều từ Java và nói chung, hầu hết các ngôn ngữ lập trình dựa trên lớp về cơ bản khá giống nhau (bạn đã đề cập đến node.js, được xây dựng trên ECMAScript, là ngôn ngữ dựa trên nguyên mẫu, vì vậy bạn rõ ràng là thoải mái với các mô hình lập trình khác.

Các lập trình viên giỏi, ngoài việc linh hoạt, háo hức học hỏi những điều mới. Trong phát triển phần mềm, bạn thường học hoặc trở nên không liên quan.

Tất nhiên, chủ nhân của bạn, giả sử họ biết bạn không biết C #, phải gặp bạn nửa chừng. Nếu bạn tỏ ra ham học hỏi thì họ phải cho bạn thời gian và nguồn lực để làm việc đó. Ném bạn vào tận cùng là không công bằng và căng thẳng không cần thiết. Bạn cần ngồi xuống và có một cuộc thảo luận bình tĩnh, hợp lý với cấp trên. Nếu họ muốn nó trong C # thì họ phải sẵn sàng chấp nhận rằng bạn sẽ tham gia vào quá trình học tập trong khi làm việc với nó và sẽ không công bằng khi họ áp đặt thời hạn chặt chẽ đối với bạn. Nếu thời hạn không linh hoạt và nếu chúng có tầm quan trọng chiến lược cao, thì chúng cần được chuẩn bị để cho phép bạn có một số vĩ độ để hoàn thành công việc trong thời hạn đó. Nếu họ cần ngôn ngữ được sử dụng phổ biến hơn trong văn phòng của họ, thì có lẽ bạn có thể yêu cầu triển khai ngay bây giờ trong những gì bạn ' quen thuộc với việc đáp ứng thời hạn, và sau đó khi dự án tiếp theo của bạn triển khai lại nó trong C # như một bài tập học tập và đưa phần mềm tuân thủ các yêu cầu bên trong một khi nó đáp ứng các yêu cầu bên ngoài. Giống như tôi đã nói, hầu hết các ngôn ngữ được sử dụng phổ biến hiện nay đều có nhiều điểm chung vì vậy nó chủ yếu đi vào chi tiết triển khai.

Bạn phải sẵn sàng chấp nhận sớm hay muộn rằng bạn đang làm việc trong một cửa hàng C # và do đó bạn cần phải có C # trong vành đai của mình.

Có lẽ họ không hài lòng với cách mọi người sử dụng MVC trong môi trường .NET. Có thể có quá nhiều đối xử với nó như các biểu mẫu web. Điều này không khác gì khi một người có nền tảng thủ tục bắt đầu trong OOP, đặt mọi thứ vào một lớp lớn và tiếp tục công việc như bình thường.

Dự án đầu tiên này không phải là tình huống lý tưởng bởi vì họ muốn điều này được thực hiện nhanh chóng. Tăng tốc độ trên .NET càng nhiều càng tốt và bắt đầu tạo ra các tính năng nhanh nhất có thể. Bạn sẽ không thích cách bạn làm mọi thứ, chỉ cần cố gắng ghi nhớ bạn sẽ bắt đầu cấu trúc lại công cụ này và áp dụng các kỹ năng của mình bằng ngôn ngữ khác.

Hy vọng rằng, cách bạn sử dụng MVC4 (giả sử mọi người khác không làm điều đó hoàn toàn đúng) theo kiểu Ruby hơn sẽ bắt kịp và phá vỡ mọi người khỏi tâm lý Webforms.