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

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

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

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

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

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

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

• Избегайте позолоты - делайте только то, что от вас требуется (с точки зрения требований)
• Понять бизнес-требования и сделать это правильно с первого раза
• Тщательно понимайте свою среду и инструменты
• Станьте фантастической машинисткой, используйте вместо мыши сочетания клавиш
• Используйте итеративный подход и встроите проверки работоспособности, чтобы убедиться, что вы на правильном пути
• Не изобретайте велосипед, рассмотрите возможность повторного использования прошлой работы и работы других
• Устраняйте отвлекающие факторы, не проверяйте электронную почту, не смотрите снаружи, не разговаривайте с коллегами и т. Д.
• Не переутомляйтесь - узнайте, когда вам нужно сделать перерыв

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будь проще.

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

1. Напишите провальный тест ( красный ). (Часто для функциональности ваш код еще не имеет.)
2. Совершите ужасные кодовые преступления, чтобы сдать ваши тесты ( зеленый ). Жесткий код при необходимости.
3. Рефакторинг , возможно, ненадолго сломал тесты, но в целом улучшил дизайн.

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

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

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

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

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

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

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

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

Я делаю это завтра .

Получение вещей также очень полезно.

В любом случае, у меня небольшой объем внимания, поэтому эти книги помогают мне сохранить фокус ... что я снова делал?

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

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

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

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

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

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

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

Emacs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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