sivabur
@sivabur
Заблокировали просто так!

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

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

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

Ответы нужен опыт не принимаются!(это как бы и так понятно что чем больше опыт тем быстрей я буду создавать код).
  • Вопрос задан
  • 1582 просмотра
Решения вопроса 4
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Учить ООП и стандарты.
UPD: нужна архитектура, основанная на функциональных блоках, независящих от конкретного проекта. (что-то типа "детского" конструктора, где из 7-8 блоков можно сделать красивый домик)

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

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

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

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

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

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

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

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

P.S. Не помню точно, может как раз у Макконнелла сказано, что программист на работу непосредственно с кодом тратит 20% времени. Остальные 80% заняты обдумыванием.
Так что логичнее тренировать голову, а не руки.
Ответ написан
Комментировать
angrySCV
@angrySCV
machine learning, programming, startuping
как и в любом другом искусстве мастерство (в том числе и скорость) складывается из множества деталей.
посредственным программистам они могут казаться не значительными, даже появляются фразы типа слепой метод печати НИНУЖОН, овер9000% обдумываем архитектуру, рисуем схемки на бумаге, и тд. Это всё оправдания.

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

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

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

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

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

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

и да все эти вещи приходят исключительно с многолетним опытом.
Ответ написан
Комментировать
vt4a2h
@vt4a2h
Senior software engineer (C++/Qt/boost)
Скорость создания именно качественного кода (под этим я подразумеваю сопровождаемый код, который решает актуальную задачу) напрямую зависит от трёх вещей:
1) Понимание задачи
2) Знание предметной области
3) Владение существующей кодовой базой

Остальное (скорость набора, IDE, снипеты и т.д.) уже вопрос удобства. Всё это конечно здорово облегчает жизнь, но далеко не так важно.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
@protven
Наймите 3-4-5 высококачественных программистов. Становитесь менеджером, в общем.
Ответ написан
In4in
@In4in
°•× JavaScript Developer ^_^ ו°
Тренировать память и запоминать краткие имена переменных,

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

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

Забыть про слепой набор.
Ответ написан
heksen
@heksen
Просто сидеть и писать качественный код. Уделять больше времени. И всё норм.
Ответ написан
Комментировать
@ollisso
1. забыть про скорость набора после "определённого уровня".

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


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

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы