2009-10-19 7 views
7

Tôi có phải là nhà phát triển lười biếng không? Có lười biếng khi sử dụng các công cụ tự động, chẳng hạn như trình tạo mã và như vậy không?Để trở thành một nhà phát triển lười biếng hoặc không phải là một nhà phát triển lười biếng?

Bây giờ, tôi có thể, nếu tôi phải tạo tất cả các lớp dữ liệu và thực thể tôi cần, nhưng tôi chọn sử dụng CodeSmith để tạo các trình dữ liệu và thực thể của mình. Tôi cũng sử dụng Resharper và tôi sẽ nói nó chiến đấu với MSDeploy như được cài đặt đầu tiên sau khi Visual Studio. Một lần nữa nếu tôi phải, tôi có thể viết mã mà không có nó, nhưng không thích.

Cả hai công cụ này từ quan điểm của tôi không có bộ não khi chúng cải thiện sản lượng ồ ạt.

Nhưng điều này có lười không? Tôi chắc chắn có những người theo chủ nghĩa thuần túy ở đó có thể nói mọi thứ nên được bạn làm quen để bạn biết mọi thứ đang làm gì, nhưng nếu bạn có thể đọc qua mã và xem điều gì đang xảy ra thì ok?

Vì vậy, tôi đang lười biếng hay tôi chỉ sử dụng tất cả các thẻ trong tay?

+5

Nếu lười biếng có nghĩa là hoàn thành công việc trước đó, vì vậy chúng tôi là hai. –

+1

Là lười biếng và hiệu quả là hai điều khác nhau. Tôi nghĩ tôi vừa hiệu quả vừa lười biếng! Tốt nhất của cả hai thế giới! –

+0

Tôi không nghĩ rằng bạn thực sự có một vấn đề hợp lệ. Bạn có một chủ đề mà bạn muốn suy ngẫm về, điều đó là tốt, nhưng điều đó có nghĩa là 'câu hỏi' này sẽ được đánh dấu là cộng đồng-wiki –

Trả lời

23

Trong lập trình viên, laziness is a virtue, vì vậy đừng lo lắng.

+1

Ít nhất, đó là cách biện minh cho nó để chúng ta có thể cảm thấy tốt hơn về bản thân mình;) – mpen

1

Bạn đang sử dụng tất cả các thẻ trong tay. Tại sao tái tạo lại bánh xe khi có các công cụ có sẵn để làm cho công việc của bạn dễ dàng hơn. Ghi nhớ những công cụ này KHÔNG làm công việc của bạn, họ chỉ hỗ trợ.

Điều bạn tạo ra là tùy thuộc vào bạn, do đó, sử dụng các công cụ không phải là lười ... nó chỉ là thông minh.

+1

Nhưng đồng thời đừng quên có các công cụ khác nhau cho cùng một công việc. (Tôi đã thấy mọi người mất 10 phút để thiết lập một cưa điện cho những gì sẽ mất 2 phút để làm với hack nhìn thấy ngồi trên băng ghế dự bị.) –

5

Bạn không cần phải phát minh lại bánh xe n lần, điều này được thực hiện thường xuyên đủ. Tôi xin nói ngắn gọn rằng việc sử dụng các công cụ như những công cụ mà bạn đã đề cập (trong vòng lý do) hoàn toàn không có vấn đề gì ...

1

Tôi muốn nói rằng bạn hiệu quả hơn là lười biếng.

+0

Sự lười biếng là những gì bạn nhận được khi bạn sử dụng máy phát điện mã để có hiệu quả, nhưng sử dụng thời gian được lưu vào vít xung quanh StackOverflow thay vì dành nhiều thời gian hơn cho một số khía cạnh khác của dự án mà bạn được thuê để thực hiện. Một giải thích khác về sự lười biếng: lười biếng là khi bạn sử dụng trình tạo mã, nhưng nó không hoàn toàn làm những gì bạn muốn để mọi người khác buộc phải hack xung quanh nó (tức là khi bạn sử dụng thứ gì đó không phải là công cụ phù hợp để tránh việc làm nó đúng.) –

11

