Пользователь
0,0
рейтинг
4 августа 2010 в 14:38

Управление → Десять советов начинающим программистам

GTD*

Предисловие


Хорошо, когда работаешь с человеком, который отлично знает толк в своём деле. А что, если случается работать с коллегой, опыт которого не столь большой. Особенно это касается профессионально-личностных качеств. Невольно приходится подсказывать, местами помагать ему, а где-то даже откровенно учить. Все мы когда-то начинали. Все эти действия требуют немалых усилий, которые можно было бы применить по прямому назначению — в разработке проекта, но без подготовки новых специалистов будет тяжелее.

Так вот, чтобы минимизировать эти затраты, давайте «создадим» хорошего, а возможно и идеального начинающего программиста, с высоким потенциалом и светлыми горизонтами.

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

1. Будьте самостоятельными


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


2. Умейте спрашивать


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

3. Постоянно развивайтесь


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

4. Не бойтесь учиться оценивать


Вспоминая себя, вначале у меня была своеобразная боязнь оценки поставленной задачи. И я с переменным успехом то промахивался, то попадал. Могу вас сразу успокоить, эта задача является настолько не простой, что для её решения существует множество комплексных методик, разрабатываемых не одним поколением специалистов, и это не только в айти. Мне кажется, что я вас изрядно напугал. Ну да ничего, поймаете пару ударов граблями, угостите пивом более опытных коллег, чтобы разузнать их ноу-хау, и у вас будет базовый навык эстимации задач. Со временем, приобретая опыт по решению различных задач, картина будет весьма ясной, например, вы без труда поймете, что на реализацию фичи «свистелка-пыхтелка на jQuery» понадобится 6 часов плюс 2 часа на риски. Так что это дело наживное.

5. Не забывайте о всей картине системы


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

6. В меру используйте готовые решения


Наверное, нигде больше, чем в айти, не изобретается такое огромное количество велосипедов. В этом есть как свои плюсы, так и откровенные минусы. Важно понимать, что если есть достаточное количество времени, задача не сложная и вы хорошо представляете, что нужно делать, то можно написать свою реализацию, которая гармонично впишется в общий стиль проекта. Это как минимум даст вам понимание процессов изнутри, и конечно же практический опыт. Однако, если времени в обрез, либо задача успешно решается комплексным инструментарием, например, популярным фреймворком, задействованным на проекте либо каким-то компонентом из библиотеки, то эффективнее использовать готовое решение. Учтите, что возможны ситуации, когда в дальнейем может потребоваться оптимизация или расширение выбранного вами решения.

7. Цените свой труд


Не подходите к задаче, как одолжению, иначе от вас будет только вред. Цените то, что вы творите, ведь вы именно творите и создаете. Не пожалейте пары минут на оформление кода, согласно общепринятым стандартам в компании или команде. Вычистите свой результат, будьте педантичны, воспитайте в себе эту привычку, если её еще нет. К примеру, если у вас «съехал» элемент интерфейса на несколько пикселей вправо, то не пожалейте времени поправить его, вернув на место. Обязательно проверяйте и запускайте результат своей деятельности, не перекладывайте всё на плечи без того загруженных инженеров по контролю качества. В итоге вас обязательно заметят и оценят по достоинству, и все, потому что вы цените то, что создаете.

8. Не будьте ленивыми


Комменты на хабре, просмотр роликов на ютубе и прочие скайпы во время простоев на работе — это не плохо, но гораздо лучше заниматься чем-то полезным как для себя, так и для коллег. Прочитали об интересной технологии, которую потенциально можно применить на проекте? Попробуйте её в деле — нагрузите тестами в песочнице, сравните полученные результаты с уже используемыми сходными технологиями, или же напишите «hello world» в виде движка для блога либо другой тривиальной (но не слишком) задачи. Также хорошо в свободное время можно создать что-то своё: будь то простенький greasemonkey-скрипт для любимого веб-ресурса, или же давно не дающая покоя оригинальная мысль для стартапа. В любом случае огромным плюсом после всего этого будет поддержание рабочего тонуса и, как следствие, хорошие результаты в решении новых задач.

