Как кодировать быстрее (без ущерба для качества) [закрыто]

144

Я был профессиональным программистом в течение нескольких лет. Комментарии к моему коду в целом были одинаковыми: пишет отличный код, хорошо протестирован, но может быть быстрее .

Так как мне стать более быстрым программистом, не жертвуя качеством? Ради этого вопроса я собираюсь ограничить область действия C #, так как это в первую очередь то, что я кодирую (для забавы) - или Java, который во многих отношениях достаточно важен.

Вещи, которые я уже делаю:

  • Напишите минимальное решение, которое выполнит работу
  • Напишите множество автоматических тестов (предотвращает регрессии)
  • Напишите (и используйте) многократно используемые библиотеки для всех видов вещей
  • Используйте известные технологии, где они работают хорошо (например, Hibernate)
  • Используйте шаблоны проектирования там, где они подходят (например, Singleton)

Все это здорово, но я не чувствую, что моя скорость увеличивается со временем. Мне все равно, потому что если я смогу что-то сделать, чтобы повысить свою производительность (даже на 10%), это будет на 10% быстрее, чем у моих конкурентов. (Не то чтобы у меня есть.)

Помимо этого, я неизменно получал эту отдачу от своих менеджеров - будь то мелкомасштабная разработка Flash или разработка Java / C ++ для предприятий.

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

Я работал в небольших и средних командах (5-50 человек) в различных компаниях над различными проектами и различными технологиями (Flash, ASP.NET, Java, C ++). Наблюдение за моими менеджерами (о чем они мне прямо сказали) заключается в том, что я «медленный».

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

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

Почему? Что мне не хватает? Как я могу стать лучше в этом?

Моя конечная цель проста: если я могу создать продукт X за 40 часов сегодня и как-то улучшить себя, чтобы завтра создать такой же продукт через 20, 30 или даже 38 часов, это то, что я хочу знать - как туда попасть? Какой процесс я могу использовать для постоянного улучшения? Я думал, что речь идет о повторном использовании кода, но этого, кажется, недостаточно.

пепла999
источник
4
Другие кодируют быстрее, чем вы при том же качестве? Если нет, укажите в ваших записях поддержки и отчетах об ошибках, чтобы указать, что скорость не является проблемой.
Майкл К
3
Возможный дубликат: programmers.stackexchange.com/questions/55692/…
Корбин
1
Чтобы попытаться выиграть гонку, некоторые выберут своих самых быстрых лошадей и побьют их, чтобы идти быстрее. Любые вопросы?
Пол
24
У меня нет ответа для вас, но у меня есть кое-что, что может заставить вас чувствовать себя лучше. Каким бы медленным вы ни были программистом, каким бы неэффективным вы ни были, ваш менеджер намного, намного хуже. Какой идиот говорит: «Эй, Боб, ты слишком медленный», не помогая тебе совершенствоваться? Могу также сказать, что ты слишком короток. Это не лидерство, это просто чертовски. Думаю, у меня есть предложение: найти работу у компетентного менеджера, который будет работать с вами, чтобы преодолеть ваши недостатки.
Мальволио,
1
Все ответы делают меня несчастным. Если вы просто хотите, чтобы шаг noob-> посредственный, тогда, возможно, делать одну вещь в порядке. Но посредственный-> эксперт всегда требует выучить все. Вы должны глубоко изучить вашу VCS, свой редактор, свой язык программирования и свои фреймворки. Вам нужно повторить жесткие и интересные шаги, чтобы вы могли делать их не задумываясь. И затем вам нужно найти способ применения контекста, такого как разница между потребностями клиентов и потребностями вашего коллеги, как ваше ежедневное настроение влияет на вашу способность кодировать / проектировать / обсуждать. Если вы хотите, чтобы 1 вещь сделала это: выучите все.
erikbwork

Ответы:

158

Мне нравится подход Джеффа Этвуда к этому, который можно найти здесь http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

В основном в статье он ссылается на отрывок из книги «Искусство и страх» Дэвида Бэйлса и Теда Орланда. Отрывок идет:

