Вы предпочли бы иметь полную полную свободу во всех ваших методах разработки или лучше придерживаться более безопасного, более скучного подхода, который имеет значительно больше шансов на работу в конце? Хакер против инженера? Художник против электрика?Какой метод программирования вы предпочитаете? Успех и свобода
Мне нравится делать все. Это означает использование установленных инструментов разработки и разумный процесс, одновременно творческий подход к тому, что я делаю в рамках этого процесса. Величайшая поэзия на английском языке была написана на строгие правила метрики и рифмы и, тем не менее, была для нее творческой.
Отношение «свобода или ничего» является несовершеннолетним и раздражающим, настоящий мир не работает таким образом.
Дайте мне установленный процесс.
Экономист. Если это делает меня деньгами и не является неэтичным, я все для этого.
Лично я предпочитаю свободу, чтобы попробовать новые идеи, новые технологии, новые процессы, но я думаю, что это должно быть саморегулирующимся. То есть, я думаю, что методы, процессы и т. Д. Должны оказаться полезными. Требование свободы личного выражения в командной среде, вероятно, не является хорошим способом создания команды, но я думаю, что команда должна быть открыта для совершенствования с помощью новых идей. Однако, как только процесс/методика была принята командой, было бы контрпродуктивно продолжать настаивать на своем собственном пути (даже если лучше), если команда не увидит его так же, как вы.
Зависит, если вы умны.
Если вы умны, то свобода. Вы сделаете свой собственный успех.
Но проблема в том, что никто не может честно сказать, насколько они умны.
Работая в больших группах, преподаваемыми знаками установленных, документированных процессов.
До тех пор, пока вы работаете в небольшой команде (2-4 человека), где вы хорошо знаете всех, и у вас есть общая цель, вы, вероятно, можете работать отлично, не имея определенного процесса.
Как только 10 человек должны что-то сотрудничать, вам понадобятся хотя бы некоторые основные правила, чтобы все были на одной стороне.
Когда вы выполняете проект со 100 людьми, вы не получите нигде, если у вас нет особых правил и четко определенного процесса.
Лично я предпочел бы, если бы я мог делать все, что мне нравится, и все остальные работали в соответствии со строгим процессом ;-)
Существуют различные аспекты свободы. Когда вам запрещено изменять половину кода, потому что он уже «проверен» (даже если он плохо кодирован), я бы сказал, что это случай, когда вам нужна свобода, но я не думаю, что вы об этом говорите.
Хакерский стиль свободы, чтобы использовать любые инструменты, необходимые для решения проблемы, и решение проблемы в качестве основной цели просто пугает меня в эти дни.
Я никогда не видел кода, который в какой-то момент не нуждался в отладке/исправлении, и для отладки/исправления всегда, кажется, требуется больше времени, чем начальная кодировка, поэтому первый раунд отладки/обслуживания/улучшения насколько это возможно, ваша основная цель.
Это противоречит «Свободе», потому что «Свобода» часто подразумевает, что вы можете выбирать механизмы, которые потребуют от других людей больше времени, - и это, скорее всего, другие люди, которые будут выполнять этот первый раунд обслуживания.
Я не думаю, что свобода против скуки действительна.Определенный легкий процесс, который также является гибким, безусловно выполним. Пока кто-то не сможет показать мне, что они умеют развиваться, я, вероятно, не допущу так много свободы.
Следуя за неуравновешенным неупругим процессам, также может быть вредным.
Необходимо много здравого смысла, но это сложная вещь, и все это зависит от разработчиков и организаций. Нет ни одного размера.
Что делать, если вы хотите, чтобы ваша свобода стала творческой в новых проектных областях, а не придумала еще один процесс разработки?
Это недопустимый вопрос. Вы можете проявлять свою свободу, чтобы следовать процессу, или вы можете использовать свою свободу, чтобы не следовать процессу. Независимо от того, следуете ли вы процессу или нет, у вас все еще есть свобода.
«Успех против свободы» подразумевает, что если вы свободны принимать решения, программа не будет успешной.
Думаю, вам действительно нужно переосмыслить это. По моему опыту, разработчикам необходимо быть БЕСПЛАТНЫМ, чтобы выбрать лучший способ реализации, если после обзора лучше, чем «проверенные и проверенные» методы, он будет храниться и использоваться остальной частью команды. Но они все равно должны обеспечить, чтобы код, который они пишут, УСПЕШНО выполнял задачи, которые они должны выполнять.
«Свобода» в данном случае просто кажется эмоционально положительным словом, связанным с неприятной концепцией. Его можно так же легко заменить «упрямством» или «небрежностью». Даже сам вопрос формулируется как «то, что я хочу делать», и «что может сработать».
Конечно, любой человек может свободно выбирать любой путь. Но я лично не буду посвящать минуту своей жизни тому, что меня не волнует, и если бы я позаботился об этом, я сделал бы все, что мог, чтобы максимизировать шансы на успех. Я не вижу этого как «ограничительного» вообще.
Это ложная дихотомия. Наложенный процесс не коррелирует с успехом. Например, в телефонных компаниях существует огромное количество процессов, наложенных на разработчиков программного обеспечения (наивное чтение «развития водопада») с тем, что много времени тратится впустую, написание подробных проектных документов, а затем, когда программное обеспечение доставляется клиентам внезапно узнайте, что то, что они просили, не то, что они хотели. В этот момент ресурсы почти исчерпаны, и все проигрывают. Наложенный процесс убивает проекты.
С другой стороны, когда Amitabh Srivastava ввел некоторые базовые требования к анализу и тестированию в команде Windows, уровень ошибок снизился и, по крайней мере, среди моих друзей в Microsoft, повысилась производительность и моральный дух. Я предполагаю, что что-то подобное произошло в проекте KDE, когда они начали требовать, чтобы все использовали valgrind. Внезапно, больше ошибок памяти и непонятных отвалов ядра.
В общем, я думаю, что это более успешно вводить полезные инструменты чем вводить процессы. Доказательства для или против полезности инструмента могут накапливаться довольно быстро. Единственный «процесс», который я видел, последовательно успешный, состоит в том, что более чем одна пара глаз должна видеть код. Механизм, с помощью которого этот просмотр достигается, не имеет значения.
Свобода для разработчиков - это совсем другой вопрос. Мне повезло, что у меня есть работа, где у меня есть почти полная свобода выбора всего, что касается моей среды разработки. (Пример: я работаю в магазине Red Hat, но у меня был бюджет, чтобы купить компьютер и установить Debian.) Поскольку у меня есть более чем 20-летний опыт разработки программного обеспечения, я обычно могу сделать довольно хороший выбор о том, какие языки и инструменты использовать. Но обратная сторона этого заключается в том, что я могу быть достаточно продуктивным на любом языке или в среде. Использование perl или C++ может замедлить меня в 2 или 3 раза, и использование Lua или Haskell ускорит меня для определенных проблем, но я доберусь туда в конце.
Но я работал с другими разработчиками, которые имеют очень ограниченную зону комфорта, насколько это касается языков и инструментов, и кто будет болеть за неправильный инструмент для работы, если ему предоставляется свобода. Меня как-то попросили в качестве консультанта попытаться помочь группе ускорить компилятор, который занимался 24 часами, чтобы скомпилировать небольшие программы. Оказывается, люди, написавшие это, были людьми экспертной системы, и они написали компилятор, используя механизм вывода на основе правил. Они заставили его работать, но это была неправильная технология для работы.
Я также видел, что сдерживание разработчика в конкретной среде или языке не является гарантией успеха. Я считаю себя очень плохим программистом perl; Я в основном рассматриваю perl как awk на стероидах. Я полный идиот. И все же мне приходилось иметь дело с perl-кодом, написанным другими, что было намного хуже, чем все, что я мог писать, потому что они никогда не научились думать о проблемах или о том, как организовать код.
Думаю, мне лучше прекратить разглагольствовать.
Вопрос о том, придерживаться общепринятой мудрости или «мыслить за пределами поля», существует вечно в большинстве дисциплин, а не только в программировании. Я думаю, что это нужно решать в каждом конкретном случае.
Я был на конференциях, где наиболее популярными документами, по-видимому, являются углубленные анализы вещей, как они есть. В отличие от SO, где популярны идеи.
Это было бы нормально, если бы не было серьезных проблем в этой области. Многое (если не большинство) программное обеспечение все еще слишком раздуто (IMHO) и страдает хроническими проблемами с производительностью. Вещи-как-они-являются стабильными, но являются ли они достаточно хорошими?
Я думаю, нам нужны новые идеи, и они неизбежно будут непопулярными, нетрадиционными и рискованными.
Я рад, что SO разрешает обсуждать нестандартные идеи, а не как пламя, а как способы подвергнуть сомнению статус-кво.
Не зависит ли это от того, что вы собираетесь построить в конце?
Эти ребята следуют установленным процессам: http://www.fastcompany.com/magazine/06/writestuff.html
Закрыто. Я думаю, что это правильный вопрос. – tvanfosson 2008-12-04 21:50:19
Я не закрою его, но из FAQ «Реальные вопросы ожидают факты, а не мнения как ответы». – EBGreen 2008-12-04 21:52:12
Согласен, что это может быть лучше сформулировано. Я думаю (надеюсь), что ему действительно интересно узнать, как работают успешные разработчики. Я видел более вопиющие нарушения этого конкретного пункта FAQ. – tvanfosson 2008-12-04 21:55:30