Быть ленивым разработчиком или не быть ленивым разработчиком? [закрытый]

Я думаю, что лучшие разработчики также самые ленивые. По сути, все, что вы делаете, должно быть сосредоточено на получении конечного результата с наименьшим объемом работы. Это часто обеспечивает наилучший результат, а также позволяет разработчикам не отвлекаться на интересные вещи, которые можно включить в проект. Ленивый разработчик, например, никогда не добавит пасхалку в свой код просто потому, что это будет больше кода, который может внести больше ошибок, которые нужно будет исправить позже. Добавление кода - это плохо, поскольку вы также добавите больше ошибок, которые вам нужно будет исправить позже. Тем не менее, вам нужно будет добавить код, иначе вам не заплатят. Итак, как ленивый разработчик вы, конечно, выберете наиболее оптимизированный код, лучше всего протестированный код, который почти никогда не даст сбоев, и вы будете работать таким образом, чтобы вероятность ошибок была сведена к минимуму.

Помните, что ленивые разработчики должны сосредоточиться на том, чтобы избегать работы в будущем, а не на том, чтобы избегать работы прямо сейчас! Так что прекратите читать и приступайте к работе! ; -)

Конечно, это зависит от того, что вы пишете. Я удивлен, что никто об этом не поднял. Если вы пишете драйверы устройств, операционные системы, протоколы или серверное программное обеспечение (веб-серверы, серверы, управляемые TCP и т. Д.), Вам, вероятно, следует делать это вручную.

Но с тем, что делаю я, и, вероятно, с тем, что многие из нас do - это реализация бизнес-процессов в коде для веб-страниц или веб-сервисов. И в этих областях, если вы можете улучшить свой код с помощью генераторов кода, дерзайте.

Программирование - это лень, автоматизация повторяющихся задач. Если вы не можете сделать это внутри своего языка, можно использовать генераторы кода и подобные вещи.

Думаю, это неправильный вопрос. Лень - это добродетель. Я видел слишком много программистов, которые делают что-то сложным, вместо того, чтобы сидеть сложа руки и несколько минут думать, чтобы найти более простой способ. У меня было так много раз, что я говорил младшему программисту что-то вроде: «Да, я уважаю ваше усердие в работе во время обеда и опоздании, чтобы написать код для X, но если бы вы приняли несколько минут, чтобы проверить документацию, вы могли заметить, что в библиотеке уже есть функция, которая это делает ». Или подобные истории.

Я не знаком с конкретными инструментами, которые вы описываете, но для меня всегда возникает вопрос: действительно ли этот инструмент спасает меня от работы? Я пробовал множество «генераторов кода», которые в основном просто создают заглушки кода. Так что, спасибо, вы написали «функцию x (int, float)», теперь все, что мне нужно, это заполнить фактические имена параметров и написать код. Что это меня спасло? Я также видел множество генераторов кода, которые пишут действительно ужасный код. Итак, теперь я должен попытаться добавить «собственный» код к этому беспорядку. Разве не было бы проще просто написать все чисто с первого раза? Я видел множество инструментов для повышения производительности, и я обнаружил, что на настройку параметров для запуска инструмента у меня уходит больше времени, чем я на самом деле сэкономил, используя его. (Как старая шутка о том, что было доказано, что регулярный бег трусцой действительно продлевает жизнь: каждые 60 минут, которые вы проводите, это добавляет 30 минут к вашей жизни.) Некоторые инструменты могут создавать код или структуры данных или что-то еще, что сложно поддерживать, Таким образом, вы сэкономите час сегодня, но это будет стоить вам десяти часов на обслуживание в течение всего срока проекта. И т.д.

Мой вывод заключается не в том, что вам не следует использовать инструменты повышения производительности, а в том, что вы должны убедиться, что они действительно повышают вашу продуктивность, а не просто создают иллюзию этого. Если в вашем случае вы обнаружите, что эти инструменты действительно вам помогают, то их использование не будет «мошенничеством», это просто разумно.

