Я был профессиональным программистом в течение нескольких лет. Комментарии к моему коду в целом были одинаковыми: пишет отличный код, хорошо протестирован, но может быть быстрее .
Так как мне стать более быстрым программистом, не жертвуя качеством? Ради этого вопроса я собираюсь ограничить область действия C #, так как это в первую очередь то, что я кодирую (для забавы) - или Java, который во многих отношениях достаточно важен.
Вещи, которые я уже делаю:
- Напишите минимальное решение, которое выполнит работу
- Напишите множество автоматических тестов (предотвращает регрессии)
- Напишите (и используйте) многократно используемые библиотеки для всех видов вещей
- Используйте известные технологии, где они работают хорошо (например, Hibernate)
- Используйте шаблоны проектирования там, где они подходят (например, Singleton)
Все это здорово, но я не чувствую, что моя скорость увеличивается со временем. Мне все равно, потому что если я смогу что-то сделать, чтобы повысить свою производительность (даже на 10%), это будет на 10% быстрее, чем у моих конкурентов. (Не то чтобы у меня есть.)
Помимо этого, я неизменно получал эту отдачу от своих менеджеров - будь то мелкомасштабная разработка Flash или разработка Java / C ++ для предприятий.
Изменить: Кажется, есть много вопросов о том, что я имею в виду под быстрым, и как я знаю, я медленный. Позвольте мне уточнить некоторые детали.
Я работал в небольших и средних командах (5-50 человек) в различных компаниях над различными проектами и различными технологиями (Flash, ASP.NET, Java, C ++). Наблюдение за моими менеджерами (о чем они мне прямо сказали) заключается в том, что я «медленный».
Частично это связано с тем, что значительное количество моих сверстников пожертвовали качеством ради скорости; они написали код, который был ошибочным, трудным для чтения, сложным в обслуживании и трудным для написания автоматических тестов. Мой код, как правило, хорошо документирован, удобочитаем и тестируем.
В Oracle я бы последовательно исправлял ошибки медленнее, чем другие члены команды. Я знаю это, потому что я бы получил комментарии на этот счет; это означает, что другие (да, более старшие и опытные) разработчики могли бы выполнять мою работу за меньшее время, чем это потребовалось мне, с почти таким же качеством (удобочитаемость, ремонтопригодность и тестируемость).
Почему? Что мне не хватает? Как я могу стать лучше в этом?
Моя конечная цель проста: если я могу создать продукт X за 40 часов сегодня и как-то улучшить себя, чтобы завтра создать такой же продукт через 20, 30 или даже 38 часов, это то, что я хочу знать - как туда попасть? Какой процесс я могу использовать для постоянного улучшения? Я думал, что речь идет о повторном использовании кода, но этого, кажется, недостаточно.
источник
Ответы:
Мне нравится подход Джеффа Этвуда к этому, который можно найти здесь http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .
В основном в статье он ссылается на отрывок из книги «Искусство и страх» Дэвида Бэйлса и Теда Орланда. Отрывок идет:
По сути, грязные руки быстрее и чаще улучшают ваши навыки, чем тратят время на изучение и теоретизирование «идеального» способа сделать это. Мой совет: продолжайте практиковаться, следите за технологиями и изучайте дизайн.
источник
Одна возможность, о которой никто еще не говорил, это то, что у вас все хорошо, а у ваших менеджеров не очень хорошо. Как они измеряют производительность? Могут ли они дать вам конкретные примеры или это просто общее восприятие? Учли ли они время, потраченное на исправление работы других людей, по сравнению с вашей?
Я видел, как многие люди получают должное за то, что они сделали, в то время как остальная часть их команды исправляет беспорядок, который они оставили позади.
источник
Большая часть того, что люди считают важным, не важна. Скорость печати не важна. Быстрее машины или инструменты не важны. Мы не машинистки или операторы машин. Мы мыслители. Мы принимаем решения .
Что это важно , используя обратную связь , чтобы постоянно улучшать свой процесс принятия решений. Единственный способ сделать это, подобно приобретению любого другого навыка, - это через опыт, целенаправленную практику и постоянную обратную связь.
Напоследок: помните, что скорость без качества бесполезна, и наоборот. Чтобы максимизировать вашу полезность, найдите баланс между этими напряжениями.
* http://codekata.pragprog.com/
источник
Вполне возможно , что на самом деле, вы попросили принести в жертву некоторых качеств, для большей скорости.
В некоторых средах разработки 1 просто не стоит тратить дополнительное время на то, чтобы произвести что-то отточенное, когда будет достаточно просто.
1 - Я думаю о "внутреннем инструменталете", в частности, но есть и другие.
источник
Похоже, вы делаете все хорошие вещи - что в среднесрочной перспективе сделает вас быстрее, так что это не очевидно, если вы на самом деле медленный. Только ты действительно это знаешь. (но это вполне реальная возможность - PeopleWare заявляет о 10-кратной разнице в производительности между разработчиками для одной и той же задачи).
Итак, у меня есть несколько предложений для вас:
Время - вещь относительная, поэтому, возможно, проблема не в вашей реальной скорости, а в восприятии времени, которое вы даете. Вы можете предположить, что это займет неделю, но в итоге вы потратите две недели, тогда как другие могут потратить 3 недели ... но вы просто смотрите 1 неделю медленно.
Поскольку вы часто получаете эти отзывы, возможно, пришло время поговорить с вашим менеджером и коллегами, чтобы увидеть, что они говорят, - у них должно быть что-то, чтобы поучиться у них.
Сделайте пару программ с разработчиком «быстрого качества», чтобы увидеть, можете ли вы заметить разницу.
источник
По сути, все сводится к опыту . Быть быстрее в том, что вы делаете, - это как управлять автомобилем, изначально вы напуганы, поскольку другие - быстрые (или пьяные) водители (или оба), и вы хотите безопасно добраться до дома (с точки зрения программного обеспечения, вы хотите убедиться, что ваш код работает как разработано и работает хорошо).
За годы / месяцы, как только вы освоитесь с вождением и автострадой, вы научитесь нескольким хитростям, которые сделают ваше вождение увлекательным. Это то, что мы называем опытом. Эти «хитрости» (которые я называю чертами) - вот что помогает.
В моем случае я изучил реальное использование шаблонов проектирования путем кодирования (даже @ home) и изучения использования некоторых из них. Таким образом, когда я сталкиваюсь с проблемой, которая требует шаблона проектирования, я использую прошлый опыт, чтобы увидеть, какие из них сработали, и почему это работает / не работает для моей ситуации.
В итоге:
PS: опыт также приходит от обучения у других. Например, помощь SO, парное программирование, экспертные оценки и т. Д. У вас не может быть опыта, если вы не можете оглянуться назад и учиться на ошибках (или если кто-то никогда не оспаривает ваши усилия).
источник
Вопрос в том, стоите ли вы дешевле, если смотреть на общую стоимость в долгосрочной перспективе.
Другими словами, являются ли ваши тщательно разработанные исправления ошибок настолько высокого качества (включая тестовые примеры и документацию), что они перевешивают затраты на обслуживание исправлений ошибок, сделанных вашими более быстрыми сотрудниками?
Если да, то вам нужно, чтобы начальство осознало этот факт. Это может быть трудно спорить, если они не измеряют и имеют необходимые данные для подтверждения вашей оценки.
Если нет, то вам настоятельно необходимо рассмотреть, почему это так:
Подумайте об этом и отредактируйте свой вопрос с помощью своих выводов.
источник
Все, что люди спрашивают о том, действительно ли вы медлительны, глупы. Стать более быстрым программистом, не жертвуя качеством, всегда хорошая цель, какой бы медленной или быстрой вы ни были. Это моя цель номер 1 как программиста, и я никогда этого не сделаю. Я всегда стараюсь быстрее, не жертвуя качеством, я одержим этим. Вот что сработало для меня до сих пор в порядке полезности, вместе с некоторыми экспериментальными идеями в конце:
1) Никогда не прекращайте учиться: узнайте все, что можете о программировании и использовании компьютеров в целом. Найдите области, в которых вы слабы, и изучите их. Даже если это кажется совершенно не связанным с вашей работой и C #, я гарантирую, что если вы ищете его, вы часто найдете способы применить его к тому, что вы делаете. Обучение также связано с опытом, поэтому не просто читайте материал, но и попробуйте его и расширьте свои навыки. Если вы привыкли использовать Windows, попробуйте Unix или наоборот. Если вы обычно любите использовать IDE, попробуйте инструменты командной строки и текстовые редакторы или наоборот. Если вы слышали об инструменте или технологии, о которых вы раньше не слышали или о которых мало что знаете, не поддавайтесь искушению идти дальше. Поищи это! Не бойтесь мыслить нестандартно и изучать экспериментальные новые технологии, которые другие считают непрактичными;
2) Разбейте проекты: попробуйте разбить свои проекты на мини-проекты. Попытайтесь делать новый выпуск каждый день или не чаще, чем раз в несколько дней. Спросите себя: «Какой минимальный объем функциональности я могу выпустить, и все же выпустить что-то полезное для пользователя». Это навык, который вы выучите, выполнив его. Возможно, вам придется убедить ваших менеджеров позволить вам это сделать, но они, как правило, будут довольны результатами довольно быстро. Делая это, вы начнете замечать, что вещи, которые вы считаете важными для вашей функции, на самом деле являются дополнительными функциями, которые могут быть разработаны позже. Это позволяет вам и вашим менеджерам расставлять приоритеты только для наиболее важных функций вместо всех функций, связанных с той, над которой вы работаете. Это позволяет вам думать быстрее, сохраняя ясность и сосредоточенность. Вы в свою очередь законно будете программировать быстрее. Ваши менеджеры или, по крайней мере, менеджеры вашего менеджера, вероятно, также поймут, что вы сейчас программируете даже быстрее, чем на самом деле, потому что вы выпускаете больше релизов. Еще одним огромным преимуществом этого является то, что вы будете гораздо лучше оценивать, сколько времени потребуется для завершения релизов, и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. Менеджеры также, вероятно, поймут, что вы сейчас программируете даже быстрее, чем на самом деле, потому что вы выпускаете больше релизов. Еще одним огромным преимуществом этого является то, что вы будете гораздо лучше оценивать, сколько времени потребуется для завершения релизов, и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. Менеджеры также, вероятно, поймут, что вы сейчас программируете даже быстрее, чем на самом деле, потому что вы выпускаете больше релизов. Еще одним огромным преимуществом этого является то, что вы будете гораздо лучше оценивать, сколько времени потребуется для завершения релизов, и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное.
3) Используйте технику pomodoro и адаптируйте / измените то, что вам не подходит. Если вы объедините это с номером 2 в этом списке, вы получите ОГРОМНОЕ повышение производительности.
4) Изучите Vim. Даже если вы в конечном итоге будете использовать эти команды в Visual Studio через ViEmu, или из Eclipse через плагин, или из Emacs, вы получите повышение производительности. Лучший способ изучить Vim - это начать использовать его и заставить себя никогда (отключать его / возвращаться к старым инструментам), пока вы не овладеете им. Сначала это больно, но вам никогда не захочется отступать, и даже съеживаться, когда вам приходится работать без него. Кто-то скажет, что это не сильно увеличит вашу скорость. Но быстрее - быстрее, особенно когда чтение и изменение кода - это то, ЧТО МЫ ДЕЛАЕМ, и я иногда экономлю время на этом.
5) Последний вариант не обязательно рекомендуется, так как я не уверен, что это хорошая идея, и она может фактически снизить вашу производительность, но я все равно справлюсь с этим. Вы можете попытаться сделать больше приемочных тестов и меньше юнит-тестов, или, по крайней мере, убедиться, что вы делаете некоторые приемочные тесты. У меня был успех с SpecFlow, но я подозреваю, что есть что-то лучшее там. Даже написание спецификаций может быть довольно техническим, поэтому вам может потребоваться, чтобы ваш менеджер / клиент сначала написал черновую версию, в которую вы вносите существенные изменения, или вы можете написать все самостоятельно, просто прочитав их и подтвердив. Это поможет вам с номером 2 из этого списка. Также приемочные тесты могут быть более практичными и требуют меньше кода, чем модульные тесты. Нельзя сказать, что они заменяют их, разные инструменты для разных вещей.
6) Этот еще более экспериментальный и противоречивый. Я на самом деле не сделал это сам, поэтому я не могу точно рекомендовать это. Изучите и используйте систему метапрограммирования от JetBrains. Используйте его для создания инструментов, которые ваш менеджер / клиент использует для создания нужного программного обеспечения. Возможно, вы даже сможете прекратить выполнение модульных и приемочных тестов, если сможете использовать их для создания инструментов, которые ваш менеджер / клиент использует для определения поведения очень простым и не запутанным способом. Идея не в том, чтобы избавиться от программиста. Программистам по-прежнему необходимо добавлять новые функции в эти инструменты, используемые клиентом / менеджером, всякий раз, когда они (люди, а не инструменты) не могут легко создать желаемую функциональность. Я верю, что MPS или другие подобные ему инструменты - путь будущего.
источник
Используйте свой мозг больше и меньше тестируйте. Если честно, у тестирования есть свое место, но оно дорогое.
Кроме того, прочитайте Искусство программирования Unix (бесплатно онлайн, книга стоит цена)
Наконец, вы не можете быть в нужном месте. Круглый колышек на квадратной работе и др.
В конечном счете это похоже на школу: «Вывод того, что хочет учитель», становится «выводом, о чем просит и платит руководство».
источник
Если вы возьмете большой законченный проект и получите количество «окончательных» строк кода на человека в час, вы обнаружите, что программисты кодируют НАМНОГО медленнее, чем вы могли себе представить.
Мы говорим всего несколько строк кода в день. Остальное время вы тратите на отладку, переписывание и выполнение общих задач программиста.
Возможно, вы слышали старую поговорку: если вы поймете ошибку во время ее ввода, она сэкономит вам 10 раз больше времени, если вы поймали ее во время сборки, что в 10 раз лучше, чем перехват во время QA, что в 10 раз лучше чем ловить его после релиза ..
Так как ты ускоряешь это? Я не стал бы концентрироваться на какой-либо форме скорости набора текста - сокращение ошибок и улучшение других «будущих взаимодействий» с вашим кодом должно быть гораздо более выгодным вложением вашего времени.
Читаемый, понятный код имеет решающее значение. Вы пишете свой код один раз, но он будет прочитан десятки раз. Письмо для удобства чтения избавит вас от многих проблем в будущем (что также сэкономит много времени). Если вы когда-нибудь вернетесь и прочитаете свой код и будете думать об этом хотя бы секунду, значит, вы делаете это неправильно.
Парное программирование может сократить время QA и, если учесть, что один программист производит всего несколько строк в день, если две могут кодировать с той же скоростью, что и одна, но с меньшим количеством ошибок, тогда вы НАХОДИТЕСЬ впереди.
Защитное кодирование (например, проверка параметров) может уменьшить проблемы ... Если в вашей команде действительно хороший аналитик / архитектор, вы можете сэкономить время с хорошим начальным дизайном.
В противном случае просто продолжайте улучшать свои дизайнерские навыки. По мере накопления опыта вы обнаружите, что сможете лучше распознавать шаблоны, которые не будут работать, и избегать их, вы сможете раньше определять временные рамки и т. Д.
источник
Рассматривали ли вы сделать подробный аудит себя, как вы работаете? Либо ручкой и бумагой отслеживайте, как вы проводите свое время, либо используйте что-то вроде Rescue Time, чтобы отследить себя.
Как только вы будете лучше понимать, как именно вы проводите свое время, вы сможете лучше понять, что нужно улучшить, и сосредоточить свои усилия на этом.
В идеале вы можете попросить некоторых своих коллег сделать это, сравнить свои результаты и получить идеи друг от друга. У вас, вероятно, есть сильные стороны, от которых они тоже могут выиграть.
Может быть, вы обнаружите, что вы тратите слишком много времени на часть вашего процесса, которая может быть автоматизирована, или просто у вас много отвлекающих факторов в течение определенной части дня, а другая часть дня тихая, тогда вы можете планировать свои задачи вокруг что и т.д.
Или, может быть, вы обнаружите, что тестирование занимает больше времени, чем вы думали, и вам нужно переосмыслить свое восприятие того, что оно делает вас быстрее.
Если ничего другого, это дает вам некоторые ориентиры, с которыми вы можете работать.
источник
Из твоего списка у тебя все хорошо.
Если ваши коллеги делают код с более высоким номером CRAP, они пойдут быстрее. CRAP - это комично названная метрика, сочетающая цикломатическую сложность и тестовое покрытие.
Не пишите код, который более CRAP, чем вы должны. ;)
Единственное, что я могу предложить вам - это использовать библиотеки, не пишите их, если:
Вы читаете и делаете, и это здорово. Но вы можете застрять, думая о процедурном или ОО-коде. Вы подвергались функциональному программированию (скажем, на Haskell?) И Прологу?
Чтобы отточить свою технику программирования ОО, вы играли с Smalltalk / Squeak?
И наконец, теория. У вас есть хотя бы элементарное понимание теории графов? (Некоторые программы в какой-то момент работают с деревьями, DAG или просто с простыми графами. Сети - это графы)
источник
Я собираюсь процитировать дядя Боб :
- «Неистовая посредственность», Роберт С. Мартин
источник
Насколько я знаю, это:
Как менеджер, вы можете выбрать любой 2.
Не беспокойтесь о комментариях, которые вы получаете на скорости. Как товарищ по кодированию, я бы предпочел поддерживать хорошо продуманный и хорошо написанный код, а не что-то, что было собрано вместе.
источник
Основные вещи, о которых я могу думать, следующие
Я уверен, что есть кое-что, что вы можете сделать и в области навыков кодирования, но, похоже, вы во всех подобных вещах. Вещи, которые я перечислил выше, обычно игнорируются разработчиками.
источник
Вы можете пройти курс скоростного набора. Я не знаю, если печатать быстрее, это проблема, но «слишком медленное кодирование» может быть вызвано просто медленной скоростью печати.
Как насчет генераторов кода? Иногда код становится повторяющимся. Рефакторинг может удалить некоторые из них, но даже тогда у вас могут быть повторяющиеся вызовы одной и той же рефакторированной функции. В зависимости от данных и кода, с которыми вы работаете, генераторы кода (написанные в Excel, Perl, Java и т. Д.) Могут сэкономить много времени. И использование инструментов генерации кода для разработки пользовательского интерфейса обычно не составляет труда.
И, наконец, возможно, метрики неверны. Рассматривали ли вы , что вы кодирование в fasteset возможной скорости данной все остальное, и что сроки слишком коротки, что делают вас появляется , чтобы быть медленным кодером?
Основываясь на правках в вашем вопросе, кажется, что вы могли бы либо пойти по пути некоторых из ваших коллег и собрать вместе самое быстрое решение, которое будет работать - и проклятие документации и QA!
Или ... получите больше опыта и практики в конкретной области, чтобы вы знали кодовую базу и API так хорошо, что могли бы кодировать решения во сне. Это можно сделать, но требует больше времени. Если другие разработчики, которые работают быстрее вас, как известно, являются более старшими и более опытными, тогда остается сделать только одно - вы должны стать старше и опытнее!
источник
У меня есть возражение против представления "жертвенного качества за скорость".
Профессиональные программисты (программисты) должны выполнить 3 задачи:
1) код должен работать так, как задумано;
2) доставка должна быть в срок;
3) иметь хорошее качество, документацию и т. Д.
4) другое и т. Д.
Я думаю, OP был обвинен как медленный, вероятно, потому что OP не сделал вовремя.
источник
Это уловка 22, которую трудно обойти. Хотя вам может все еще не хватать опыта, и некоторые знания во многих аспектах уже работают быстрее, чем большинство, выгода в том, что его труднее измерить .
Лично лучшее, что вы можете сделать на данный момент, это измерить себя. Предоставьте себе обратную связь о том, как вы работаете, возможно, простые изменения в ваших рабочих привычках могут сделать вас более продуктивными.
Я обнаружил, что письма разъедают гораздо больше, чем я думал, просто из-за прерывания. Теперь я отвечаю только на письма два раза в день и за несколько дней набрал почти 1 час производительности. Попробуйте такие методы, как pomodoro , я использовал его как средство измерения. Через равные промежутки времени (15 минут) я записывал то, что делал в то время. Это позволило мне увидеть, как устроены мои дни и что я могу сделать, чтобы максимизировать эффективность.
источник
Преимущество Squeak для быстрого кодирования выходит далеко за рамки простого «оттачивания навыков ООП». Есть причина, по которой современные графические интерфейсы, а также IDE были изобретены на Smalltalk, не говоря уже о том, что JUNIT был портом SUNIT для Java, термин «ООП» был изобретен для описания Smalltalk и т. Д., И т. Д.
Нужно всегда использовать язык и среду, которые лучше всего подходят для того, что кто-то надеется достичь, но для общего прототипирования, по крайней мере, я бы сопоставил скрип с любым, за возможным исключением HyperCard, и даже это потребовало бы сравнительного анализа, чтобы увидеть, какой на самом деле быстрее, учитывая, что в Squeak есть встроенные средства, подобные гиперкарте.
источник