Comments 32
Главный совет — гуглить. Причем не готовые решения.
А как составить запрос в гугле что бы он не показывал готовые решения?
«Windows open file» ведет на MSDN, например.
Вместо windows лучше сразу писать "msdn open file". Для поиска по Mozilla Developer Network пишем "mdn open file".
Это уже следующий уровень гугления ;-)
Следующий — это зайти на msdn.com и в поиске msdn вбить CreateFile
А вы сравните два способа, через google и через msdn.com)
Google: в адр. строке "msdn CreateFile" [Enter] [Tab] (первый результат) [Enter] и вы уже на странице.
Msdn.com: в адр. строке "msdn.com" [Enter] [ Мышкой кликаем на поле пoиска] ["CreateFile"] [Enter] [Мышкой кликаем на первый результат].
Сравнили? И как вам, к тому же, скорость загрузки msdn?)
Гуглить готовые решения — это не проблема (более того — это здорово ускоряет работу).
Проблема, если бездумно копировать эти решения в свой код.
Любой найденный код в интернете нужно адаптировать и брать… Т.е. иногда из готового решения тебе нужна только одна «правильная» строчка кода.
Ещё одна частая проблема начинающих разработчиков — подключать внешнюю библиотеку на каждый чих.
Проблема, если бездумно копировать эти решения в свой код.
Любой найденный код в интернете нужно адаптировать и брать… Т.е. иногда из готового решения тебе нужна только одна «правильная» строчка кода.
Ещё одна частая проблема начинающих разработчиков — подключать внешнюю библиотеку на каждый чих.
ИМХО гуглить и готовые решения. Обычно решений либо не предлагается совсем, либо предлагается очень много. Первый случай не означает, что нужных решений нет. Скорее всего неверно сделан запрос. Во втором случае программисту поневоле придется вникать в решения, сравнивать их, чтобы выбрать оптимальное для своей задачи. Конечно, бывают халтурщики, которые из множества найденных решений выбирают одно случайным образом. Поэтому я бы посоветовал: гуглить не халтуря! Готовое решение хорошо тем, что можно разобраться в деталях, которые авторы многих «неготовых решений» опускают, считая очевидными и малозначительными. Кроме чтения кода и описания к нему (если таковое есть) очень полезно погонять решение под отладчиком и посмотреть шаг за шагом, как оно работает. Далее полезно бывает поэкспериментировать с этим решением внося изменения в код. Попробовать найти контр-пример, чтобы решение обвалилось. Так повозившись с несколькими готовыми решениями нередко придумываешь свое лучшее решение.
Так и во многих книгах по программированию автор приводит готовое решение и анализирует его, объясняя читателю чуть ли не каждую строчку кода.
Так и во многих книгах по программированию автор приводит готовое решение и анализирует его, объясняя читателю чуть ли не каждую строчку кода.
У опытного программиста есть скрипт stackoverflow.sh, которому можно скормить ТЗ, а на выходе получить готовый проект надерганный из постов на stackoverflow.com
Вы таки будете смеяться. Правда, не stackoverflow.sh, а howdoi.py.
Я бы поспорил с тем, что короткий код категорически всегда лучше и профессиональнее. Кто из нас не видел написанные в одну строку write-only конструкции, призванные показать крутость «а я вот так могу»? Я бы наоборот рассматривал аккуратную декомпозицию сложного действия в несколькострочный список коротких операций (да еще и с комментариями) как признак более опытного разработчика.
Тут нужен баланс… Код должен быть настолько коротким, насколько это возможно без потери выразительности, но не короче :-)
Кто из нас не видел написанные в одну строку write-only конструкции, призванные показать крутость «а я вот так могу»?
Вы правы, но никто и не утверждал обратное. Ясное дело, что лепка костылей в одну строку приводит к нечитабельности. А в статье говорилось о ёмком и понятном коде.
Можно сформулировать так: «Краткость — сестра таланта, ясность — сестра понимания».
Тут скорее имеется не умение максимум логики уложить в минимум строк, а найти самое короткое решение задачи. А за излишнюю декомпозицию, в сособенности продиктованную прямолинейным single responsibility, иногда хочется прибить. Частенько люди решающие простую и неинтересную задачу, находят интерес в заведомом усложнении решения. 90% багов находится в связях между сущностями. Много сущностей — много кода — много связей — много багов — долгая разработка — долгая стабилизация — интересно делать любую задачу.
На первом курсе я думал, что для программиста нужен определенный склад ума, умение анализировать и составлять алгоритмы.
На втором курсе, я пошел работать интерном и думал, что для программиста нужно много и долго читать Страуструпа
На четвертом курсе, я перешел инженером-разработчиком и понял, что главное засыпать под подкасты Java Posse, ставить окружение и гуглить.
Каждый год приносил мне новое понимание, что нужно программисту.
На данный момент, лично я считаю, что самые банальные советы — самые правильные.
Первый совет — постоянно развиваться и быть в курсе всех изменений в своей основной области.
Второй совет — смотреть, что тащишь с гугла.
На втором курсе, я пошел работать интерном и думал, что для программиста нужно много и долго читать Страуструпа
На четвертом курсе, я перешел инженером-разработчиком и понял, что главное засыпать под подкасты Java Posse, ставить окружение и гуглить.
Каждый год приносил мне новое понимание, что нужно программисту.
На данный момент, лично я считаю, что самые банальные советы — самые правильные.
Первый совет — постоянно развиваться и быть в курсе всех изменений в своей основной области.
Второй совет — смотреть, что тащишь с гугла.
Код пишет один, а читают и поддерживают его многие. Так что на первом месте должна быть простота, понятность, прогнозируемость, слабая связанность (чтобы в случае чего код можно было безопасно переписать или выкинуть не затрагивая другие компоненты) и дружелюбие к дебагингу. А вот во сколько строк кода это выльется — это уже второстепенное. Уж лучше читать простой, прогнозируемый, линейный код хоть и с небольшим копипастом, чем писанину и дизайн в стиле «смотри как я могу!».
Вот мои правила.
1. Исходный код пишется не для компьютера, а для людей.
2. Документировать/кормментировать код, писать документацию для разработчика (как запустить программу на отладку, где смотреть логи и т.д.), делать скриншоты. (со скриншотами всегда заморочка, а где их хранить? Я предпочитаю выложить изображение скриншота на фотохостинг, а в код кинуть ссылку на скриншот).
3. Если я использую код, найденный в интернете, то даю ссылку перед этим кодом, что код взят оттуда-то, чтобы читающий мог перейти и глянуть в каком контексте это было использовано там, да и описание почитать будет не лишним.
4. Радуюсь, что оставил комментарий, ссылку или скриншот к запутанному месту в своём коде через полгода.
1. Исходный код пишется не для компьютера, а для людей.
2. Документировать/кормментировать код, писать документацию для разработчика (как запустить программу на отладку, где смотреть логи и т.д.), делать скриншоты. (со скриншотами всегда заморочка, а где их хранить? Я предпочитаю выложить изображение скриншота на фотохостинг, а в код кинуть ссылку на скриншот).
3. Если я использую код, найденный в интернете, то даю ссылку перед этим кодом, что код взят оттуда-то, чтобы читающий мог перейти и глянуть в каком контексте это было использовано там, да и описание почитать будет не лишним.
4. Радуюсь, что оставил комментарий, ссылку или скриншот к запутанному месту в своём коде через полгода.
Согласно опросу на Hacker News, многие программисты до сих пор делают записи в блокнотахПредпочитаю использовать для этого обычный MS Word. Сначала записываю порядок основных действий, которые должна сделать программа, потом детализирую. (На бумаге часто не хватает места, чтобы вставить несколько строчек, приходится делать вставки-указатели, что может запутать запись.) Каждую строчку стоит начинать с "//". Переходя к кодингу сохраняю файл как «текст с разбиением на строки». Открываю в IDE и под каждым комментарием пишу нужный код. Примерно так же поступаю, когда нужно реализовать чужой алгоритм. Разбиваю описание на естественном языке или псевдокод на смысловые строки с "//" в начале и открываю в IDE. Просто, но удобно!
Если в задаче много сложных мат.формул, то вместо ворда использую LyX.
К вопросу о коммуникабельности: если есть желание расти профессионально, обязательно следует «залезть» в соседнюю область Пишешь сервер — напиши клиент. Пишешь фронт — напиши енд. Пишешь для контроллера — купи за 100 рублей на али авр (или стм), нарисуй и разведи утюгом плату, заставь это работать. Напиши для себя, в свободное время. Если стыдно за результат — можешь никому не показывать, но сделай это. 3/4 вопросов коммуникации со смежниками отпадут.
К вопросу о желании учиться — обязательно надо написать на ассемблере работоспособный проект сложнее хеллоуворда. На любом ассемблере, но интереснее — не интеловском, а типа PDP11 или вообще типа NM6406. После реализации конструкции switch/case отпадают вопросы, чем это лучше десятка if, после реализации функции с выделением места под локальные переменные в стеке отпадают вопросы про то, зачем писать stdcall и чем это отличается от других ...call и почему не стоит делать массив на 100000 элементов локальной переменной. Чем передача параметра по значению отлиается от передачи по ссылке. Не говоря уже о том, что пропадают вопросы, что такое указатель и чем он отличается от самих данных. Вот просто въедается, понимается не просто умом, а руками. Считаю, что асм ни разу не помешает даже PHP-шникам (или кто считает себя дальше всех от ассемблера?) для осознания тонкостей мастерства и оптимизации.
К вопросу о предварительной работе — надо не забывать и о последующей работе. Все, что стало в работе новым для себя, надо задокументировать. Как минимум — в виде хороших комментариев, хорошо бы виде дневника, а еще лучше — в виде статьи на тот же хабр или свой блог (если есть), где это может быть полезно и другим, но будет полезно и себе через какое-то время.
К вопросу о желании учиться — обязательно надо написать на ассемблере работоспособный проект сложнее хеллоуворда. На любом ассемблере, но интереснее — не интеловском, а типа PDP11 или вообще типа NM6406. После реализации конструкции switch/case отпадают вопросы, чем это лучше десятка if, после реализации функции с выделением места под локальные переменные в стеке отпадают вопросы про то, зачем писать stdcall и чем это отличается от других ...call и почему не стоит делать массив на 100000 элементов локальной переменной. Чем передача параметра по значению отлиается от передачи по ссылке. Не говоря уже о том, что пропадают вопросы, что такое указатель и чем он отличается от самих данных. Вот просто въедается, понимается не просто умом, а руками. Считаю, что асм ни разу не помешает даже PHP-шникам (или кто считает себя дальше всех от ассемблера?) для осознания тонкостей мастерства и оптимизации.
К вопросу о предварительной работе — надо не забывать и о последующей работе. Все, что стало в работе новым для себя, надо задокументировать. Как минимум — в виде хороших комментариев, хорошо бы виде дневника, а еще лучше — в виде статьи на тот же хабр или свой блог (если есть), где это может быть полезно и другим, но будет полезно и себе через какое-то время.
Периодически пересматривать и переписывать свой код на предмет «оптимизации»)
Странно, что в Вашей версии опытного программиста — опыт совсем не фигурирует в списке :)
Diablo III как пример «упора на результат»? Только фанатам серии этого не говорите…
Иногда я пишу в блокнот мысли, идеи, задачи. Это действительно помогает.
Сейчас застрял в написании одного скрипта, а блокнот в столе, просто лень взять его и написать, что я хочу от программы! Очень ценный совет в статье, спасибо!
Изучение любой науки процесс постепенный. Скорость постижения у всех разная, но процесс примерно одинаков.
Один мудрец сказал: как только понял, что всё знаешь — начал деградировать! Как и описано в этой статье, важный момент всегда изучать.
Сейчас застрял в написании одного скрипта, а блокнот в столе, просто лень взять его и написать, что я хочу от программы! Очень ценный совет в статье, спасибо!
Изучение любой науки процесс постепенный. Скорость постижения у всех разная, но процесс примерно одинаков.
Один мудрец сказал: как только понял, что всё знаешь — начал деградировать! Как и описано в этой статье, важный момент всегда изучать.
Sign up to leave a comment.
Навыки опытного программиста: Самые популярные советы начинающим