В день открытия учитель керамики объявил, что делит класс на две группы. Он сказал, что все те, кто находится слева от студии, будут оцениваться исключительно по количеству произведенной ими работы, а все те, кто справа, - только по качеству. Его процедура была проста: в последний день занятий он приносил свои весы для ванной и взвешивал работу «количественной» группы: пятьдесят фунтов горшков с оценкой «А», сорок фунтов с «В» и так далее. Тем не менее, для оценки «качества» необходимо было получить только один горшок - хотя и идеальный - чтобы получить «А». Что ж, пришло время оценки, и появился любопытный факт: все работы самого высокого качества были произведены группой по количеству. Кажется, что пока «количество»

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

ChrisW
источник
12
Разве эта аналогия не подразумевает, что гончары собрали кучу мусорных горшков, прежде чем производить качественные? Можете ли вы сделать это в профессиональной среде, со всей совестью? А как насчет тех, кто учился и теоретизировал, а затем выполнил свою работу раньше срока?
PDR
4
Я в порядке с 20 мусорными горшками для опыта программирования хобби. Это также помогает мне с моим профессиональным опытом программирования; кроме того, должен начать где-нибудь.
ashes999
23
Я просто решил взглянуть на это поверхностно, «практика совершенна». Не смотрите слишком глубоко в него;)
chrisw
6
Мне не нравится этот ответ, потому что его слишком легко принять неверным путем, точно так же, как «одноразовые прототипы» никогда не кажутся выброшенными.
Рудольф Олах
2
Мне кажется странным, что у многих людей есть проблемы с этим. Это почти идеальная аналогия для итеративного процесса разработки. Вы строите что-то быстрое, чтобы соответствовать требованиям, исправляете ошибки и реорганизуете до тех пор, пока оно не станет правильным и достаточно хорошим Если вы не создаете программное обеспечение таким образом, вам действительно нужно попробовать его. Размышление и пуповина гораздо менее эффективны, чем заставить что-либо делать и позволять людям стучать по нему.
JimmyJames
72

Одна возможность, о которой никто еще не говорил, это то, что у вас все хорошо, а у ваших менеджеров не очень хорошо. Как они измеряют производительность? Могут ли они дать вам конкретные примеры или это просто общее восприятие? Учли ли они время, потраченное на исправление работы других людей, по сравнению с вашей?

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

прецизионный самописец
источник
1
Это, вероятно, большая часть проблемы. Оглядываясь назад, можно сказать, что я всегда сравниваюсь с людьми, которые работают в моей компании на годы дольше, чем я. Хм ...
ashes999
Если это так, я советую задать первые два из моих вопросов напрямую и посмотреть, какой ответ вы получите, возьмите его оттуда
pdr
16
насколько это правда, так часто я сталкивался с менеджерами, заявляющими, что я некомпетентен, когда проекты, которые я выводил в производство, систематически генерируют на один-два порядка меньше обращений в службу поддержки, чем эквивалентные работы других команд. Многим просто не удается увидеть общую картину. Метрика помогает примерно так же, как это неприятно. Обычно такой менеджер пытается играть в систему так, чтобы их статистика выглядела хорошо.
Newtopian
Это больше комментарий, чем ответ. Лично я всегда хочу стать быстрее и эффективнее как программист, независимо от того, что думают другие. Здесь определенно есть что обсудить.
Андрес Канелла
@AndresCanella Каждый ответ на этот вопрос в основном длинный комментарий. Вы правы, есть что обсудить. Это действительно не хороший формат для обсуждения (и не должен быть). Но для начала это был хороший вопрос, поэтому он закрыт и помечен как Wiki сообщества, за который никто не получает очки репутации, а не удаляется.
фунтовые
39

Большая часть того, что люди считают важным, не важна. Скорость печати не важна. Быстрее машины или инструменты не важны. Мы не машинистки или операторы машин. Мы мыслители. Мы принимаем решения .

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

  • Работа над сторонними проектами.
  • Работа над проектами с открытым исходным кодом.
  • Работайте с разработчиками, которые лучше вас. Парная программа!
  • Познакомьтесь с новыми инструментами и техниками. Держи то, что работает.
  • Выполняйте упражнения по программированию, предназначенные для тренировки вашего аппарата принятия решений *.
  • Контролируйте свои улучшения на основе объективных показателей, таких как частота и скорость дефектов, и субъективных показателей, таких как качество кода и пригодность.

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

* http://codekata.pragprog.com/