Да, вы ленивый разработчик, будьте честны с собой, если вы потратите время на то, чтобы сделать это тяжелым способом, вы можете назвать себя менее ленивым, чем сейчас.

Суть То есть ленивость вовсе не неэффективна. Ленивые люди тратят время на то, чтобы взглянуть на проблемы с разных сторон, прежде чем действовать, это позволяет избежать ненужных ошибок, что экономит ваше драгоценное время.

Итак, вы ленивы, но это нормально. Люди не нанимают гиперактивных программистов, которые делают по 10 приложений каждый день, но оставляют на своем пути след ошибок. исправление ошибок стоит времени, время - деньги.

заключение: Лень = прибыль

Дерзайте.

Спросите себя, почему существует так много ORM и других инструментов для генерации кода. Я бы посоветовал пойти на это с оговоркой, что вы оставите его обслуживаемым для следующего парня / девушки.

Я уверен, что есть пуристы, которые сказали бы все должно быть написано вами, чтобы вы знали, что все делает

Это могло быть жизнеспособной точкой зрения в первые дни программирования. Но в настоящее время это просто невозможно (или даже предпочтительнее). В конце концов, вы уже сократили определенный уровень понимания, просто используя язык высокого уровня.

Тем не менее, я обнаружил, что время от времени писать некоторые из этих вещей от руки - отличное учебное упражнение. Вы не только узнаете больше, но они научат вас, насколько эти инструменты действительно полезны (или нет). Обратите внимание, что я бы сделал это только для личного проекта. Я бы не стал

Я бы сказал, что вы более эффективны, чем ленивы.

Программирование - это в первую очередь упражнение на мышление, а не на набор текста. Пока вы понимаете, что делают инструменты, вы переключаете баланс с набора текста на мышление. Больше заниматься тем, чем занимается ваша работа? Мне не кажется, что ленивый!

Это не лень - это ум. Нет ничего плохого в том, чтобы использовать все имеющиеся в вашем распоряжении инструменты ... если они повышают вашу продуктивность. Использование инструментов ради использования инструментов - плохая идея.

Однако, если вы не знаете, что делает ваш инструмент под капотом, вы должны узнать об этом, поэтому, если у вас нет инструмента для некоторых причина, вы можете выполнить работу.

Оба эти инструмента, с моей точки зрения, не вызывают затруднений, поскольку они значительно улучшают производительность.

Это означает, что вы не ленитесь, вы используете соответствующие инструменты, позволяющие сосредоточиться по важным аспектам работы.

Для вас? Нет, вы не ленитесь.

Для парня, который не понимает, что делают генераторы кода и как они это делают? Да , это лень.

Это важное различие: вы должны знать, что вы получаете , и знать, что вы теряете, используя генератор кода. Если вы этого не сделаете, это лишь вопрос времени, когда вы столкнетесь с ситуацией, когда вы должны уметь создавать эти классы и не знать, как это сделать.

Как уже указали все, нет ничего плохого в использовании вами генераторов кода.

Тем не менее, я вижу недостатки и причины, по которым следует избегать этого в определенных ситуациях.

• выбор языка. . Иногда тот же факт, что вам нужен генератор кода для начала кодирования, может означать, что вы используете неправильный язык для задачи . В большинстве случаев язык действительно не может быть выбран, поэтому генераторы кода остаются лучшим решением.

• избыточность кода . В зависимости от фактических используемых генераторов, сгенерированный код может быть избыточным, если это произойдет и генерация произойдет один раз, не будет автоматизирована, а сгенерированный код попадет в основной репозиторий . Проблемы обслуживания могут возникнуть в течение длительного времени. запустить. На самом деле это не проблема с генерацией кода, но с тем, как его следует и не следует использовать

