Моя последняя оценка работы включала только одно слабое место: своевременность. Я уже знаю о некоторых вещах, которые я могу сделать, чтобы улучшить это, но я ищу еще кое-что.
У кого-нибудь есть советы или рекомендации о том, что они делают, чтобы увеличить скорость своей продукции, не жертвуя ее качеством?
Как вы оцениваете сроки и придерживаетесь их? Что вы делаете, чтобы сделать больше за более короткие промежутки времени?
Любая обратная связь с благодарностью, спасибо,
performance
methodology
Ник Готч
источник
источник
Ответы:
Выключи компьютер. Возьмите карандаш и немного бумаги. Сделайте набросок вашего дизайна. Рассмотрите это со своими пэрами. Затем напишите код.
источник
Некоторые идеи...
источник
Ваше желание быть «более быстрым» программистом само по себе похвально. Однако, несвоевременная доставка не означает, что вы медлительны, это означает, что проект был спланирован плохо. Быть «более быстрым» программистом не поможет; это просто означает, что вы будете сваливать в срок быстрее.
Вы (и ваша команда) делаете одну из следующих ошибок (или все они):
Существует несколько способов решения любого из трех приведенных выше. Но прежде чем вы сможете улучшить любой из них, вам нужно знать, почему дела идут так, как они есть. Сделайте посмертную оценку последних двух или трех оценок проекта в сравнении с фактическим затраченным временем и выясните, куда ушло дополнительное время.
Я повторю это снова - медлительность в написании кода не приведет к несоблюдению сроков , если вы спланировали это должным образом, чтобы учесть этот факт.
источник
Действительно, действительно выучи свой редактор. Если вы используете IDE, убедитесь, что вы используете все функции, которые он предлагает. Получить шпаргалку, чтобы узнать сочетания клавиш для вашего редактора по вашему выбору. Если вы используете оболочку, установите ярлыки для часто используемых каталогов
источник
«Есть ли у кого-нибудь советы или рекомендации о том, что они делают, чтобы увеличить скорость своей продукции, не жертвуя ее качеством?»
Многие, многие люди стремятся к «высочайшему» качеству за счет чего-то, что (а) просто, (б) надежно и (в) правильно.
Самый важный способ ускорить вашу разработку - упростить то, что вы делаете, чтобы она была максимально простой.
Большинство людей, которые испытывают проблемы с доставкой вовремя, доставляют слишком много. И приведенные причины часто глупы. Они часто просто воспринимаемые требования, а не фактические требования.
Я слышал, что многие люди говорят мне, что «ожидает» клиент. Это плохая политика.
Постройте самую простую вещь. Если клиент требует больше, строить больше. Но сначала постройте самую простую вещь.
источник
Избегайте полировки вашего кода до совершенства, просто сделайте так, чтобы он работал. Это то, что ожидает бизнес.
Но часто увеличение скорости подразумевает потерю качества.
источник
Повторное использование - я пытаюсь учесть любые умные биты из предыдущих проектов, чтобы я мог использовать их снова в будущих предприятиях. Всегда стоит спросить себя: "Могу ли я снова использовать это когда-нибудь?"
источник
Будь проще.
Если вы используете TDD, вы должны следовать « красный, зеленый, рефакторинг »:
источник
Загрузите всю документацию по языкам / библиотекам локально на свой компьютер, затем отключите сетевой кабель / выключите Wi-Fi .
Не пытаться быть смешным здесь. Это действительно помогает мне!
источник
Обратите внимание, что вы слишком долго читаете переполнение стека. Оправдание компиляции работает только так долго. :)
источник
Избегайте переключения задач слишком часто. Отвлечение внимания и переключение задач могут убить день, даже если вы используете такие инструменты, как Mylyn, для управления своими задачами.
Выясните детализацию (например, 30 минут) и работайте только над тем, что связано с поставленной задачей. Все остальное (новые сообщения об ошибках, электронные письма о других проблемах, процедурные вопросы, которые не связаны) задерживается по крайней мере до «следующей контрольной точки». Убедитесь, что вы отключили всплывающие уведомления по электронной почте, чтобы вас не засосало.
Это особенно эффективно, если в вашей команде есть приятель, который сообщит вам, действительно ли ситуация растаяла и требует вашего немедленного внимания.
источник
Делай это правильно, лучшим образом, в первый раз. Если это означает, что вы должны остановиться и немного подумать, прежде чем начать, то сделайте это. Работает 90% времени.
источник
Научитесь печатать как можно быстрее .
источник
Я делаю это завтра .
Получение вещей также очень полезно.
В любом случае, у меня небольшой объем внимания, поэтому эти книги помогают мне сохранить фокус ... что я снова делал?
источник
Практика и тяжелая работа.
Вам нужно потратить время и силы. По мере того, как вы будете чувствовать себя более комфортно и уверенно в работе с любыми инструментами, вам следует следовать скорости и творческому подходу.
Если вы хотите улучшить какой-то конкретный навык, это также может помочь в разработке упражнений, которые позволят вам работать именно над этим. Если ваша медлительность находится на этапе проектирования, попробуйте найти проблемы с дизайном для работы в Интернете. Повторяя одно и то же упражнение, вы сможете выполнять его быстрее и практиковаться в скорости. Мне лично нравятся упражнения алгоритма TopCoder для отработки скорости программирования. У них тоже есть проблемы с дизайном, но я их не пробовал.
источник
Узнайте о Зоне, узнайте, как попасть в нее, и узнайте, как распознать, когда вас нет в ней.
Цитата из того, что уловки, которые Вы используете, чтобы получить себя в зоне
источник
Знание своей IDE и структуры хорошо. Обращение к Google для каждой мелочи требует времени.
источник
Emacs
источник
Прежде чем начать разработку:
Каждый раз, когда вас прерывают, вы замедляетесь, так как вашему разуму требуется время, чтобы вернуться к своим мыслям. Я слышал цифры, что для каждого прерывания человеческому разуму требуется 5-10 минут, чтобы вернуться к мыслительному процессу, который был до прерывания. С таким большим количеством времени на перерыв не нужно тратить много времени впустую.
Сотрудники нашей компании фактически блокировали время в своих календарях, а затем каждый день переезжали в пустой конференц-зал на пару часов.
источник
Изучите свою разработку IDE в и из. Изучите сочетания клавиш. Научитесь меньше пользоваться мышью. Я считаю, что это экономит много времени для меня.
источник
Вы медленнее, чем ваши коллеги, или ваши оценки более оптимистичны?
источник
Чтобы быстрее создавать программное обеспечение, я обнаружил, что лучшее, что нужно сделать, - это изучить ваш API времени выполнения как можно лучше. Не вводите логику списка, когда подойдет расширение LINQ; не создавайте группу слушателей событий, когда будет работать привязка и т. д.
Что касается оценки, это приходит с опытом. Вы можете использовать программное обеспечение для оценки, чтобы помочь вам получить более точные оценки.
Лично я нашел у разработчиков младшего уровня, возьму их начальную оценку и умножу ее на 2, а затем удвою. Это будет учитывать все обучение, встречи, потерянное время и т. Д. Более старшие разработчики уровня имеют тенденцию работать в 2 раза над их оценками.
Часто вопрос не в том, была ли ваша оценка неверной. Это ваша оценка учитывает все правильные вещи? Вы даете свои оценки и сроки с точки зрения усилий по кодированию или с точки зрения календарного времени? Подумайте о том, сколько времени в вашем дне и насколько оно актуально, продуктивное кодирование против встреч, обучения, отладки и т. Д.
источник
Две вещи, которые могут подразумеваться, но я еще не видел среди ответов здесь, которые увеличивают производительность:
Используйте какие-то сценарии сборки и развертывания. Компиляция, развертывание, перезапуск сервера приложений и т. Д. Не могут израсходовать время и внимание, это должно быть одним щелчком мыши.
Есть какой-то контроль версий. Необходимость кодировать без возможности откатить изменения - это все равно что пытаться ходить по яйцам
источник
На ум приходит пара идей:
Получить другие мнения о ваших оценках - Есть ли другие разработчики, которые вы могли бы спросить что-то вроде «Эй, как вы думаете, вы можете сделать такую функцию в этот срок?» Идея в том, что в некоторых случаях вклад других людей может помочь с точностью, так как кто-то может отметить кучу вещей, которые вы упустили при оценке.
Отточите свой навык оценки - начните отслеживать, насколько вы отключены в оценках и почему вы отключены: другие рабочие элементы вызывают несоблюдение сроков? Вы постоянно недооцениваете, насколько сложно что-то? Вы даете полный график, когда это не практично, например, то, что спрашивается, достаточно расплывчато, чтобы простое изготовление прототипа заняло бы недели, а затем должна быть переоценка того, что еще нужно сделать? Это может помочь в построении этого навыка, так что если вы скажете, что что-то займет х часов, вы можете быть уверены в этом, потому что вы делали это снова и снова. Альтернативный способ заявить об этом - просто практика, практика, практика.
Конечно, вы, наверное, уже обдумали это, но я просто подумал, что стоит заявить об этом тем, кто еще не рассмотрел эти идеи.
источник
источник
Я думаю, что они ключевое слово здесь "своевременность". Они не говорили, что вы слишком медлительны, скорее, что вы не успели.
В управлении проектами важно, чтобы менеджер был в состоянии оценить, когда ваши рабочие задания будут выполнены с точностью. Я подозреваю, что основная причина, по которой ваши усилия не были признаны своевременными, заключается в том, что у вас часто были предметы, которые не были доставлены по расписанию и были доставлены намного позже, чем было запланировано.
Чтобы улучшить свою своевременность, вы можете потратить больше времени на понимание того, сколько времени вам потребуется для выполнения определенного рабочего задания с учетом ваших навыков, опыта и области. Это позволит вам дать более точные оценки вашему менеджеру проекта. Ключевым моментом здесь является «лучше» ... вы могли бы выполнять вовремя чаще, дополняя все с помощью коэффициента выдумки, но к чему вы действительно хотите стремиться, это более точная оценка.
Я бы обсудил это с вашим менеджером, чтобы узнать, действительно ли это проблема. В противном случае вы могли бы закончить программирование вдвое быстрее, обещая что-то наполовину меньше, чем раньше, и все равно подвергнуться критике за вашу своевременность, потому что ваши оценки будут иметь тот же коэффициент ошибок.
источник
Будьте стабильны, оставайтесь стабильными.
Создайте что-то, что реализует небольшую часть функциональности, и убедитесь, что она работает, сквозной. Затем продолжайте работать, добавляя новые функциональные возможности. Да, это отчасти практика TDD, но это имеет смысл, даже если вы не делаете TDD.
Смысл в том, что каждый раз, когда я видел кого-то с 2-недельным кодом, который никогда не был стабильным, всегда требуется еще 2 недели, чтобы добиться его стабильности.
Если вы остаетесь стабильным, вы устраняете эту неопределенность, а также даете себе возможность прицелиться ближе к крайнему сроку, если это необходимо.
Очевидный контраргумент состоит в том, что выполнение этого займет больше времени, чем простое его написание, поскольку вы будете выполнять дополнительную работу по стабилизации не финального кода. Я не покупаю это ни на секунду. Когда у вас есть код, который работает , вы меняете 5 строк, и что-то ломается, вы точно знаете , где должен был произойти разрыв.
Если у вас есть 10000 строк кода, которые никогда не работали , и вы должны найти разрыв, у вас есть тонна кода для поиска.
Небольшие, постепенные изменения в системе, которая стабильно стабильна. Идите медленно, чтобы идти быстро.
источник
Для меня достижение хорошей производительности - это четкое представление о том, чего вы пытаетесь достичь и как вы этого добьетесь.
источник
Почти все ответы были сказаны до смерти во многих местах здесь и в других местах. Или, по крайней мере, я слышал это до смерти. Изучите свою IDE, научитесь быстрее печатать, использовать фреймворки, генерировать код и т. Д. И т. Д. Да, конечно, эти вещи помогут, и я сомневаюсь, что есть много программистов, которые владеют ими. Но, будучи программистом, который задает эти вопросы и часто посещает такие сайты, как Stack Overflow, вы уже знали это . Вы просто хотели, чтобы здесь их повторили, или вы просто хотели немного выпустить?
Но что, если бы мы смогли добраться до этого состояния? Я имею в виду освоить все эти предложения? Что будет потом? Что ж. Я предполагаю, что сроки будут сокращены еще больше. И снова мы вернемся к восприятию качества. Я имею в виду, что наше ремесло определенно прогрессировало и становилось все более и более продуктивным в течение десятилетий. Но повысилось ли качество за это время (исключая, конечно, самые ранние годы)?
Мой ответ прост: качественное программное обеспечение требует времени ! Вы можете обменять только одно на другое (качество / скорость). Но да, мы все знаем, что, тем не менее, мы не честны относительно степени, в которой этот компромисс часто заканчивается на скоростном конце шкалы. И мы еще большие лжецы в начале проектов!
Я говорю, что вы здесь не виноваты. Проблема заключается в том, что восприятие людей о том , как долго качества программного обеспечения должны принять. Мы обманываем себя, полагая, что мы способны создавать качественное программное обеспечение с типами графика времени, которые наши менеджеры или даже мы предполагаем. Мы не делаем качественное программное обеспечение . Мы пишем программное обеспечение, которое работает, но иногда со вспышками качества в определенных углах приложения.
Так что мы можем с этим поделать? Мы не можем просто убедить наших руководителей, что нам нужно удвоить или утроить инвестиции в каждый из наших проектов. Я говорю привести пример. Создайте действительно замечательное программное обеспечение как побочный проект. Вложите в это свое время и не идите на компромисс. Все время обращайте внимание на то, как вы прогрессируете. Запишите, по-видимому, не связанные задачи, на которые вам пришлось потратить неожиданное количество времени, и посмотрите, сможете ли вы это оправдать. Сравните это со всеми другими проектами, над которыми вы работали. Будь жестоко честенс самим собой и всеми аспектами этого анализа. Можно ли пренебречь дополнительными вещами, которые вы сделали с вашим качественным программным обеспечением в «реальных» проектах на работе? Но, возможно, ваша попытка не удалась. В чем была причина? Вам стало скучно, и вы просто бросились делать основные функции? Я сам еще не сделал что-то подобное, вот почему я заканчиваю эту мысль с некоторым сомнением - но я намерен сделать это по-настоящему. Я буду держать вас в курсе :).
Наконец, я думаю, что большинство (если не все) оценки производительности являются искаженными и чрезвычайно манипулятивными. Вы не можете ограничить качество и скорость на 100%. Ваш начальник должен оценивать вас по стандартам, установленным организацией. Стандарт организации на компромисс между качеством и скоростью. Предположим, что OrangeSoft Inc. ожидает 33% качества и 66% скорости. Поэтому, если вы пишете код, у которого может быть треть модульных тестов, он должен делать это быстрее, но с меньшим временем доставки, вы должны набрать около 100% на ваш отзыв! (Это довольно грубые аналогии, но вы понимаете, в чем дело). Но вместо этого происходит то, что Боб пишет код очень быстро, но, как известно, глючит. Таким образом, в своем обзоре производительности он получит 3/5 за качество и 5/5 за скорость. Кэрол, с другой стороны, пишет код намного медленнее, но выдает значительно меньше ошибок. Она получает 5/5 за качество, но 3/5 за скорость. В любом случае, Боб и Кэрол оказываются на скамье подсудимых. Может ли любой сотрудник получить идеальный балл? Это справедливо?
источник
Техника, которую я использую, - это эволюционное прототипирование.
Вы можете зайти в Google для получения дополнительной информации, но если вам нужно быстро что-то произвести, это единственный способ. Плюс к этому, преимущество в том, что когда пользователь говорит, что ему это нравится, вы готовы (... и можете начать делать документацию).
источник