Как создавать качественый код в 3-4-5 раз быстрей?

Question

[sivabur]

-снипеты(стандартные+свои заготовки наиболее часто используемых и шаблонных конструкций)
-слепой набор(с большой скоростью)
-писать само документирующий код(чтоб не писать много комментариев)
-сперва накидать общую логику на бумаге
-четкий план какие функции надо реализовать и в какой по очередности

Какие еще есть варианты?
UDP:
Вопрос касательно одного разработчика (вне зависимости от языка программирования ну возьмем топ10).

Ответы нужен опыт не принимаются!(это как бы и так понятно что чем больше опыт тем быстрей я буду создавать код).

Comments

[Валерий Рябошапко]

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

[sivabur]

Валерий Рябошапко: мне кажется все таки это не совсем так.(прироста как у художественного не будет но все же какой то прирост будет не надо отвлекаться на клавиатуру)

Answer 1

[xmoonlight]

Учить ООП и стандарты.
UPD: нужна архитектура, основанная на функциональных блоках, независящих от конкретного проекта. (что-то типа "детского" конструктора, где из 7-8 блоков можно сделать красивый домик)

Тогда Вы сможете их вставлять в нужном порядке и тем самым, экономить время на создании обработчиков, за счет использования УЖЕ РЕАЛИЗОВАННЫХ ВАМИ функциональных блоков.

Comments

[Максим Мосейчук]

А если мы на Haskell/OCaml/Closure/Scala/Erlang пишем? Тоже ООП учить?

[sivabur]

fshp: стандарты думаю тоже учить надо. В Scale - есть ООП. Ну наверное имеется виду там топ 5-10 языков.

[⚡ Kotobotov ⚡]

я так понимаю вопрос не про то как научиться программировать, уверен человек уже умеет и знает.

Answer 2

[Дмитрий Макаров]

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

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

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

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

Итого: алгоритмы и структуры, паттерны проектирования, слабо связанный тестируемый читаемый код, тесты, внедрение зависимостей, git + git-flow, знание надежных библиотек и фреймворков и умение их применять.

Макконнелл. Совершенный код.

Симан. Внедрение зависимостей с .NET

Банда четырех. Паттерны проектирования.

P.S. Не помню точно, может как раз у Макконнелла сказано, что программист на работу непосредственно с кодом тратит 20% времени. Остальные 80% заняты обдумыванием.
Так что логичнее тренировать голову, а не руки.

Answer 3

[⚡ Kotobotov ⚡]

как и в любом другом искусстве мастерство (в том числе и скорость) складывается из множества деталей.
посредственным программистам они могут казаться не значительными, даже появляются фразы типа слепой метод печати НИНУЖОН, овер9000% обдумываем архитектуру, рисуем схемки на бумаге, и тд. Это всё оправдания.

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

такой подход называют ещё решением "сверху вниз", когда ты сразу описываешь как программа должна в общем работать постепенно углубляясь в реализацию деталей.
программисту в 2015 году, стыдно должно быть рисовать какие-то диаграммки от руки, имея генераторы UML диаграмм (в intellij IDE например встроенный генератор схем есть).
учитесь описывать структуру и схемы работы сразу в коде, а не наоборот.

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

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

и это всё НЕ ерунда, это те детали из которых складывается ваша скорость, и качество программирования. Tо там потерял 5 минут, то здесь провозился со схемкой на бумаге, то писал простой метод в течении 2 минут вместо 15 секунд.
И в итоге, некоторые пишут программу в течении 2х недель, а кто-то туже самую программу за 2 часа...

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

и да все эти вещи приходят исключительно с многолетним опытом.

Answer 4

[Vitaly]

Скорость создания именно качественного кода (под этим я подразумеваю сопровождаемый код, который решает актуальную задачу) напрямую зависит от трёх вещей:
1) Понимание задачи
2) Знание предметной области
3) Владение существующей кодовой базой

Остальное (скорость набора, IDE, снипеты и т.д.) уже вопрос удобства. Всё это конечно здорово облегчает жизнь, но далеко не так важно.

Answer 5

[protven]

Наймите 3-4-5 высококачественных программистов. Становитесь менеджером, в общем.

Comments

[sivabur]

Ну пока вопрос за меня)) конкретно за человека который создает код. Скорость ихнего создания кода тоже важна.

Answer 6

[Виталий Инчин ☢]

Тренировать память и запоминать краткие имена переменных,

Юзать хорошие редакторы текста - с подсказками при наборе и т.п,

Использовать рекурсию,

Забыть про слепой набор.

Comments

[sivabur]

а слепой набор чем не угодил?)(т. е. и скорость набора на нем више как и потолок скорости)

[Виталий Инчин ☢]

sivabur: вероятность ошибок при наборе увеличивается, хотя если вы ультра-про-набиратор... =)

[sivabur]

и что подрузумевается под "Тренировать память" т. е. как это поможет?И что конкретно надо запоминать?

[Виталий Инчин ☢]

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

[sivabur]

Виталий Инчин: это скорей всего стандарты регламентируют)как и что называть сокращать или не сокращать.
Ну в целом да лучше сокращать и как то стандартизировать)

[Алексей Уколов]

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

[sivabur]

Алексей Уколов: можете пример реализации показать и объяснить что это?

[Алексей Уколов]

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

[sivabur]

Алексей Уколов: понял благодарю за пояснения в прицепе знал)но использовал очень редко.

[sivabur]

Насчет рекурсии сильно поможет в ускорении?Или лучше от нею отказываться в пользу циклов?

[Алексей Уколов]

Как вообще рекурсия может помочь в этом вопросе, кстати говоря?

[Виталий Инчин ☢]

Алексей Уколов: как? Сократить код! В некоторых ситуациях, задача расписанная через циклы на кучу строк может решится всего парой, но с использованием рекурсии.

[Алексей Уколов]

А в некоторых - нет. Говорить, что рекурсия - это универсальное решение для быстрого написания хорошего кода, совершенно неверно.

[sivabur]

В прицепе дельной замечания где это возможно и целесообразно не в ущерб производительности использовать рекурсию. А то ее редко используют. Даже в тех местах где это целесообразно делать.

[Виталий Инчин ☢]

Алексей Уколов: я и не утверждал, что ее нужно совать везде, где не попадя - лишь "В некоторых ситуациях", но главное - просто не забывать о ее существовании :)

Answer 7

[Ilya Bobkov]

Просто сидеть и писать качественный код. Уделять больше времени. И всё норм.

Answer 8

[Oleg]

1. забыть про скорость набора после "определённого уровня".

"определённый уровень":
1. ты можешь писать смотря в экран и одновремённо думать о том, как программа будет работать.
2. на клавиауру вообще не смотришь, чувствуешь её на ощупь, т.е. фактически голова говорит "напиши слово", и пальцы сами работают, а голова в этот момент думает о печеньках :)


Если ты можешь печатать и при этом думать о клавиатуре - структуре функции/кода - можно дальше не ускоряться.

Причина почему дальше безсмысленно:
особого прироста не будет.
основное время идёт на продумывание структуры/архитектуры, а не на сам код.

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

Причина:
читать и понимать этот код придётся ещё не 1 раз.

3. лёгкие для понимания названия переменных, функций, классов.

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