9. Умейте правильно излагать свои мысли


Старайтесь кратко и четко излагать свои мысли. Не зря говорят, что краткость — сестра таланта. Если вам приходится не просто и словесная «вода» льется без остановки, то тренируйтесь «на кошках»: запишите мысль на бумаге, постарайтесь вдумчиво выделить базовый тезис и, через постепенное вычеркивание «лишних» и «приукрашающих» слов и фраз, очищайте его. Отнеситесь к этому, как к игре — с азартом, энтузиазмом и интересом. В роли второй «кошки» выступает, как ни странно, твиттер, с его ограничениями на сообщения.

10. Не ограничивайтесь своей ролью


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


Послесловие


Для кого-то это само собой разумеющееся, и, возможно, на меня повесят погоны всем известного капитана. Но, как показывает практика, к сожалению не все это понимают и, в последствии, набивают глупые шишки как себе, так и коллегам. А ведь этого можно было избежать.

В комментариях горячо приветствуются другие полезные и конструктивные советы. Уверен, что будет интересно все, как на базе своего опыта, так и советы, полученные в наставление от более опытных и мудрых коллег.
HighOctane @HighOctane
карма
13,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (84)

  • +12
    Если всему этому следовать будет, ну просто, «Идеальный начинающий программист» :)
    • +10
      Этим правилам неплохо бы следовать и большинству «опытных» программистов.
      • 0
        интересно было бы такое руководство и в плане обучению программированию, с чего начинать, как лучше…
        • +1
          Structure and Interpretation of Computer Programs (с проделыванием всех упражнений; переведена на русский), не самый плохой вариант, факт. Потом Programming from the Ground Up. Потом K&R. Потом сами прекрасно поймете, что читать и учить.

          Но это уж очень оптимистичный и почти нереальный сценарий развития событий ИМХО.
  • +2
    По сути согласен, но вот 1 и 2 могут и меняться местами, например пусть меня лучше спросят, т.к. часто начинающий не обычно не знает архитектуру целиком и соответственно самостоятельно может решить задачу таким образом, что она не впишется в соответствующую архитектуру, поэтому лучше уточнить. При этом я либо отвечу на вопрос если это действительно критично и решить надо задачу определенным образом, либо отправлю гуглить.
    • 0
      А по-мне так порядок более чем правильный, нет, конечно лучше пусть спросят когда речь о спасении человечества и 8 миллиардах замбезийских голодных детей, однако-же обычно проблема не в этом, а в том «не помнишь-ли ты тот оператор...» / «а куда мне вставить скобку...»/ «а ты видел...» / «а ты слышал...», завершающееся коронным «хотя не буду тебя отвлекать», есс-но после того как ты уже отвлекся, и бегством, с расчетом на то что ты скача трехметровыми шагами по офису ринешся за вопрошающим вдогонку с криком «Я не занят! Я знаю! Я помогу!».
      • 0
        Не согласен. У начинающего программиста всегда должен быть куратор, которому в оверхеды заложено время на обучение. И этим можно и нужно пользоваться.
        Если суть вопроса — конструкция языка, то (для примера!) какой-нибудь java.sun.com раскапывать на предмет того, как просто преобразовать List в массив, можно долго, а знающий на этот вопрос ответит не отрываясь от монитора. Разницу во времени можно потратить на более полезные вещи.
        Если вопрос по сути поставленной задачи, то совет «гугл в помощь», увы, не работает на больших проектах, т.к. новые(для этого проекта) технлогии в проект внедрять начинающему не доверят, а о содержимом проекта гугл не знает.
        Если же самому копать код, то на это может уйти очень много времени, и зачастую приводит совсем не к тому результату — на code review может выясниться, что то же самое можно было сделать вдесятеро меньшими усилиями.
        • +1
          Ммм… вбил в гугл «java convert list to array», изучил первые три ссылки, ушло две-три минуты, будто бы всё понятно. Если ты спросишь коллегу, ты можешь отвлечь его на минуту, так как ему придётся подойти и показать, а потом ещё восстанавливать контекст того, чем он занимался до этого. Если ты стажёр, время коллеги может быть в 3-4 раза дороже :-)
          • 0
            Я ж сказал — для примера. :)
        • 0
          Задавать хорошие вопросы — это, наверное, одно из определяющих качеств начинающего программиста, да и специалиста вообще.
          Во-первых, при правильной формулировке вопроса (а она порой занимает очень много времени), когда стараешься собрать и выдать старшему товарищу как можно больше исходных данных, половина проблем решаются сами собой.
          Во-вторых, ситуацию, когда уже пора задать вопрос, нужно отличить от ситуации «лень посмотреть в MSDN, google и т.п.». Даже если нужно полчаса на то, чтобы понять, какую функцию можно использовать для решения задачи, это вполне оправданно. Такое исследование добавит опыта начинающему программисту и позволит не отвлекать куратора. Кстати, Дж. Спольски писал о том, что простой вопрос, на который приходится отвлечься, отнимает у программиста 15 минут эффективного рабочего времени — а за эти 15 минут ваш куратор, который скорее всего является одним из опытных членов команды, мог бы сделать много полезного.
          В-третьих, опытному программисту радостно отвечать на хороший и интересный вопрос. Пусть даже ответ для него очевиден, он с готовностью поможет и «зарядит» в итоге как знаниями, так и общими советами, инициативой и хорошим настроением. А если бегать к старшим товарищам спрашивать, как преобразовать строку, раз в 5 минут, то есть большие шансы ничего кроме «ну что там опять?» и «гугл в помощь» не услышать.
      • 0
        Вот когда что-нить новичок сломает и потом придется все приводить в нормальный вид уже его тим-лиду или еще кому, уже не очень весело становится.
  • +17
    Как только я вижу статью которая начинается с «Десять советов...», «Двенадцать способов», «Пять правил успешного...», можно с 90% уверенностью предположить что под катом скрыватся Капитан Очевидность с очередной порцией общих (а значит несовместимых с жизненными реалиями) или очевидных любому неидиоту и само собой разумеющихся советов. Так и вышло.

    • +3
      Вы не представляете насколько разные люди могут быть, я кстати это указал в послесловии, то есть отдаю себе отчет этом.
    • +1
      И почему-то везде круглое число — пять, десять, двенадцать. Если б статья называлась как-нибудь типа «Семнадцать советов...» или «Одиннадцать правил...», я б еще поверил, что автор не отбросил ничего существенного или, наоборот, не высосал несколько пунктов из пальца ради красивого числа в заголовке, а так…
      • 0
        Эээ, а чем одинадцать правил отличаются от двенадцати с точки зрения округлости? :-)
        • +1
          Двенадцать — это дюжина :-) Очень даже круглое число, особенно для англоязычного мира.
      • +1
        Представьте, что я использовал 16-ричную систему и тут 0A пунктов, но на последнем пункте случайно сбилась нумерация.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Пишите статью, успех будет обеспечен!
    • 0
      Проблема в том, что если человек следует т.е. реально следует _очевидным_ советам, то в общем он сам уже кого хочешь чему хочешь научит.
      Опять же правила которым можно следовать они должны быть очевидными иначе не работают. И вообще что еще Вы ожидали увидеть под заголовком учись работать? Мега сложный секртный совет-заклинание? Я думаю 99% всего что тут есть просто должно быть очевидным иначе это не получится использовать.
    • +1
      Ага, а еще бывает смотришь на какую-то страшную лажу и думаешь, «блин, а почему человек не сделал вот такой элементарной, очевидной и простой вещи, чтобы этот предотвратить?». Идешь и спрашиваешь его. А он говорит: «Да? А ведь и вправду, можно было сделать так...»
    • +2
      Если 100 таких тредов сделают из одного, как Вы выразились, идиота одного Нормального Начинающего Программиста — то это будет победа, труд был не напрасен.
  • +2
    По некоторым пунктам узнал себя в далекой молодости ;) особенно в оценке тасков… до сих пор промахиваюсь :)
    Наиболее важные, имхо, это умение задавать вопрос правильно. Иногда достаточно правильно сформулировать свой вопрос, как решение всплывает тут-же, и становится всё очевидным сразу.
    • 0
      Точно! «Правильно сформулированный вопрос — половина ответа» — ну или как то так.
      • +10
        А Алена Голуба описана классная техника. «Если вы долгое время не можете решить какую-то задачу — просто расскажите про нее кому-нибудь. Решение придет в голову процессе рассказа». Работает со 100% результативностью.

        Мне иногда начинает казаться, что программирование — это лингвистическая задача.
  • +2
    8 = самый надежный путь загнуться от переутомления. Я последний год занимаюсь в среднем 3-4 проектами одновременно (это кроме работы), и постепенно качество выполнения каждого проекта падает, как и качество меня самой :-)
    • 0
      Поддерживаю. Не ленится оно хорошо, но вот качество исполнения от этого часто падает. Я вот в отпуске нормальной небыл уже хз сколько и в данный момент я жалкое подобие того, что было 2-3 года назад в плане эффективности. Вот пилю начальство и уйду в месячный отпуск при первой же возможности и больше никогда не буду идти на компромисы вида «А давай мы на недельку сейчас, и недельку потом». За неделю не одхохнёшь, да и за 2 частенько тоже фиг успеваешь расслабится после интенсивной работы.
      • 0
        Отпуск… У нас тоже, стоило мне запланировать шикарный отпуск на целых три недели в начале лета, _внезапно_ началось внедрение, теперь только жалкие недельные хвостики, и то каждый раз воспринимаются как преступление :-(
        • +1
          Шлите лесом и предложите им самим съездить в турцию на 3 дня «отдохнуть». Отпуск положен и дать его они вам обязаны.
    • +1
      Согласен!

      Я бы вместо этого сделал бы пункт:

      8. Будьте ленивыми!
      Ведь только ленивый человек сначала поудмает как ему не делать чего-то, а потом только примется делать. Не будь талантливые разработчики ленивыми, мы бы никогда не узнали про шаблоны и генерацию кода и про многие другие плюшки современного мира разработки ПО.

      Сейчас я работаю сразу над 3 проектами и периодически ну так сильно ленюсь, что уезжаю на все выходные на природу — зато потом на целую неделю такой заряд сил, что это с лихвой компенсирует «упущенное время».

      В общем, находите время лениться, господа программисты и им сочувствующие!
      • 0
        Лень вообще двигатель прогресса, если бы древним людям не было лень таскать грузы, так никто бы и не изобрёл колесо (а в поледствии тачки/кареты/машины/итд)
  • +1
    Ох, сколько уже было этих «10 советов начинающим программистам»… А на деле пережевывание прописных истин и советы, как быть внимательным, и ответственным человеком. Эти советы можно использовать где угодно, поменяв десяток слов в тексте быстрой заменой.
    • +1
      Прописные истины становятся ими только тогда, когда человек их осознал и подкрепил опытом. Отсюда можно сказать, что вы не начинающий программист, раз это для вас очевидно. Рад за вас.
    • 0
      Они, может, и прописные, но очень много т.н. «программистов» о них даже не подозревают.
      • 0
        И самое страшное, кстати, это когда человек не умеет (или боится) спрашивать. Тут спектр страшностей очень широк: от тормозов процесса до адского быстрокода, но в любом случае такой человек требует дополнительного контроля, что отнимает ценное время «надзирающего» программиста или менеджера.
  • –1
    «Особенно это касается нашей сферы дЕТЯельности.» :)

    В целом отличная статья. Спасибо. Для меня, как для начинающего тем более полезно.
    • 0
      Поправил, спасибо.
      • +1
        Не придирка, а так к сведению: 2 строка

        >местами помагать
        помОгать вернее будет
  • +2
    0. Читайте Хабр :)
    • +5
      11. Закрывайте хабр, начинайте программировать.
      • +1
        12. goto 0
        • +5
          Чревато.
          xkcd.com/292/
        • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    спасибо за статью, сохранил в evernote. сам потихоньку шарп учу, эти советы явно помогут правильнее подходить к процессу.
    и ещё — может кто-то посоветует сайт или книжку с практическими задачами по этому языку? было бы просто замечательным подспорьем.
    • 0
      А зачем потихоньку? Учите смелее, раз взялись!
  • 0
    Все могу, все делаю, но с 7 пунктом — «Цените свой труд», как-то туговато(
    • 0
      7. цените свой труд — это бред, это нужн перефразировать как «пожалейте себя в будующем, который будет поддерживать этот код»
  • +2
    11. Пишите код аккуратно и комментируйте!
    Через неделю даже вы не поймете что это за ересь написана.

    12. Не вступайте в холивары по поводу расстановок скобок и количества пробелов в табуляции.
    • +1
      11 да, хотя ИМХО это так сказать вторичный вывод.
      по поводу 12 — я бы сказал вступайте в холивары, не будьте конфиормистами, грамотный и обстоятельный холивар может принести много пользы. Главное обстоятельно спорить а не брызгать слюной.
      Просто не приниайте это к сердцу, не теряйте чувства юмора. Я могу яростно учавствовать в холиваре Java vs PHP на строне Явы но через день порекомендовать для проекта PHP просто потому что для данного проекте он более уместен.
      • +1
        Чтобы холиварить, нужно иметь солидную базу знаний предмета холивара, иначе это… ну сами понимаете.
        • +2
          Нет. Холивар он тем и полезен что помогает эту базу приобрести. Вот я Яву защищаю, а мне говорят, а ты знаешь что в Яве вот такая засада есть? Посмотрел и правда есть. Приобрел опыт.
          Просто холивар это абсолютно не серьезное занятие, очень любимое джуниорами. Если у Вас есть солидная база то холиварить тяжело. Я вот практически не могу. Ну наехать на какую-то технологию еще получается, но потом как бы всерьез из-за этого рубиться — уже не прикольно.
          А для джуниоров вид спорта в самый раз, главное, повторюсь, не принимать близко к сердцу. Прямо таки упражение для джуниоров нашел
          1. Найдите аткивную технологическую тусовку
          2. Выберите произвольный технологический холивар
          3. Выберите понравившуюся сторону
          4. Аргументированно порубитесь какое-то время
          5. Возьмите другой ник, так же по взрослому и аргументированно порубитесь за другую сторону.
          6. Напишите статью A vs B хотя бы просто для себя
          Проделайте несколько раз с разными холиварами Java vs .Net, .Net vs PHP, Windows vs Linux, и т.п.
  • 0
    Все эти советы это попытка поделиться опытом, но они редко усваиваются начинающими программистами. Пока сами не обожгутся — не поймут толком. Но ничего, все «умные дядьки» когда то были ни бум-бум.
    • 0
      Что-ж теперь и не советовать? Те, кто прочитает и последуют советам те выживут и поднимутся, те кто нет, нет.
  • +6
    Мне все эти «советы начинающим» очень напоминают нотации детям. Ты вот рассказываешь, он все понимает и махает головой, но все равно делает по своему. И делает он по своему не потому-что он тупой или вредный, а потому-что он ребенок.
    Тут мне кажется тоже самое. Начинающий не будет следовать всем этим правилам именно потому-что он начинающий, а если же будет, то это уже не начинающий :-)
    • 0
      Смотря какой начинающий :)
      • 0
        ну само определение «Начинающий» уже не конкретно. Тут естественно имеется ввиду «Начинающий» как общий термин, примениымй для среднего человека в идеальных условиях :-)
  • 0
    Толково. Добавлю только — 11. общайтесь 12. общайтесь про активно.
    • +1
      А да и еще совет — не теряйте чувства юмора!!! Это очень важно.
    • 0
      Это, в смысле, в чатиках сидеть в рабочее время? :-)
      • 0
        Если чувство юмора это сидение в чатиках. Ну даже не знаю. Вы еще программу «Аншлаг» вспомните :-)
        • 0
          А вы внимательнее смотрите на точечки слева, которыми помечается дерево обсуждения :-)
          • 0
            аналогично коллега
  • +3
    На счёт лени не совсем согласен. В том разрезе в котором её описываете вы «Да», но «лень как таковая вообще» может быть очень и очень полезна.

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

    У меня около шести лет назад был почти юмористический случай, я написал код на неизвестном мне до этого языке (в совершенно новой для меня области)
    Я разбил написание на несколько этапов.
    — Постарался написать его настолько просто, на сколько это возможно
    — Усложнял этот код, добавлял костыль за костылём, пытался сделать «по уму»
    Результат этого действия меня веселит и по сей день, рано или поздно добавляя новые костыли, переосмысливая необходимость старых и удаляя их, в итоге я вернулся к почти что тому самому первому варианту.

    Просто всё что надо было, это полениться писать код, а вместо этого только чуть больше времени уделить «формулированию задачи» (посидеть попить чаю, прикинуть «а что я собственно делаю, и нафига»)
    • 0
      Хороший код простой код. Отличный код — тот про который скажут — а что тут писать то было? Все же элементарно.
      • 0
        главное потом суметь обосновать его значимость после фразы «и что, вот на это ты потратил две недели рабочего времени?»
        • 0
          Ну интересный вопрос — если работа оценивается так что обосновать нельзя — ну ее нафиг. А в правильной ситуации оценка идет по тому что сделано и насколько это надежно.
  • 0
    Гы :-)
    >Если у вас есть какой-то вопрос, и вы не знаете как с ним поступить, то… и конечно же хабра.

    Может лучше пусть мануал почитают?
    • 0
      Если НИЧЕГО не помогает — попробуйте почитать мануал. Т.е. уже после хабра :-)
  • 0
    По поводу «5. Не забывайте о всей картине системы» хочется добавить «читай код». Советую всем поискать в гугле пост уважаемого Gaperton'а по этим двум словам.
  • 0
    Честно говоря, никогда не видел необходимости в распечатанной диаграмме классов или тем более схеме алгоритма. Полгода назад начал втягиваться в новый проект (порядка 10Мб Java-кода). Сейчас у меня неплохое представление о системе в целом и о детальном устройстве многих компонентов, хотя я не видал диаграмм классов более сложных, чем Type hierarchy в эклипсе (то есть полная иерархия отдельно взятого типа). Имхо, побегать по проекту в IDE в интерактивном режиме, пользуясь средствами навигации, гораздо полезнее, чем изучать бумажку.
    • 0
      Бумажку, которая на практике редко бывает актуальной. Обычно на поддержании огромного объема актуальной проектной документации в реальной жизни людей не хватает (если только такая документация не является частью итоговой поставки заказчику).
      • 0
        Я бы так сказал помогает любой способ вникания в код. А уж конкретную магию под себя каждый подбирает.
    • 0
      Почитайте Фаулера, его точка зрения на UML мне очень нравится: UML for sketches only. Реально очень помогает общаться.
  • +7
    Не хочу писать отдельную статью, присобачусь тут в комменте.

    1. Читайте на английском, для этого совсем не обязательно целенаправленно учить английский. Начните со справочников, язык там очень простой, зачастую даже не понимая слов можно по примерам кода понять, о чем идет речь. Когда в справочниках все станет понятно, можно перейти к техническим статьям. Сначала будет болеть голова, но если информация интересная, то вы все равно будете ее читать и слова выучатся сами собой. Большинство стоящих статей (на Хабре к примеру) — это секондхенд, запоздалые и некачественные переводы статей с популярных англоязычных ресурсов. Иногда информация до русскоязычного сообщества доходит годами, иногда — не доходит вообще. Не зная английского вы не читаете практически ничего стоящего.

    2. Научитесь печатать вслепую. Представьте себе программирование с помощью Т9. Вот этим вы примерно и занимаетесь, если не печатаете вслепую.

    3. Не ведитесь на паттерны, UML, ООП, «правильные» способы разработки и «правильные» языки. Не верьте никому. Я не могу предложить стратегию, как не дурить себе голову, но наверное дело в полном понимании и ясности. Если вы хотите написать профессиональный код, и знаете что для этого нужно использовать классы, то не используйте их ни в коем случае! Классы нужно использовать только тогда, когда задача хорошо описывается классами. А вы не будете этого знать, пока не столкнетесь с проблемами, которые классы призваны решить, не идентифицируете эти проблемы, и не изобретете свой способ их решения. Вот тут скорее всего у вас получатся классы, и с этого момента вы будете понимать, зачем они нужны.

    4. Не тратьте много времени на проектирование. Во время реализации вы поймете, что не учли множество деталей; решение будет уродливое, но времени на переделку уже не останется. Лучше напишите очень грязный, но рабочий вариант. Рассчитайте время так, чтобы успели еще 2-3 раза его переписать. Понимаю, что этот подход далеко не интутивный. Просто имейте его в виду. Он дает лучшее качество кода и больше спокойствия, потому что код всегда работает. Может он не вылизанный, может чего-то не хватает, но он всегда готов.

    5. Вникайте в бизнес. Общайтесь с людьми из других отделов, проявите инициативу поработать менеджером. Осознайте за счет чего делаются деньги, кто вовлечен в процесс, какова роль программирования. Если вы этого не знаете, то центр вселенной для вас скорее всего смещен. Вы слишком много внимания уделяете тому, что неважно, и слишком мало тому, что важно.
    • 0
      пятый совет замечательный, не нужно ограничиваться программированием, нужно развиваться в разных областях и не забывать жить.
    • 0
      По поводу пункта 4 немного не согласен. Надо написать две-три грязные итерации, после чего уже сесть, подумать, и грамотно всё спроектировать, зная уже про все подводные камни. Последняя, чистовая итерация будет уже правильной и красивой. Только надо помнить, что каждую новую итерацию надо писать с нуля, нельзя заимствовать ничего из предыдущих.
  • +1
    Есть один очень важный пункт именно для программиста (начинающего, опытного) — читать умные книжки по программированию.
    И первую книжку которую я бы посоветовал начинающему — «Совершенный код» Стива Макконнелла — после прочтения этой книги от корки до корки, я смотрел на свой старый код и плакал, пришлось даже переписать несколько проектов :)
    • +1
      не могу Вам никуда + поставить, то того мало то того нет, потому просто здесь напишу: Спасибо! За на водку на книгу :)
  • –2
    советчиков что-то развелось…
  • 0
    Грамотно.
    Добавил бы пункт 11 «Иногда все-таки будьте ленивы». Начинающие программисты брызжущие энергией такооого могут наворотить…
  • 0
    Правило номер 8 на первое место вынести и возвести в абсолют. Тогда, имхо, остольные правила не нужны. Ну точнее все остальные правила выработаются как будто бы сами)
  • 0
    Ценный материал, я пытаюсь постоянно объяснить это своим коллегам
    • 0
      Спасибо, попробуйте найти индивидуальный подход для каждого — это должно помочь донести суть.
  • НЛО прилетело и опубликовало эту надпись здесь

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