Рейн Хенрикс
источник
Можете ли вы предложить другие сайты / условия для Google? Я думаю, что решение одной странной проблемы в неделю может заставить мой мозг двигаться в разных измерениях.
ashes999
Мой недавний фаворит - pragprog.com/titles/btlang/seven-languages-in-seven-weeks
Рейн Хенрикс
1
Часть в самом начале не имеет смысла. Все, что делает вас быстрее, делает вас быстрее. Если хотя бы часть вашего времени уходит на набор текста, то повышение скорости набора текста сделает вас быстрее. Если хотя бы часть вашего времени уходит на ожидание компьютера, то более быстрый компьютер сделает вас быстрее. Когда вы стремитесь стать как можно быстрее и постоянно совершенствоваться, ничего не следует упускать из виду.
still_dreaming_1
12
Такие мелочи, как набор текста и скорость компьютера, имеют большое значение. Это из-за неожиданных побочных эффектов. Когда вам приходится ждать своего компьютера, большинство людей разочаровываются, а некоторые даже отвлекаются. Сочетание разочарования и отвлечения - огромные убийцы производительности. Нечто подобное относится и к печати. Если вы быстро печатаете, это, вероятно, означает, что вы хорошо научились печатать на ощупь и, вероятно, не слишком много думаете о наборе текста. Это освобождает ваши глаза и мозг, чтобы сосредоточиться на поставленной задаче, что значительно повышает производительность.
still_dreaming_1
@INTPnerd Я согласен. Если вы тратите время на размышления о том, как слово «бросить» появляется на вашем экране («Мне нужно навести туда мышь, затем нажать, а затем мне нужно найти« t »на моей клавиатуре»), у вашего мозга тоже не будет времени рассмотреть фактические решения.
erikbwork
25

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

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


1 - Я думаю о "внутреннем инструменталете", в частности, но есть и другие.

Jens Bannmann
источник
5
Это то, что я сделал из своей ранней работы - другие писали значительно более низкое качество за счет огромной скорости. Это моя ахиллесова пята; Мне очень трудно писать плохой код, который, как я знаю, укусит меня позже.
ashes999
Эту проблему легко решить. вам нужно изменить свою программную среду. Вы должны работать в среде, в которой правильное понимание ценится больше, чем быстрое. Есть рабочие места там, где это имеет значение.
Майкл Шоу
Работая в среде, где оба ценятся одинаково, среди всех, кто понимает это правильно - те, кто понимает это быстрее , бьют тех, кто понимает это медленнее. И я думаю, что я в последней группе.
ashes999
2
Хорошо, в этом случае, вероятно, дело в стратегиях, которые вы используете для написания, тестирования и отладки кода. спросите, можете ли вы соединить программу с «быстрым» программистом и посмотреть, как они организуют свои мыслительные процессы?
Майкл Шоу
1
@ ashes999: с практикой, опытом и терпением вы перейдете из второй группы в первую. Там нет волшебной таблетки, чтобы принять вас за одну ночь.
FrustratedWithFormsDesigner
12

Похоже, вы делаете все хорошие вещи - что в среднесрочной перспективе сделает вас быстрее, так что это не очевидно, если вы на самом деле медленный. Только ты действительно это знаешь. (но это вполне реальная возможность - PeopleWare заявляет о 10-кратной разнице в производительности между разработчиками для одной и той же задачи).

Итак, у меня есть несколько предложений для вас:

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

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

  3. Сделайте пару программ с разработчиком «быстрого качества», чтобы увидеть, можете ли вы заметить разницу.

Стивен Бейли
источник
8

По сути, все сводится к опыту . Быть быстрее в том, что вы делаете, - это как управлять автомобилем, изначально вы напуганы, поскольку другие - быстрые (или пьяные) водители (или оба), и вы хотите безопасно добраться до дома (с точки зрения программного обеспечения, вы хотите убедиться, что ваш код работает как разработано и работает хорошо).

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

В моем случае я изучил реальное использование шаблонов проектирования путем кодирования (даже @ home) и изучения использования некоторых из них. Таким образом, когда я сталкиваюсь с проблемой, которая требует шаблона проектирования, я использую прошлый опыт, чтобы увидеть, какие из них сработали, и почему это работает / не работает для моей ситуации.

В итоге:

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

PS: опыт также приходит от обучения у других. Например, помощь SO, парное программирование, экспертные оценки и т. Д. У вас не может быть опыта, если вы не можете оглянуться назад и учиться на ошибках (или если кто-то никогда не оспаривает ваши усилия).

