Какой метод программирования вы предпочитаете?Успех против.Свобода

Question

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

Answer 1

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

Answer 2

Цитата &; цитата свободы или ничего &; Отношение ювенильное и раздражающее, реальный мир так не работает.

Дайте мне установленный процесс.

Answer 3

Экономист.Если это приносит мне деньги и не является неэтичным, я полностью за это.

Answer 4

Зависит от того, умны ли вы.

Если ты умный, тогда свобода. Вы добьетесь успеха.

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

Answer 5

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

Следование за сложным неупругим процессом также может быть вредным.

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

Answer 6

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

Answer 7

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

Answer 8

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

С другой стороны, когда Амитабх Шривастава ввел некоторые базовые требования к анализу и тестированию для команды Windows, количество ошибок снизилось, и, по крайней мере, среди моих друзей в Microsoft, производительность и моральный дух выросли.Я предполагаю, что нечто подобное произошло в проекте KDE, когда они начали требовать от всех использования Валгринд.Внезапно больше нет ошибок памяти и непонятных дампов ядра.

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

Свобода для разработчиков — это совсем другой вопрос.Мне повезло: у меня есть работа, где я почти полностью свободен выбирать все, что касается моей среды разработки.(Пример:Я работаю в магазине Red Hat, но у меня был бюджет на покупку компьютера и установку Debian.) Поскольку у меня более 20 лет непрерывного опыта разработки программного обеспечения, я обычно могу сделать довольно хороший выбор относительно того, какие языки и инструменты использовать.Но обратная сторона этого в том, что я могу быть достаточно продуктивным на любом языке и в любой среде.Использование Perl или C++ может замедлить мою работу в 2 или 3 раза, а использование Lua или Haskell ускорит решение определенных задач, но в конце концов я доберусь до цели.

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

Я также видел, что ограничение разработчика конкретной средой или языком не является гарантией успеха.Я считаю себя очень плохим программистом на Perl;По сути, я отношусь к Perl как к awk на стероидах.Я полный идиот.И все же мне приходилось иметь дело с кодом Perl, написанным другими, который был намного хуже, чем все, что я мог написать, только потому, что они так и не научились думать о проблемах или о том, как организовывать код.

Думаю, мне лучше прекратить разглагольствовать.

Answer 9

Работа в больших группах учит ценности установленных документированных процессов.

Пока вы работаете в небольшой команде (2-4 человека), где вы хорошо всех знаете и у всех вас есть общая цель, вы, вероятно, сможете отлично работать без определенного процесса.

Как только 10 человек будут сотрудничать в чем-то, вам понадобятся хотя бы некоторые основные правила, чтобы все были на одной стороне.

Когда вы делаете проект со 100 людьми, вы никуда не добьетесь, если у вас нет очень определенных правил и четко определенного процесса.

Лично я предпочел бы, чтобы я мог делать все, что захочу, а все остальные работали в соответствии со строгим процессом; -)

Answer 10

Есть разные аспекты свободы. Когда вам запрещено изменять половину кодовой базы, потому что она уже & Quot; test & Quot; (даже если это плохо написано), я бы сказал, что в этом случае вам нужна свобода, но я не думаю, что вы об этом говорите.

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

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

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

Answer 11

Что если вы направите свою свободу на творчество в новые области проекта, а не на изобретение еще одного процесса разработки?

Answer 12

" Успех против свободы " подразумевает, что если вы свободны принимать решения, программа не будет успешной.

Я думаю, что вы действительно должны переосмыслить это. По моему опыту, разработчики должны БЕСПЛАТНО выбирать лучший способ реализации, если он лучше после проверки, чем & Quot; опробовано и протестировано & Quot; методы, то он будет сохранен и использован остальной частью команды. Но им все еще нужно убедиться, что код, который они пишут, УСПЕШЕН в выполнении задач, которые они призваны выполнять.

Answer 13

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

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

Answer 14

Вопрос о том, следует ли придерживаться общепринятой точки зрения или & думать нестандартно " был вокруг навсегда в большинстве дисциплин, а не только в программировании. Я думаю, что это должно быть решено в каждом конкретном случае.

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

Это было бы хорошо, если бы не было серьезных проблем в этой области. Многие (если не большинство) программ все еще слишком раздуты (ИМХО) и страдают от хронических проблем с производительностью. Вещи как они стабильны, но достаточно ли они хороши?

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

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

Answer 15

Разве это не зависит от того, что вы собираетесь построить в конце?

Эти ребята следуют установленным процессам: http://www.fastcompany.com/magazine /06/writestuff.html