Nó chỉ lười nếu bạn sử dụng một công cụ để tạo mã và sử dụng nó như là mà không xác minh rằng mã đáp ứng nhu cầu của bạn và tuân theo các tiêu chuẩn của bạn.

2

Cả hai công cụ này từ quan điểm của tôi không có bộ não khi chúng cải thiện sản lượng ồ ạt.

Điều này có nghĩa là bạn không lười biếng, bạn đang sử dụng các công cụ thích hợp để cho phép bạn tập trung vào các khía cạnh quan trọng của công việc.

2

Nó không phải là lười biếng - đó là thông minh. Không có gì sai khi sử dụng mọi công cụ theo ý của bạn ... miễn là nó làm cho bạn hiệu quả hơn. Sử dụng các công cụ vì lợi ích của việc sử dụng các công cụ là một ý tưởng tồi.

Tuy nhiên, nếu bạn không biết công cụ của mình đang làm gì dưới mui xe, bạn nên tìm hiểu về nó vì vậy nếu bạn không có sẵn công cụ vì lý do nào đó, bạn có thể hoàn thành công việc.

5

Đối với bạn? Không, bạn không lười biếng.

Đối với anh chàng đó không hiểu máy phát mã đang làm gì và cách họ thực hiện? , nó đang bị lười.

Đó là sự khác biệt quan trọng: Bạn phải biết những gì bạn nhận được biết những gì bạn đang thiếu bằng cách sử dụng trình tạo mã.Nếu bạn không làm vậy, đó chỉ là vấn đề thời gian trước khi bạn bắt gặp một trường hợp mà bạn phải có khả năng sản xuất những lớp đó và không biết làm thế nào.

+0

Điều đó có nghĩa là ai đó không biết làm thế nào một trình biên dịch hoạt động được lười biếng bằng cách sử dụng một? –

+0

@Matthew Whited Tôi nhận ra rằng bạn đang say mê; nhưng bạn nên nhận ra rằng có những người mù quáng sử dụng các công cụ mà không biết tại sao hoặc cách chúng hoạt động, và chúng trở thành một thiệt hại cho nhóm của họ. –

+1

Có những lập trình viên không biết cách trình biên dịch hoạt động như thế nào? Mua một cuốn sách, các bạn. Sheesh. –

0

Tôi chắc chắn có chủ nghĩa thuần túy ra khỏi đó mà sẽ nói tất cả mọi thứ nên được wirtten bởi bạn để bạn biết những gì tất cả mọi thứ đang làm

Điều này có thể đã là một điểm khả thi của xem trong những ngày đầu lập trình. Nhưng ngày nay, điều này chỉ đơn giản là không khả thi (hoặc thậm chí thích hợp hơn). Sau khi tất cả, bạn đã che khuất một mức độ hiểu biết nhất định chỉ bằng cách sử dụng một ngôn ngữ cấp cao.

Điều đó nói rằng, tôi đã nhận thấy đó là một bài tập học tập tuyệt vời để viết một số những điều này bằng tay đôi khi. Bạn không chỉ tìm hiểu thêm, mà còn dạy bạn những công cụ này hữu ích như thế nào (hoặc không). Lưu ý rằng tôi chỉ làm điều này trên một dự án cá nhân. Tôi sẽ không làm điều này cho bất kỳ dự án ai đó đã trả tiền cho tôi (trừ khi tôi đã làm việc cho một masochist hoặc một cái gì đó).

0

Tự hỏi tại sao có quá nhiều ORM và các công cụ tạo mã khác xung quanh. Tôi muốn nói với nó với điều kiện rằng bạn để nó duy trì cho chàng trai/cô gái tiếp theo.

0

Lập trình sắp trở nên lười biếng, về việc tự động hóa các tác vụ lặp đi lặp lại. Nếu bạn không thể làm điều đó bên trong ngôn ngữ của bạn, bằng cách sử dụng máy phát điện mã và những thứ tương tự là một cách giải quyết hữu ích.

2

