Как стать «более быстрым» программистом?

142

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

У кого-нибудь есть советы или рекомендации о том, что они делают, чтобы увеличить скорость своей продукции, не жертвуя ее качеством?

Как вы оцениваете сроки и придерживаетесь их? Что вы делаете, чтобы сделать больше за более короткие промежутки времени?

Любая обратная связь с благодарностью, спасибо,

Ник Готч
источник
96
Тратьте меньше времени на SO на работе, если вы это делаете.
Сан Хасинто
52
Если вы читаете это, уже слишком поздно
32
Я читаю «Как стать толстым программистом». Сделал меня смех
Marcgg
13
Я хотел бы задать вам дополнительный вопрос. Является ли ваше желание быть «более быстрым программистом» результатом вашей собственной низкой производительности (AKA, вам нужно оттачивать свои навыки, вам нужно сосредоточиться и устранять отвлекающие факторы (такие как SO) и т. Д.), Или плохое планирование со стороны разработки точка зрения (AKA, вам дали 1 неделю, чтобы сделать то, что любой здравомыслящий человек знал бы, заняло бы 1 месяц). Каждый элемент имеет очень разные решения.
3
Нет единственно правильного ответа, поэтому включите его в вики-вопрос сообщества или оставьте вопрос закрытым для вас.
Donal Fellows

Ответы:

190

Выключи компьютер. Возьмите карандаш и немного бумаги. Сделайте набросок вашего дизайна. Рассмотрите это со своими пэрами. Затем напишите код.

gatorfax
источник
9
ИЛИ вы можете оставить свой компьютер
включенным
208
Карандаш, бумага или доска быстрее, чем большинство приложений, которые я использовал.
Томас Оуэнс
24
Делать это на бумаге фокусирует ум.
100
Почему я не могу понизить комментарий к Visio? Отказ от использования Visio - это определенный способ ускорить разработку!
52
Тьфу .... Визио. Каждый раз, когда меня просят «использовать Visio в вашем проектном документе», я сначала делаю набросок на бумаге, а затем провожу следующие два дня, борясь за то, чтобы все строки в Visio были правильными.
Роберт Фрейзер
149

Некоторые идеи...

  • Избегайте позолоты - делайте только то, что от вас требуется (с точки зрения требований)
  • Понять бизнес-требования и сделать это правильно с первого раза
  • Тщательно понимайте свою среду и инструменты
  • Станьте фантастической машинисткой, используйте вместо мыши сочетания клавиш
  • Используйте итеративный подход и встроите проверки работоспособности, чтобы убедиться, что вы на правильном пути
  • Не изобретайте велосипед, рассмотрите возможность повторного использования прошлой работы и работы других
  • Устраняйте отвлекающие факторы, не проверяйте электронную почту, не смотрите снаружи, не разговаривайте с коллегами и т. Д.
  • Не переутомляйтесь - узнайте, когда вам нужно сделать перерыв
Майо
источник
7
+1 за не изобретать велосипед. Научитесь создавать код многократного использования, который может быть подключен к другому коду и работать без переписывания. (напр .: функции с параметрами вместо жесткого кодирования)
34
+1 за «избегать позолоты» - это было причиной того, что я пропустил слишком много сроков из-за моих перфекционистских / анально-сохраняющих тенденций.
Дина
7
Набор текста - важный момент. Всегда удивляюсь количеству встречающихся мной кодеров, которые не научились печатать ...
Пэдди,
2
+1 устранение отвлекающих факторов. На мой взгляд, они являются основными пожирателями времени.
2
+1 за советы по микро-улучшению (вместо макро-улучшений с точки зрения планирования проектов).
132

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

Вы (и ваша команда) делаете одну из следующих ошибок (или все они):

  • недооценка работы, которую необходимо выполнить;
  • при планировании пропускаются большие требования или элементы архитектуры;
  • путать оценки работы с календарными оценками и не учитывать такие вещи, как встречи / телефон / другие накладные расходы;

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

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