Бухаке синди
источник
Я действительно надеюсь, что это не правильный ответ; Я уже много времени провожу за написанием кода и надеюсь, что мне чего-то не хватает, что даст мне существенное преимущество.
ashes999
@ ashes999, хорошо! с кодированием свободного времени, вы просматриваете свою работу? Я хочу сказать, что должно быть время, чтобы поработать над оптимизацией кода и освоить его. Мы можем все кодировать, но сколько раз мы даем себе время на оптимизацию?
Бухаке Синди
@TEG Я рассматриваю это между проектами; например. если бы я определенным образом что-то кодировал в проекте № 1, в аналогичном проекте № 2, я мог бы много поразмыслить о недостатках дизайна и рефакторинга.
ashes999
@ashes - «много рефакторинг» означает, что у вас есть время, потому что ваш первоначальный дизайн не был оптимальным. Если ваш начальник не знает, у вас есть проблема с объяснением, куда ушли часы. Если начальник знает, у вас есть проблема с объяснением того, почему ваш проект в первую очередь не был рассмотрен опытным сотрудником.
@TRA извините, я должен был указать - на хобби- проектах я много рефакторинг. На работе я слегка рефакторинг или создаю видимые задачи, чтобы мой менеджер знал, что я рефакторинг.
ashes999
8

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

Другими словами, являются ли ваши тщательно разработанные исправления ошибок настолько высокого качества (включая тестовые примеры и документацию), что они перевешивают затраты на обслуживание исправлений ошибок, сделанных вашими более быстрыми сотрудниками?

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

Если нет, то вам настоятельно необходимо рассмотреть, почему это так:

  • Вы слишком неопытны?
  • Вы тратите много-много времени на то, чтобы делать вещи, о которых вы не просили, которые, по вашему мнению, должны быть там?
  • Вам сложно определить, когда исправление закончено?
  • Ваш код более низкого качества, чем вы думаете?
  • Должны ли вы подходить к разработке кода по-другому, потому что вам нужно слишком много времени, чтобы начать работать так, как вы это делаете сейчас?
  • Вы потратили слишком много времени на такие вещи, как этот сайт?

Подумайте об этом и отредактируйте свой вопрос с помощью своих выводов.

user1249
источник
8

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

1) Никогда не прекращайте учиться: узнайте все, что можете о программировании и использовании компьютеров в целом. Найдите области, в которых вы слабы, и изучите их. Даже если это кажется совершенно не связанным с вашей работой и C #, я гарантирую, что если вы ищете его, вы часто найдете способы применить его к тому, что вы делаете. Обучение также связано с опытом, поэтому не просто читайте материал, но и попробуйте его и расширьте свои навыки. Если вы привыкли использовать Windows, попробуйте Unix или наоборот. Если вы обычно любите использовать IDE, попробуйте инструменты командной строки и текстовые редакторы или наоборот. Если вы слышали об инструменте или технологии, о которых вы раньше не слышали или о которых мало что знаете, не поддавайтесь искушению идти дальше. Поищи это! Не бойтесь мыслить нестандартно и изучать экспериментальные новые технологии, которые другие считают непрактичными;

2) Разбейте проекты: попробуйте разбить свои проекты на мини-проекты. Попытайтесь делать новый выпуск каждый день или не чаще, чем раз в несколько дней. Спросите себя: «Какой минимальный объем функциональности я могу выпустить, и все же выпустить что-то полезное для пользователя». Это навык, который вы выучите, выполнив его. Возможно, вам придется убедить ваших менеджеров позволить вам это сделать, но они, как правило, будут довольны результатами довольно быстро. Делая это, вы начнете замечать, что вещи, которые вы считаете важными для вашей функции, на самом деле являются дополнительными функциями, которые могут быть разработаны позже. Это позволяет вам и вашим менеджерам расставлять приоритеты только для наиболее важных функций вместо всех функций, связанных с той, над которой вы работаете. Это позволяет вам думать быстрее, сохраняя ясность и сосредоточенность. Вы в свою очередь законно будете программировать быстрее. Ваши менеджеры или, по крайней мере, менеджеры вашего менеджера, вероятно, также поймут, что вы сейчас программируете даже быстрее, чем на самом деле, потому что вы выпускаете больше релизов. Еще одним огромным преимуществом этого является то, что вы будете гораздо лучше оценивать, сколько времени потребуется для завершения релизов, и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. Менеджеры также, вероятно, поймут, что вы сейчас программируете даже быстрее, чем на самом деле, потому что вы выпускаете больше релизов. Еще одним огромным преимуществом этого является то, что вы будете гораздо лучше оценивать, сколько времени потребуется для завершения релизов, и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. Менеджеры также, вероятно, поймут, что вы сейчас программируете даже быстрее, чем на самом деле, потому что вы выпускаете больше релизов. Еще одним огромным преимуществом этого является то, что вы будете гораздо лучше оценивать, сколько времени потребуется для завершения релизов, и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное. и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с выполнением стабильных стабильных выпусков. Возможно, вам придется усилить вашу автоматизированную систему сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная доставка» в серии Мартина Фаулера. Это трудно читать, потому что это чрезвычайно повторяющееся, но все же очень полезное.

