Недавно задумался и понял, что значительно увеличил скорость разработки благодаря быстрой печати, борьбе с перфекционизмом, фреймворкам, хорошей IDE, баш скриптам, улучшению удобства рабочего места т.п..
Этого было достаточно, но появилась масса крупных задач, и нет сил все это делать.
Слышал есть различные методики для более эффективной разработки, например экстремальное программирование.
Посоветуйте методику разработки, которую используете вы. Благодарю.
Рональд Макдональд, весь результат состоит из таких тонкостей. На продуктивность влияет все, мышь, клавиатура, стол, кресло, мониторы и их качество, знание максимального количества хоткеев для решения типичных задач, знание всех возможностей IDE, как например автоматический рефакторинг кода и многое другое.
Бгг.
а что с быстрой печатью не так? в разработке мало творчества, а много как раз рутины
слепая печать сокращает временной интервал между "идея!" и "работает!", а это дополнительная мотивация
ну и второй монитор, наверное ))
Написано
Saboteur
@saboteur_kiev Куратор тега Организация работы
Ну не знаю. Быстрая печать мало помогает. Слепая - да, помогает сильно. Но она может быть не быстрой, а просто достаточной. 200-300 символов в минуту на тренажере - более чем достаточно, тем более что в IDE редко пишешь именно литературный текст.
Saboteur, а написание всяких отчетов, комментов в жире, всяких там переписок с клиентом/пиэмом? Это ведь тоже часть работы, и тут как раз быстрая печать сокращает время на такую обязательную рутину.
Написано
Saboteur
@saboteur_kiev Куратор тега Организация работы
lukoie, как я уже выше сказал, если на тренажере 200-300 символов в минуту есть - этого более чем достаточно. Важно, чтобы это была слепая печать.
Быстрее - нет смысла. Надо же думать, что печатаешь, особенно в чате.
Создать свой конструктор для построения проектов под любые требования.
Любой функционал - пишем однократно! и используем потом во всех последующих проектах как подключаемый модуль.
Делаю так: разбиваю ТЗ на функц.блоки, рисую схему движ.данных, смотрю: что уже готово, а что - кодить.
Компоную блоки так, чтобы захватить бОльшую часть нужного и возможного функционала в новые блоки, не потеряв в производительности.
Снова проверяю структуру (и все нюансы) и только потом - кодирую.
composer пакеты с версионностью гораздо проще использовать в других проектах. В том числе подтянутся зависимости нужных версий.
Для обновления кода достаточно выполнить одну команду.
Снипеты тоже хорошая штука, но только в каких-нибудь мелочах
dimonchik2013, Дмитрий Байбухтин, ни то, ни то - не проще.
Проще - использовать структуру директорий, согласно сделанной архитектуре и размещать блоки кода (файл или несколько файлов в одной папке), которые подхватываются управляющим архитектурным кодом в нужный момент автоматически.
Использовать для сборки проекта всякие там композеры - это абсолютно ненужное усложнение процесса сборки, и вдобавок ко всему, это привлечение стороннего ПО к обработке вашего исходного кода.
Управляющий архитектурный код - как раз за всё это и отвечает.
xmoonlight Во-первых это не усложнение, а упрощение, если понимать для чего он нужен.
Во-вторых, код выносит в пакеты композера, что бы разрабатывать один раз, а использовать во всех проектах
Эффективное распределение своего времени. Планирование задач перед ее выполнением, планирование экономит время, есть такая пословица: минута час бережет. Одна минута, потраченная на планирование, экономит от 10 до 12 минут при исполнении.
Ни одна задача не бывает слишком трудной, если разделить ее на множество достаточно мелких частей. Чем больше вы учитесь/делаете тем лучше функционирует ваш мозг, в результате чего вы становитесь умнее, соответственно чтобы разрабатывать быстрее нужно разрабатывать больше.
По поводу планирования, я знал об этом и раньше, но все то забывал, то забивал.
Благодарю, нужно учиться планировать перед выполнением задач. Правда экономит массу сил и времени.
Иначе все держишь в голове и мало того, что программируешь дольше, так еще и устаешь гораздо сильнее.
Помню в исключительных случаях приходилось в 4 утра доделывать крупные задачи, и если я до этого вечером не продумывал решение, не описывал план, то это было крайне тяжело, а в обратном случае запросто.
Итого, лучше сначала продумать решение задач, описать план и затем программировать
Developer, Это нормальный и правильный подход, зачем писать один и тот же код много раз. Если можно скопировать и при необходимости подправить нужное, тем самым сократить время на написание того же самого. Некоторые программисты на определенных языках даже пишут свои библиотеки утилит,хелперов если в языке нет конструкций помогающих решать определенные ситуации. Это не шутка, это действительность
Некоторые программисты на определенных языках даже пишут свои библиотеки утилит,хелперов если в языке нет конструкций помогающих решать определенные ситуации. Это не шутка, это действительность
Это здесь при чём? Это к копипасте не имеет никакого отношения.
Если ты до сих пор ещё пользуешься копипастой, то ты либо юный новичок, не столкнувшийся с проблемами копипасты, либо непрофессионал, который даже минимальных для программиста книг не читал, где о копипасте говорится как об очевидном зле и объясняется почему.
Читай книги.
А лучше покажи свой говнокод с копипастой, если такой смелый.
twobomb, ты уж определись, копипаст это хорошо или плохо :)
А если будешь хорошо себя вести, я расскажу тебе про модули и функции. И как с их помощью можно повторно использовать код без этих волшебных сочетаний клавиш.
FanatPHP, Ааа ну началось оправдание, тоесть модули и тем более функции если копировать это не копипаст? Так там почти ничего и не остается копировать. Developer,
Это здесь при чём? Это к копипасте не имеет никакого отношения.
, это к копипасте имеет прямое отношение, когда программист пишет модуль, динамическую библиотеку, библиотеку,пусть даже будет какой нибудь com объект, кто как изващается, а потом просто использует его в других своих проектах, дополняя и расширяя его, тоесть тупо копирует свои наработки. И только не нужно мне здесь сейчас писать что вот в моей [язык на котором вам довелось программировать] это делается с помощью [средства которые вы используете для подключения различного рода зависимостей] именно вот так. Здесь не было речи о каких то конкретных языках, так как везде это делается по разному, где то тупо ctrl+c ctrl+v файла, где нужно в конфиге сборщика прописать, где то нужно еще какие нибудь танцы с бубном устроить.
Я свое сообщение написал быстро и не собирался расписывать как конкретно это нужно делать, конкретно на вашем языке на котором вы программируете. Опытный программист сам решит как правильно нужно организовать копипасту. Так как вы FanatPHP, Developer, люди не далекие и понимаете всё буквально, вам сразу в голову пришло, что нужно там какой-то кусок кода копировать и вставлять, это ограниченность вашего мышления, читайте больше книг. Не напрягайтесь, расслабьтесь. Удачи!
Без описания задачи невозможно дать ответ.
Потому что он таки очень сильно зависит от типа задач.
Судя по формулировке вопроса и принятому ответу, задача - boilerplate разработка по паттернам "фигак-фигак - и в продакшен" и "отдал заказчику и забыл". В этом случае использование конструктора сайтов действительно является адекватным ответом. Рекомендую проверенное временем решение - вордпресс.
Если же задача состоит в работе над одним крупным проектом, включая в себя поддержку существующего функционала и добавление нового, то тут ответ банален - учить ООП и фреймворки, TDD. Они как раз и придуманы для того, чтобы сделать работу программиста "творческой", позволяя сосредоточиться на алгоритмах, а не технической реализации. И также позволяя вносить правки в существующий функционал минимальными усилиями. О чем некоторые комментаторы здесь не подозревают, искренне полагая что залогом производительности является скорость нажатия на клавиши crtl-c, ctrl-v
Согласен, но все же нужно иметь компромис между скоростью и качеством. Иначе в будущем потеряешь много времени на разбор говна, которого наделал раньше.