Франци Пенов
источник
47
Некоторые разработчики действительно слишком медленные. Это может быть проблемой.
12
Да, это может быть проблемой, но это личная проблема. Это никогда не должно становиться проектом или проблемой команды. Другими словами, это может повлиять на карьеру, но это никогда не должно влиять на график проекта.
Франси Пенов
12
«не доставить вовремя не означает, что вы медлительны, это означает, что проект был спланирован плохо» - это текстовое описание недопустимого аргумента. Есть много других причин, по которым вы можете не успеть вовремя, одна из которых может быть связана с медлительностью.
плоть
15
@flesh - если вы знаете, что вы медлительны, почему бы вам не планировать свое расписание с учетом этого факта? Другими словами, если вы знаете, что не можете бежать так же быстро, как Усэйн Болт, планируете ли вы пробежать 100 м за 9,7 с?
Франси Пенов
5
@ Kibbee - в этой ситуации вы сокращаете особенности. Вы не можете обещать выполнять определенную работу в определенное время, когда знаете, что это невозможно, и надеетесь на чудо.
Франси Пенов
89

Действительно, действительно выучи свой редактор. Если вы используете IDE, убедитесь, что вы используете все функции, которые он предлагает. Получить шпаргалку, чтобы узнать сочетания клавиш для вашего редактора по вашему выбору. Если вы используете оболочку, установите ярлыки для часто используемых каталогов

slashnick
источник
3
Иногда это действительно может резко повысить производительность
шоу
6
Написание реального кода - это только часть работы разработчика. Тратить время на изучение IDE до совершенства - это точка оптимизации; и вы знаете, что они говорят об оптимизации, не так ли? - «Сначала измерить, а затем оптимизировать узкие места».
Франси Пенов
1
Я не вижу этого вообще. Если я сбиваю 50% времени на печатание, сколько времени это спасет меня за день? Исходя из моего опыта, я трачу большую часть времени на размышления о / тестировании / оценке / незначительном изменении / и т.д. кода, по сравнению с фактическим написанием его, я думаю, что это в конечном итоге не будет большой победой.
4
Это делает навигацию по IDE чем-то, что вы делаете, не задумываясь. Все, что требует каких-либо значительных усилий, например, переход к маленькой серой кнопке, отмеченной тем или иным рядом с остальными маленькими серыми кнопками, замедляет вас, прерывая ваше мышление. Наличие ctrl-n под кончиками пальцев без каких-либо движений - это главный чистый выигрыш.
Пол Макмиллан
5
В том же духе: изучите общие «горячие» клавиши. Например, во многих программах Windows ... Копировать: Ctrl + c Вырезать: Ctrl + x («x» выглядит как открытая пара ножниц) Вставить: Ctrl + v (прямо рядом с «c» и «x» выше) Перейти к началу строки: Home Перейти к концу строки: End Переместить курсор по слову (не символу): [Shift] + Ctrl + влево или вправо Перейти к началу документа: Ctrl + Home Перейти к концу документа: Ctrl + End и т. д.
38

«Есть ли у кого-нибудь советы или рекомендации о том, что они делают, чтобы увеличить скорость своей продукции, не жертвуя ее качеством?»

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

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

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

Я слышал, что многие люди говорят мне, что «ожидает» клиент. Это плохая политика.

Постройте самую простую вещь. Если клиент требует больше, строить больше. Но сначала постройте самую простую вещь.

С. Лотт
источник
«Многие, многие люди стремятся к« высочайшему »качеству за счет чего-то, что (а) просто, (б) надежно и (в) правильно». Вы могли бы оставить это при этом, и я бы проголосовал за это.
corymathews
«Упрости, упрости». ~ Генри Дэвид Торо
2
Да ... это также означает преждевременную абстракцию. Если что-то будет иметь только одну реализацию, не делайте это интерфейсом.
Роберт Фрейзер
3
Одна из моих любимых цитат уместна в этой ситуации: «Сделай что-нибудь как можно более простым, но не проще» ~ перефразируя, Альберт Эйнштейн
Неми
Проще говоря, это то, что даже многие программисты не получают должным образом: они легко попадают в ловушку «преждевременная оптимизация - корень всех зол». Обычно самая простая программа - самая быстрая или самая качественная.
32

Избегайте полировки вашего кода до совершенства, просто сделайте так, чтобы он работал. Это то, что ожидает бизнес.