Tôi nghĩ đó là câu hỏi sai. Sự lười biếng là một đức tính. Tôi đã nhìn thấy quá nhiều lập trình viên làm những việc khó khăn hơn là ngồi lại và suy nghĩ một vài phút để đến với một cách dễ dàng hơn. Tôi đã có rất nhiều lần tôi đã nói với một lập trình viên cơ sở về tác động của "Vâng, tôi tôn trọng sự tích cực của bạn khi làm việc qua bữa trưa và ở lại muộn để viết mã để làm X, nhưng nếu bạn đã một vài phút để kiểm tra tài liệu bạn có thể đã thấy rằng đã có một hàm trong thư viện thực hiện điều đó ". Hoặc những câu chuyện tương tự.

Tôi không quen thuộc với các công cụ cụ thể mà bạn mô tả, nhưng với tôi, câu hỏi luôn là, Công cụ này có thực sự tiết kiệm cho tôi bất kỳ công việc nào không? Tôi đã thử rất nhiều "máy tạo mã" mà về cơ bản chỉ cần tạo các đoạn mã. Vì vậy, gee, cảm ơn, bạn đã viết "hàm x (int, float)", bây giờ tất cả những gì tôi phải điền vào tên tham số thực tế và viết mã. Điều gì đã cứu tôi? Tôi cũng đã thấy rất nhiều trình tạo mã thực sự viết mã khủng khiếp. Vì vậy, bây giờ tôi phải cố gắng thêm mã "tùy chỉnh" vào mớ hỗn độn lộn xộn này. Nó sẽ không dễ dàng hơn để viết toàn bộ điều đó một cách sạch sẽ lần đầu tiên? Tôi đã nhìn thấy rất nhiều công cụ năng suất mà tôi thấy nó mất nhiều thời gian hơn để thiết lập các tham số để chạy công cụ hơn là tôi thực sự được lưu bằng cách sử dụng nó. (Giống như trò đùa cũ đã chứng minh rằng chạy bộ thường xuyên thực sự khiến bạn sống lâu hơn: cứ mỗi 60 phút bạn dành thời gian chạy bộ, nó sẽ thêm 30 phút vào cuộc sống của bạn.) Một số công cụ có thể tạo mã hoặc cấu trúc dữ liệu hoặc bất kỳ thứ gì khó duy trì, vì vậy bạn tiết kiệm một giờ ngày hôm nay nhưng nó chi phí bạn mười giờ trong bảo trì trong suốt cuộc đời của dự án. Kết quả của tôi không phải là bạn không nên sử dụng các công cụ năng suất, mà đúng hơn là bạn nên đảm bảo rằng họ thực sự đang tăng năng suất của bạn, chứ không phải chỉ là một ảo ảnh về việc làm như vậy. Nếu trong trường hợp của bạn, bạn tìm thấy những công cụ này thực sự giúp bạn, sau đó sử dụng chúng không phải là "gian lận", nó chỉ đơn giản là thông minh.

+0

Phản hồi rất tốt! –

0

Tùy thuộc vào những gì bạn đang viết, tất nhiên. Tôi ngạc nhiên là không ai mang cái này lên. Nếu bạn đang viết trình điều khiển thiết bị, hệ điều hành, giao thức hoặc phần mềm máy chủ (máy chủ web, máy chủ định hướng tcp, v.v.), bạn có thể làm điều đó bằng tay.

Nhưng với những gì tôi làm và có lẽ điều mà nhiều người trong chúng ta làm là triển khai quy trình kinh doanh theo mã cho các trang web hoặc dịch vụ web. Và trong những lĩnh vực đó, nếu bạn có thể cải thiện mã của mình bằng các trình tạo mã, hãy thực hiện nó.

0

Có bạn đang là một nhà phát triển lười biếng, hãy thành thật với chính mình, nếu bạn dành thời gian để làm điều đó một cách khó khăn, bạn có thể gọi bản thân mình ít lười hơn bạn bây giờ.

Vấn đề là, lười biếng không hiệu quả chút nào. Những người lười biếng dành thời gian để xem xét các vấn đề từ hướng khác nhau trước khi hành động theo nó, điều này tránh được những lỗi không cần thiết giúp bạn tiết kiệm thời gian quý báu.

