Недавно задумался и понял, что значительно увеличил скорость разработки благодаря быстрой печати, борьбе с перфекционизмом, фреймворкам, хорошей IDE, баш скриптам, улучшению удобства рабочего места т.п..
Этого было достаточно, но появилась масса крупных задач, и нет сил все это делать.
Слышал есть различные методики для более эффективной разработки, например экстремальное программирование.
Посоветуйте методику разработки, которую используете вы. Благодарю.
Рональд Макдональд, весь результат состоит из таких тонкостей. На продуктивность влияет все, мышь, клавиатура, стол, кресло, мониторы и их качество, знание максимального количества хоткеев для решения типичных задач, знание всех возможностей IDE, как например автоматический рефакторинг кода и многое другое.
Бгг.
а что с быстрой печатью не так? в разработке мало творчества, а много как раз рутины
слепая печать сокращает временной интервал между "идея!" и "работает!", а это дополнительная мотивация
ну и второй монитор, наверное ))
Написано
Saboteur
@saboteur_kiev Куратор тега Организация работы
Ну не знаю. Быстрая печать мало помогает. Слепая - да, помогает сильно. Но она может быть не быстрой, а просто достаточной. 200-300 символов в минуту на тренажере - более чем достаточно, тем более что в IDE редко пишешь именно литературный текст.
Saboteur, а написание всяких отчетов, комментов в жире, всяких там переписок с клиентом/пиэмом? Это ведь тоже часть работы, и тут как раз быстрая печать сокращает время на такую обязательную рутину.
Написано
Saboteur
@saboteur_kiev Куратор тега Организация работы
lukoie, как я уже выше сказал, если на тренажере 200-300 символов в минуту есть - этого более чем достаточно. Важно, чтобы это была слепая печать.
Быстрее - нет смысла. Надо же думать, что печатаешь, особенно в чате.
Создать свой конструктор для построения проектов под любые требования.
Любой функционал - пишем однократно! и используем потом во всех последующих проектах как подключаемый модуль.
Делаю так: разбиваю ТЗ на функц.блоки, рисую схему движ.данных, смотрю: что уже готово, а что - кодить.
Компоную блоки так, чтобы захватить бОльшую часть нужного и возможного функционала в новые блоки, не потеряв в производительности.
Снова проверяю структуру (и все нюансы) и только потом - кодирую.
composer пакеты с версионностью гораздо проще использовать в других проектах. В том числе подтянутся зависимости нужных версий.
Для обновления кода достаточно выполнить одну команду.
Снипеты тоже хорошая штука, но только в каких-нибудь мелочах
dimonchik2013, Дмитрий Байбухтин, ни то, ни то - не проще.
Проще - использовать структуру директорий, согласно сделанной архитектуре и размещать блоки кода (файл или несколько файлов в одной папке), которые подхватываются управляющим архитектурным кодом в нужный момент автоматически.
Использовать для сборки проекта всякие там композеры - это абсолютно ненужное усложнение процесса сборки, и вдобавок ко всему, это привлечение стороннего ПО к обработке вашего исходного кода.
Управляющий архитектурный код - как раз за всё это и отвечает.
xmoonlight Во-первых это не усложнение, а упрощение, если понимать для чего он нужен.
Во-вторых, код выносит в пакеты композера, что бы разрабатывать один раз, а использовать во всех проектах