Но часто увеличение скорости подразумевает потерю качества.

user8685
источник
10
Я бы предложил "заставить это работать", и если время позволяет обойтись без него, то совершенствуюсь!
Улицы
28
-1: нет причин жертвовать качеством. Вы всегда можете пожертвовать функциями.
С.Лотт
6
Я видел, как это происходило неоднократно. Разработчики зацикливаются на последнем 1% данной функции, а затем играют в догонялки и отстают при попытке завершить оставшиеся функции. Сначала выполните то, что от вас ожидается, затем вернитесь и отполируйте.
3
Часто повышение качества подразумевает увеличение скорости. Если вы потратите немного времени на то, чтобы сделать все правильно, вы можете сэкономить больше времени на тестировании и отладке.
Дэвид Торнли
2
Если вы застряли в одной функции, работайте над чем-то другим.
29

Повторное использование - я пытаюсь учесть любые умные биты из предыдущих проектов, чтобы я мог использовать их снова в будущих предприятиях. Всегда стоит спросить себя: "Могу ли я снова использовать это когда-нибудь?"

Фил Дженкинс
источник
Идеальное состояние ума для более быстрого программирования в долгосрочной перспективе, хотя сначала это может занять больше времени.
8
+1: Остерегайтесь, однако, я поймал себя на том, что обобщаю и абстрагирую что-то, чтобы я мог использовать это снова в другой день ... и пропустил крайний срок этого дня или удвоил время, которое ошибка должна была принять, чтобы исправить ... так, чтобы я мог «возможно» сэкономить время позже.
Стивен Эверс
2
Наличие "мешка с уловками" является ключевым. Если это становится проблемой для вас, стоит потратить некоторое время на разработку многократно используемых частей (при условии, что домен, в котором вы работаете, пригоден для повторного использования кода).
24

Будь проще.

Если вы используете TDD, вы должны следовать « красный, зеленый, рефакторинг »:

  1. Напишите провальный тест ( красный ). (Часто для функциональности ваш код еще не имеет.)
  2. Совершите ужасные кодовые преступления, чтобы сдать ваши тесты ( зеленый ). Жесткий код при необходимости.
  3. Рефакторинг , возможно, ненадолго сломал тесты, но в целом улучшил дизайн.
bryanbcook
источник
3
При выполнении TDD у вас есть тестовый бегун, который выдает красный / зеленый отчет за тест, чтобы указать, прошли ли они.
2
@Konstantin: Написание некоторого кода с использованием TDD может занять больше времени на 20%, но это также дает лучший код, и в долгосрочной перспективе, когда система растет, скорость внесения изменений остается примерно одинаковой. TDD помогает вам избежать технического долга, который замедляет работу.
3
Печатание никогда не было медленной частью программирования. Даже если вам нужно больше печатать с помощью TDD, это не замедляет работу. Это может даже ускорить вас, потому что написание теста сначала поможет вам сосредоточиться на том, что необходимо, прежде чем думать о том, как его реализовать.
1
Если руководство не понимает какую-то ключевую концепцию, вам следует объяснить это им. Например, martinfowler.com/bliki/TechnicalDebt.html
3
@Konstantin, если вы считаете "разработку" актом написания кода, я бы с вами согласился. Однако, если вы считаете, что «разработка» включает в себя упаковку, подготовку заметок о сборке, развертывание, тестирование, создание отчетов о дефектах, анализ и определение приоритетов дефектов, назначение задач, расследование, отладку и исправление, а также повторный запуск процесса - тогда 15 минут до Напишите, что модульный тест перевешивает дни и потери доверия клиентов в 1000 раз.
22

Загрузите всю документацию по языкам / библиотекам локально на свой компьютер, затем отключите сетевой кабель / выключите Wi-Fi .

Не пытаться быть смешным здесь. Это действительно помогает мне!

mcjabberz
источник
Я делаю то же самое.
Электронная документация и поиск неисправностей так или иначе переоценены.
Установите брандмауэр и настройте его так, чтобы он блокировал практически весь веб-доступ (у меня есть исключения для нескольких доменов, например, MSDN)
finnw
Я действительно рассматриваю возможность сделать это (факт, что я оставляю этот комментарий достаточно доказательств)
Ikke
И потерять ТАК? черт возьми, нет
20