3) Используйте технику pomodoro и адаптируйте / измените то, что вам не подходит. Если вы объедините это с номером 2 в этом списке, вы получите ОГРОМНОЕ повышение производительности.

4) Изучите Vim. Даже если вы в конечном итоге будете использовать эти команды в Visual Studio через ViEmu, или из Eclipse через плагин, или из Emacs, вы получите повышение производительности. Лучший способ изучить Vim - это начать использовать его и заставить себя никогда (отключать его / возвращаться к старым инструментам), пока вы не овладеете им. Сначала это больно, но вам никогда не захочется отступать, и даже съеживаться, когда вам приходится работать без него. Кто-то скажет, что это не сильно увеличит вашу скорость. Но быстрее - быстрее, особенно когда чтение и изменение кода - это то, ЧТО МЫ ДЕЛАЕМ, и я иногда экономлю время на этом.

5) Последний вариант не обязательно рекомендуется, так как я не уверен, что это хорошая идея, и она может фактически снизить вашу производительность, но я все равно справлюсь с этим. Вы можете попытаться сделать больше приемочных тестов и меньше юнит-тестов, или, по крайней мере, убедиться, что вы делаете некоторые приемочные тесты. У меня был успех с SpecFlow, но я подозреваю, что есть что-то лучшее там. Даже написание спецификаций может быть довольно техническим, поэтому вам может потребоваться, чтобы ваш менеджер / клиент сначала написал черновую версию, в которую вы вносите существенные изменения, или вы можете написать все самостоятельно, просто прочитав их и подтвердив. Это поможет вам с номером 2 из этого списка. Также приемочные тесты могут быть более практичными и требуют меньше кода, чем модульные тесты. Нельзя сказать, что они заменяют их, разные инструменты для разных вещей.

6) Этот еще более экспериментальный и противоречивый. Я на самом деле не сделал это сам, поэтому я не могу точно рекомендовать это. Изучите и используйте систему метапрограммирования от JetBrains. Используйте его для создания инструментов, которые ваш менеджер / клиент использует для создания нужного программного обеспечения. Возможно, вы даже сможете прекратить выполнение модульных и приемочных тестов, если сможете использовать их для создания инструментов, которые ваш менеджер / клиент использует для определения поведения очень простым и не запутанным способом. Идея не в том, чтобы избавиться от программиста. Программистам по-прежнему необходимо добавлять новые функции в эти инструменты, используемые клиентом / менеджером, всякий раз, когда они (люди, а не инструменты) не могут легко создать желаемую функциональность. Я верю, что MPS или другие подобные ему инструменты - путь будущего.

оборота INTPnerd
источник
5

Используйте свой мозг больше и меньше тестируйте. Если честно, у тестирования есть свое место, но оно дорогое.

Кроме того, прочитайте Искусство программирования Unix (бесплатно онлайн, книга стоит цена)

Наконец, вы не можете быть в нужном месте. Круглый колышек на квадратной работе и др.

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