Vì vậy, bạn đang lười biếng, nhưng không sao. Mọi người không thuê các lập trình viên năng động làm 10 ứng dụng mỗi ngày nhưng để lại một dấu vết lỗi trên con đường của họ. chi phí sửa lỗi, thời gian là tiền bạc.

kết luận: Laziness = profit

.

0

Tôi nghĩ rằng các nhà phát triển tốt nhất cũng là người lười nhất. Về cơ bản, tất cả những gì bạn đang làm nên tập trung vào kết quả cuối cùng với số lượng công việc ít nhất. Điều này thường mang lại kết quả tốt nhất và tránh các nhà phát triển bị phân tâm bởi những điều thú vị để đưa vào dự án. Một nhà phát triển lười biếng, ví dụ: không bao giờ thêm một quả trứng phục sinh vào mã của mình, đơn giản bởi vì đây sẽ là mã nhiều hơn, có thể giới thiệu thêm nhiều lỗi cần được khắc phục sau này. Thêm mã là xấu, vì bạn cũng sẽ thêm nhiều lỗi mà bạn cần phải giải quyết sau. Tuy nhiên, bạn sẽ cần thêm mã, nếu không bạn sẽ không được thanh toán. Vì vậy, với tư cách là một nhà phát triển lười biếng, dĩ nhiên bạn sẽ chọn mã tối ưu nhất, mã được thử nghiệm tốt nhất mà hầu như không bao giờ thất bại và bạn làm việc theo cách mà cơ hội của các lỗi được giảm đến mức tối thiểu.

Hãy nhớ rằng các nhà phát triển lười biếng nên tập trung vào việc tránh làm việc trong tương lai, chứ không phải tránh việc ngay bây giờ! Vì vậy, dừng đọc ở đây và trở lại làm việc! ;-)

2

Vì mọi người khác đã chỉ ra không có gì sai trong việc bạn sử dụng trình tạo mã.

Tôi vẫn có thể thấy những nhược điểm và lý do để tránh điều đó trong một số vị trí cụ thể nhất định.

  • lựa chọn ngôn ngữ. Đôi khi thực tế rất giống bạn cần một trình tạo mã để mã hóa của bạn bắt đầu có thể ngụ ý bạn đang sử dụng ngôn ngữ sai cho nhiệm vụ. Hầu hết các ngôn ngữ không thể thực sự được chọn, do đó, các trình tạo mã vẫn là cách tốt nhất để đi.

  • mã dự phòng. Tùy thuộc vào các máy phát điện thực tế được sử dụng, mã được tạo có thể thừa, nếu điều này xảy ra và thế hệ xảy ra một lần, không tự động và mã được tạo được chuyển vào kho lưu trữ chínhvấn đề bảo trì có thể phát sinh trong thời gian dài. Không thực sự là một vấn đề với việc tạo mã, nhưng với cách nó nên và không nên được sử dụng.

  • thêm yêu cầu nền tảng phát triển. Chúng ta phải thừa nhận nhiều lập trình viên làm việc trên máy nướng bánh mì tăng gấp đôi như máy tính cá nhân. Nó thực sự là một thực tế xấu, (và buồn) của thực hành kinh doanh giá rẻ đáp ứng tâm trí sắc nét. Nó có thể trở thành một mối quan tâm nếu dự án của chúng tôi (có thể có một cổng trong cửa hàng cho tương lai, và trong một cơ sở bên ngoài hoặc) cần một đống, ram hogging, không đủ nền tảng, IDE tiện dụng để biên dịch mọi sửa đổi nhỏ.

Vì vậy, không có câu trả lời dứt khoát về mã tạo ra sự lười biếng và lập trình: nó phụ thuộc. Sau đó, một lần nữa, bằng cách sử dụng các công cụ sai cho công việc là xấu cho sức khỏe của bạn, (và kinh doanh) vì vậy ... không.

1

Lập trình chủ yếu là một bài tập suy nghĩ không phải là bài tập đánh máy. Vì vậy, miễn là bạn hiểu những gì các công cụ đang làm bạn đang chuyển số dư ra khỏi đánh máy để suy nghĩ. Làm nhiều hơn về công việc của bạn là gì? Nghe có vẻ lười biếng với tôi!