Обратите внимание, что вы слишком долго читаете переполнение стека. Оправдание компиляции работает только так долго. :)

Мэтью Джонс
источник
15
Зависит от того, насколько быстро работает ваш компилятор. Так что, может быть, «решение» - найти более медленный компилятор и запустить его на Pentium 2 с 128 МБ памяти? :-)
Франци Пенов
@Franci, возможно даже помещая место подкачки на дискету. Или два в RAID.
20

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

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

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

Uri
источник
Это не будет работать, если у вас есть начальник, который ожидает ответов на электронные письма в течение 10 минут.
finnw
Это на самом деле очень актуально. Насколько это возможно, не позволяйте себе стать жертвой эгоистичных захватчиков внимания и придерживаться своей первоначальной задачи. Если вы позволяете себе тянуться в разные стороны, конечным результатом является то, что вы ничего не достигаете, а не чего-то.
AndyUK
14

Делай это правильно, лучшим образом, в первый раз. Если это означает, что вы должны остановиться и немного подумать, прежде чем начать, то сделайте это. Работает 90% времени.

CK01
источник
2
+1 Это так верно. Это не значит, что вы должны быть «идеальными»; все мы будем делать ошибки. Но если мы сделаем все как можно лучше с первого раза, последствия этих ошибок будут намного меньше.
+1 - Кажется, я вспомнил, что читал где-то, что разница между хорошими программистами и плохими программистами не в скорости. Разница в том, что хорошие программисты будут хранить больше своего кода.
Джейсон Бейкер
Это мой девиз, делай это правильно, с первого раза. Не имейте привычки всегда возвращаться и исправлять свой код, потому что вы не сделали это правильно в соответствии со спецификациями.
«Если у вас нет времени, чтобы сделать это правильно, как у вас будет время, чтобы сделать это снова?»
Алекс Фейнман
Вам может понадобиться опыт от фактического программного обеспечения , чтобы быть в состоянии определить , что является лучшим способом. В этом случае вы не можете сделать это правильно с первого раза.
14

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

Эй Джей Джонсон
источник
2
Это хороший бонус ... но я не думаю, что он будет иметь большое влияние в целом. Ввод кода, вероятно, является наименее трудоемкой частью. (Да, я следовал и прочитал ссылку. Я просто не согласен с ним.)
Если ограничивающим фактором вашего кодирования является то, насколько быстро вы набираете материал, вы, вероятно, работаете на неправильном уровне абстракции.
Пит Киркхем,
+1. Отличная ссылка, отличная статья для тех, кто дочитал ее до конца;) Я хорошо печатал, но это вдохновило меня на переключение на раскладку клавиатуры Программиста Дворжака en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard (но я переключил «» и -_ клавиш с Microsoft Keyboard Layout Creator), и я уверен, что скоро я буду печатать намного быстрее :) Смотрите также: typematrix.com/dvorak
Роман Бойко
12

Практика и тяжелая работа.

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

Если вы хотите улучшить какой-то конкретный навык, это также может помочь в разработке упражнений, которые позволят вам работать именно над этим. Если ваша медлительность находится на этапе проектирования, попробуйте найти проблемы с дизайном для работы в Интернете. Повторяя одно и то же упражнение, вы сможете выполнять его быстрее и практиковаться в скорости. Мне лично нравятся упражнения алгоритма TopCoder для отработки скорости программирования. У них тоже есть проблемы с дизайном, но я их не пробовал.

DisplacedAussie
источник
Практика часто недооценивается в программировании. Это должен был быть один из 5 лучших ответов.
Ух ты. Не уверен, почему это не выше, либо. Я действительно никогда не пробовал это. Я сделаю это!
Дэвид
11

Узнайте о Зоне, узнайте, как попасть в нее, и узнайте, как распознать, когда вас нет в ней.

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

Цитата из того, что уловки, которые Вы используете, чтобы получить себя в зоне

Дастин Гетц
источник
И пропустите обед, если вы находитесь в зоне ... или опоздаете ... ММмммм Зона. слюни
10