Кристофер Махан
источник
3
Тестирование делает меня быстрее, а не медленнее. Меньше тестирования означает, что больше регрессий остаются незапятнанными дольше и их сложнее исправить, потому что вы не можете сделать большие скачки в коде из-за страха «что-то может сломаться».
ashes999
Автоматизированное тестирование для меня - это запах кода. Это означает, что код не был достаточно простым.
Кристофер Махан
6
Если ваш код настолько прост, что ему не нужны тесты, он не делает ничего интересного.
Рейн Хенрикс
Как вы знаете, точно? О, если снова ... Я отошлю вас к правилу модульности: напишите простые части, соединенные чистыми интерфейсами. (из «Искусство программирования Unix»)
Кристофер Махан
Я думаю, у тебя есть что-то, Кристофер. Именно здесь ashes99 проводит много времени, например, «убил». Слишком много всего плохого. В этом случае, если вы не исправляете код для систем управления полетом, вы можете пересмотреть количество тестов, которые вы проводите. Или зайдите в такую ​​область.
user21007
5

Если вы возьмете большой законченный проект и получите количество «окончательных» строк кода на человека в час, вы обнаружите, что программисты кодируют НАМНОГО медленнее, чем вы могли себе представить.

Мы говорим всего несколько строк кода в день. Остальное время вы тратите на отладку, переписывание и выполнение общих задач программиста.

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

Так как ты ускоряешь это? Я не стал бы концентрироваться на какой-либо форме скорости набора текста - сокращение ошибок и улучшение других «будущих взаимодействий» с вашим кодом должно быть гораздо более выгодным вложением вашего времени.

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

Парное программирование может сократить время QA и, если учесть, что один программист производит всего несколько строк в день, если две могут кодировать с той же скоростью, что и одна, но с меньшим количеством ошибок, тогда вы НАХОДИТЕСЬ впереди.

Защитное кодирование (например, проверка параметров) может уменьшить проблемы ... Если в вашей команде действительно хороший аналитик / архитектор, вы можете сэкономить время с хорошим начальным дизайном.

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

Билл К
источник
3

Рассматривали ли вы сделать подробный аудит себя, как вы работаете? Либо ручкой и бумагой отслеживайте, как вы проводите свое время, либо используйте что-то вроде Rescue Time, чтобы отследить себя.

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

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

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

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

Если ничего другого, это дает вам некоторые ориентиры, с которыми вы можете работать.

DKnight
источник
3

Из твоего списка у тебя все хорошо.

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

Не пишите код, который более CRAP, чем вы должны. ;)

Единственное, что я могу предложить вам - это использовать библиотеки, не пишите их, если:

  1. Ваша компания продает библиотеки
  2. Вы переработали повторяющийся код в библиотеку

Вы читаете и делаете, и это здорово. Но вы можете застрять, думая о процедурном или ОО-коде. Вы подвергались функциональному программированию (скажем, на Haskell?) И Прологу?

Чтобы отточить свою технику программирования ОО, вы играли с Smalltalk / Squeak?

И наконец, теория. У вас есть хотя бы элементарное понимание теории графов? (Некоторые программы в какой-то момент работают с деревьями, DAG или просто с простыми графами. Сети - это графы)

Тим Виллискрофт
источник
Здесь много замечательных моментов. Мне нужны библиотеки, потому что мне нужна функция для игры X (например, хранилище Silverlight для нескольких сессий моей игры), и я могу сказать, что они понадобятся нам позже - или это просто абстрактный код (например, поиск пути), который не имеют ничего общего с моей игрой. У меня есть опыт работы в области компьютерных технологий, поэтому я выполнил процедурный, ОО, функциональный и другой (Пролог). Теория графов, да; Рекурсия графа в глубину, которую я использовал очень часто, как ни странно.
ashes999
3

Насколько я знаю, это:

  1. хороший
  2. быстрый
  3. дешево

Как менеджер, вы можете выбрать любой 2.

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

Нико
источник
2

Основные вещи, о которых я могу думать, следующие

  • Увеличьте скорость печати.
  • Используйте инструменты, которые обеспечивают повышение производительности. Например ReSharper.
  • Быстрее машины или инструменты. Нравится больше оперативной памяти или твердотельный накопитель.

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