• добавление требований к платформам разработки . Мы должны признать, что многие программисты работают над тостерами, дублирующими функции ПК. Это действительно плохая (и печальная) реальность дешевой деловой практики, отвечающей острым умам. (острые умы тратятся впустую в процессе) Это может стать проблемой, если нашему проекту (который может иметь порт в запасе на будущее, а также во внешнем объекте) понадобится здоровенная, таранная, недостаточно кросс-платформенная, IDE удобно скомпилировать каждую маленькую модификацию.

Итак, нет окончательного ответа на код, генерирующий лень и программирование: это зависит от обстоятельств. С другой стороны, использование неправильных инструментов для работы вредно для вашего здоровья (и бизнеса), так что ... не делайте этого.

Мы должны признать, что многие программисты работают над тостерами, дублирующими функции ПК. Это действительно плохая (и печальная) реальность дешевой деловой практики, отвечающей острым умам. (острые умы тратятся впустую в процессе) Это может стать проблемой, если нашему проекту (который может иметь порт в запасе на будущее, а также на внешнем объекте) понадобится здоровенная, таранная, недостаточно кросс-платформенная, IDE удобно скомпилировать каждую маленькую модификацию.

Итак, нет окончательного ответа на код, генерирующий лень и программирование: это зависит от обстоятельств. С другой стороны, использование неправильных инструментов для работы вредно для вашего здоровья (и бизнеса), так что ... не надо.

Мы должны признать, что многие программисты работают над тостерами, дублирующими функции ПК. Это действительно плохая (и печальная) реальность дешевой деловой практики, отвечающей острым умам. (острые умы тратятся впустую в процессе) Это может стать проблемой, если нашему проекту (который может иметь порт в запасе на будущее, а также во внешнем объекте) понадобится здоровенная, таранная, недостаточно кросс-платформенная, IDE удобно скомпилировать каждую маленькую модификацию.

Итак, нет окончательного ответа на вопрос о ленивости кода и программировании: это зависит от обстоятельств. С другой стороны, использование неправильных инструментов для работы вредно для вашего здоровья (и бизнеса), так что ... не надо.

(острые умы тратятся впустую в процессе) Это может стать проблемой, если нашему проекту (который может иметь порт в запасе на будущее, а также во внешнем объекте) понадобится здоровенная, таранная, недостаточно кросс-платформенная, IDE удобно скомпилировать каждую маленькую модификацию.

Итак, нет окончательного ответа на вопрос о ленивости кода и программировании: это зависит от обстоятельств. С другой стороны, использование неправильных инструментов для работы вредно для вашего здоровья (и бизнеса), так что ... не надо.

(острые умы тратятся впустую в процессе) Это может стать проблемой, если нашему проекту (который может иметь порт в запасе на будущее, а также на внешнем объекте) понадобится здоровенная, таранная, недостаточно кросс-платформенная, IDE удобно скомпилировать каждую маленькую модификацию.

Итак, нет окончательного ответа на код, генерирующий лень и программирование: это зависит. С другой стороны, использование неправильных инструментов для работы вредно для вашего здоровья (и бизнеса), так что ... не надо.

Не нужно изобретать велосипед n раз, это делается достаточно часто. Вкратце, я бы сказал, что использование инструментов, подобных тем, что вы упомянули (в разумных пределах), абсолютно не проблема ...

Только лениво, если вы используете инструмент для создания кода и используете его как есть, не проверяя, соответствует ли код вашим потребностям и вашим стандартам.

Вы используете все карты в руке. Зачем изобретать велосипед, когда есть инструменты, облегчающие вашу работу. Имейте в виду, что эти инструменты НЕ выполняют вашу работу, они только помогают.

То, что вы создаете, зависит от вас, поэтому использовать инструменты не лениво ... это просто разумно.

Лень - это черта, которая присуща большинству хороших программистов. Если только они не работают в Adobe, в этом случае они часто ленивы в плохом смысле.