Знание своей IDE и структуры хорошо. Обращение к Google для каждой мелочи требует времени.

Майк Холл
источник
Но также важно понимать, когда вам нужен Google, и уметь быстро это делать.
9

Emacs

ZeroCool
источник
1
Пожалуйста, отредактируйте это, чтобы я мог объявить это, в настоящее время оно "слишком старое".
Kmarsh
1
Сильно зависит от того, что вам нужно использовать для этого, хотя.
8

Прежде чем начать разработку:

  • Выйти из своего почтового ящика
  • Отключить любые клиенты IM
  • Вежливо попросите сверстников дать вам время сосредоточиться
  • Конечно, прекратить серфинг в Интернете

Каждый раз, когда вас прерывают, вы замедляетесь, так как вашему разуму требуется время, чтобы вернуться к своим мыслям. Я слышал цифры, что для каждого прерывания человеческому разуму требуется 5-10 минут, чтобы вернуться к мыслительному процессу, который был до прерывания. С таким большим количеством времени на перерыв не нужно тратить много времени впустую.

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

dhable
источник
7

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

D3vtr0n
источник
7

Вы медленнее, чем ваши коллеги, или ваши оценки более оптимистичны?

pjc50
источник
7

Чтобы быстрее создавать программное обеспечение, я обнаружил, что лучшее, что нужно сделать, - это изучить ваш API времени выполнения как можно лучше. Не вводите логику списка, когда подойдет расширение LINQ; не создавайте группу слушателей событий, когда будет работать привязка и т. д.

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

Лично я нашел у разработчиков младшего уровня, возьму их начальную оценку и умножу ее на 2, а затем удвою. Это будет учитывать все обучение, встречи, потерянное время и т. Д. Более старшие разработчики уровня имеют тенденцию работать в 2 раза над их оценками.

Часто вопрос не в том, была ли ваша оценка неверной. Это ваша оценка учитывает все правильные вещи? Вы даете свои оценки и сроки с точки зрения усилий по кодированию или с точки зрения календарного времени? Подумайте о том, сколько времени в вашем дне и насколько оно актуально, продуктивное кодирование против встреч, обучения, отладки и т. Д.

Джеймс Шек
источник
3
«... умножьте это на 2, а затем удвойте». Так как вы заинтересованы в экономии времени, у меня есть математический совет для вас, который вы могли бы использовать ...
LOL - Я знаю, что ты говоришь. Но вы будете удивлены тем, что это часто пропускается незамеченным, в отличие от слова «умножить на 4».
7

Две вещи, которые могут подразумеваться, но я еще не видел среди ответов здесь, которые увеличивают производительность:

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

  • Есть какой-то контроль версий. Необходимость кодировать без возможности откатить изменения - это все равно что пытаться ходить по яйцам

Buhb
источник
7

На ум приходит пара идей:

  1. Получить другие мнения о ваших оценках - Есть ли другие разработчики, которые вы могли бы спросить что-то вроде «Эй, как вы думаете, вы можете сделать такую ​​функцию в этот срок?» Идея в том, что в некоторых случаях вклад других людей может помочь с точностью, так как кто-то может отметить кучу вещей, которые вы упустили при оценке.

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

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

JB King
источник
7
  1. Знать технологию внутри и снаружи.
  2. Стоп! Думать! Идти!
  3. Архитектор для всего, что может возникнуть, но реализовать только то, что действительно требуется.
  4. ПОЦЕЛУЙ - Делай это просто глупо
  5. Если это становится слишком сложным, возможно, это не очень хорошо продумано. (Вернитесь к 2 и 4)
  6. Не застрять в 5. Часто стоит начинать с нуля (вернитесь к 2 и 4)
  7. Вернитесь к 1.
Руи Кравейро
источник
7

Я думаю, что они ключевое слово здесь "своевременность". Они не говорили, что вы слишком медлительны, скорее, что вы не успели.

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

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

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