mpenrow
источник
Я нахожусь на равных с моими коллегами по этим вопросам (возможно, у меня есть преимущество в скорости печати); они все еще быстрее, так или иначе. Опыт, может быть?
ashes999
1
Выше определенного минимального минимума «охота и пек» скорость печати не является ограничивающим фактором.
2
Вы могли бы быть на одном уровне с ними , имеющими инструменты (например, ReSharper), но вы знаете , как эффективно использовать их? Я видел, как многие люди устанавливают Resharper, а потом не учатся использовать 80% функций. В этом отношении убедитесь, что вы понимаете все функции рефакторинга и ярлыков в Visual Studio. Я легко получаю преимущество в 2-3% по сравнению с кем-либо еще в моем офисе, просто держась за руки в течение всего дня. Мыши медленные :)
EZ Hart
@EZ Харт: Очень хорошая мысль. В некоторых современных IDE (я думаю об Eclipse, вне головы) есть очень мощные инструменты для рефакторинга, поиска ссылок на код (например, где находится ссылка на класс или метод, а не просто где появляется текст «myMethod»). ). Для некоторых из этих «продвинутых» функций стоит потратить 5 минут на изучение, чтобы иметь возможность гораздо более эффективно управлять базой кода.
FrustratedWithFormsDesigner
Мы все на уровне. Ни у кого из нас нет инструментов :)
ashes999
2

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

Как насчет генераторов кода? Иногда код становится повторяющимся. Рефакторинг может удалить некоторые из них, но даже тогда у вас могут быть повторяющиеся вызовы одной и той же рефакторированной функции. В зависимости от данных и кода, с которыми вы работаете, генераторы кода (написанные в Excel, Perl, Java и т. Д.) Могут сэкономить много времени. И использование инструментов генерации кода для разработки пользовательского интерфейса обычно не составляет труда.

И, наконец, возможно, метрики неверны. Рассматривали ли вы , что вы кодирование в fasteset возможной скорости данной все остальное, и что сроки слишком коротки, что делают вас появляется , чтобы быть медленным кодером?


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

Или ... получите больше опыта и практики в конкретной области, чтобы вы знали кодовую базу и API так хорошо, что могли бы кодировать решения во сне. Это можно сделать, но требует больше времени. Если другие разработчики, которые работают быстрее вас, как известно, являются более старшими и более опытными, тогда остается сделать только одно - вы должны стать старше и опытнее!

FrustratedWithFormsDesigner
источник
Это не сроки; другие сотрудники могут выполнять ту же работу быстрее. Может быть, это опыт. +1 за скорость печати; Я могу набрать около 100WPM, так что это тоже не так.
ashes999
@ ashes999: и если люди, которые могут выполнять ту же работу быстрее, более опытны, то вы, вероятно, выиграете больше всего от большего опыта работы с этими системами. Опыт требует времени ...
FrustratedWithFormsDesigner
генераторы кода - смешанное благо. Они могут сэкономить ваше время, но если вам придется тратить слишком много времени на сгенерированный код, экономия может превратиться в неуправляемую потерю.
2

У меня есть возражение против представления "жертвенного качества за скорость".

Профессиональные программисты (программисты) должны выполнить 3 задачи:
1) код должен работать так, как задумано;
2) доставка должна быть в срок;
3) иметь хорошее качество, документацию и т. Д.
4) другое и т. Д.

Я думаю, OP был обвинен как медленный, вероятно, потому что OP не сделал вовремя.

9dan
источник
2

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

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

Я обнаружил, что письма разъедают гораздо больше, чем я думал, просто из-за прерывания. Теперь я отвечаю только на письма два раза в день и за несколько дней набрал почти 1 час производительности. Попробуйте такие методы, как pomodoro , я использовал его как средство измерения. Через равные промежутки времени (15 минут) я записывал то, что делал в то время. Это позволило мне увидеть, как устроены мои дни и что я могу сделать, чтобы максимизировать эффективность.

Newtopian
источник
Значит, вы говорите, что любезны по образцу? Интересно. :)
sum1stolemyname
на самом деле это был побочный эффект метода отслеживания времени, который я пробовал некоторое время ( davidseah.com/tools/ett/alpha ). Выяснилось несколько интересных и неожиданных тенденций в области данных, когда я начал смотреть на них за пределами трекера времени. Именно после того, как я узнал о помодоро, GTD и подобных.
Newtopian
0

Преимущество Squeak для быстрого кодирования выходит далеко за рамки простого «оттачивания навыков ООП». Есть причина, по которой современные графические интерфейсы, а также IDE были изобретены на Smalltalk, не говоря уже о том, что JUNIT был портом SUNIT для Java, термин «ООП» был изобретен для описания Smalltalk и т. Д., И т. Д.

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

user22340
источник