Ларри Ватанабэ
источник
«... Потратьте больше времени на понимание того, сколько времени вам понадобится для выполнения определенного задания, учитывая ваши навыки, опыт и область». -> Правильно, и это также поможет вам обрезать прицел и сэкономить вам еще больше времени.
Джим Г.
Это также поможет вашему менеджеру выглядеть хорошо для окружающих - это также позволяет выполнять вспомогательные материалы, такие как маркетинг, синхронно с вашим проектом.
Том Лис
7

Будьте стабильны, оставайтесь стабильными.

Создайте что-то, что реализует небольшую часть функциональности, и убедитесь, что она работает, сквозной. Затем продолжайте работать, добавляя новые функциональные возможности. Да, это отчасти практика TDD, но это имеет смысл, даже если вы не делаете TDD.

Смысл в том, что каждый раз, когда я видел кого-то с 2-недельным кодом, который никогда не был стабильным, всегда требуется еще 2 недели, чтобы добиться его стабильности.

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

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

Если у вас есть 10000 строк кода, которые никогда не работали , и вы должны найти разрыв, у вас есть тонна кода для поиска.

Небольшие, постепенные изменения в системе, которая стабильно стабильна. Идите медленно, чтобы идти быстро.

kyoryu
источник
7

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

МДМА
источник
1
Моя 30-минутная поездка на велосипеде на работу по норвежской сельской местности также хороша для очищения ума и развития творческих процессов.
6

Почти все ответы были сказаны до смерти во многих местах здесь и в других местах. Или, по крайней мере, я слышал это до смерти. Изучите свою IDE, научитесь быстрее печатать, использовать фреймворки, генерировать код и т. Д. И т. Д. Да, конечно, эти вещи помогут, и я сомневаюсь, что есть много программистов, которые владеют ими. Но, будучи программистом, который задает эти вопросы и часто посещает такие сайты, как Stack Overflow, вы уже знали это . Вы просто хотели, чтобы здесь их повторили, или вы просто хотели немного выпустить?

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

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

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

Так что мы можем с этим поделать? Мы не можем просто убедить наших руководителей, что нам нужно удвоить или утроить инвестиции в каждый из наших проектов. Я говорю привести пример. Создайте действительно замечательное программное обеспечение как побочный проект. Вложите в это свое время и не идите на компромисс. Все время обращайте внимание на то, как вы прогрессируете. Запишите, по-видимому, не связанные задачи, на которые вам пришлось потратить неожиданное количество времени, и посмотрите, сможете ли вы это оправдать. Сравните это со всеми другими проектами, над которыми вы работали. Будь жестоко честенс самим собой и всеми аспектами этого анализа. Можно ли пренебречь дополнительными вещами, которые вы сделали с вашим качественным программным обеспечением в «реальных» проектах на работе? Но, возможно, ваша попытка не удалась. В чем была причина? Вам стало скучно, и вы просто бросились делать основные функции? Я сам еще не сделал что-то подобное, вот почему я заканчиваю эту мысль с некоторым сомнением - но я намерен сделать это по-настоящему. Я буду держать вас в курсе :).

Наконец, я думаю, что большинство (если не все) оценки производительности являются искаженными и чрезвычайно манипулятивными. Вы не можете ограничить качество и скорость на 100%. Ваш начальник должен оценивать вас по стандартам, установленным организацией. Стандарт организации на компромисс между качеством и скоростью. Предположим, что OrangeSoft Inc. ожидает 33% качества и 66% скорости. Поэтому, если вы пишете код, у которого может быть треть модульных тестов, он должен делать это быстрее, но с меньшим временем доставки, вы должны набрать около 100% на ваш отзыв! (Это довольно грубые аналогии, но вы понимаете, в чем дело). Но вместо этого происходит то, что Боб пишет код очень быстро, но, как известно, глючит. Таким образом, в своем обзоре производительности он получит 3/5 за качество и 5/5 за скорость. Кэрол, с другой стороны, пишет код намного медленнее, но выдает значительно меньше ошибок. Она получает 5/5 за качество, но 3/5 за скорость. В любом случае, Боб и Кэрол оказываются на скамье подсудимых. Может ли любой сотрудник получить идеальный балл? Это справедливо?

Thiru
источник
5

Техника, которую я использую, - это эволюционное прототипирование.

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

slashmais
источник