Comments 84
Если всему этому следовать будет, ну просто, «Идеальный начинающий программист» :)
Этим правилам неплохо бы следовать и большинству «опытных» программистов.
интересно было бы такое руководство и в плане обучению программированию, с чего начинать, как лучше…
Structure and Interpretation of Computer Programs (с проделыванием всех упражнений; переведена на русский), не самый плохой вариант, факт. Потом Programming from the Ground Up. Потом K&R. Потом сами прекрасно поймете, что читать и учить.
Но это уж очень оптимистичный и почти нереальный сценарий развития событий ИМХО.
Но это уж очень оптимистичный и почти нереальный сценарий развития событий ИМХО.
По сути согласен, но вот 1 и 2 могут и меняться местами, например пусть меня лучше спросят, т.к. часто начинающий не обычно не знает архитектуру целиком и соответственно самостоятельно может решить задачу таким образом, что она не впишется в соответствующую архитектуру, поэтому лучше уточнить. При этом я либо отвечу на вопрос если это действительно критично и решить надо задачу определенным образом, либо отправлю гуглить.
А по-мне так порядок более чем правильный, нет, конечно лучше пусть спросят когда речь о спасении человечества и 8 миллиардах замбезийских голодных детей, однако-же обычно проблема не в этом, а в том «не помнишь-ли ты тот оператор...» / «а куда мне вставить скобку...»/ «а ты видел...» / «а ты слышал...», завершающееся коронным «хотя не буду тебя отвлекать», есс-но после того как ты уже отвлекся, и бегством, с расчетом на то что ты скача трехметровыми шагами по офису ринешся за вопрошающим вдогонку с криком «Я не занят! Я знаю! Я помогу!».
Не согласен. У начинающего программиста всегда должен быть куратор, которому в оверхеды заложено время на обучение. И этим можно и нужно пользоваться.
Если суть вопроса — конструкция языка, то (для примера!) какой-нибудь java.sun.com раскапывать на предмет того, как просто преобразовать List в массив, можно долго, а знающий на этот вопрос ответит не отрываясь от монитора. Разницу во времени можно потратить на более полезные вещи.
Если вопрос по сути поставленной задачи, то совет «гугл в помощь», увы, не работает на больших проектах, т.к. новые(для этого проекта) технлогии в проект внедрять начинающему не доверят, а о содержимом проекта гугл не знает.
Если же самому копать код, то на это может уйти очень много времени, и зачастую приводит совсем не к тому результату — на code review может выясниться, что то же самое можно было сделать вдесятеро меньшими усилиями.
Если суть вопроса — конструкция языка, то (для примера!) какой-нибудь java.sun.com раскапывать на предмет того, как просто преобразовать List в массив, можно долго, а знающий на этот вопрос ответит не отрываясь от монитора. Разницу во времени можно потратить на более полезные вещи.
Если вопрос по сути поставленной задачи, то совет «гугл в помощь», увы, не работает на больших проектах, т.к. новые(для этого проекта) технлогии в проект внедрять начинающему не доверят, а о содержимом проекта гугл не знает.
Если же самому копать код, то на это может уйти очень много времени, и зачастую приводит совсем не к тому результату — на code review может выясниться, что то же самое можно было сделать вдесятеро меньшими усилиями.
Ммм… вбил в гугл «java convert list to array», изучил первые три ссылки, ушло две-три минуты, будто бы всё понятно. Если ты спросишь коллегу, ты можешь отвлечь его на минуту, так как ему придётся подойти и показать, а потом ещё восстанавливать контекст того, чем он занимался до этого. Если ты стажёр, время коллеги может быть в 3-4 раза дороже :-)
Задавать хорошие вопросы — это, наверное, одно из определяющих качеств начинающего программиста, да и специалиста вообще.
Во-первых, при правильной формулировке вопроса (а она порой занимает очень много времени), когда стараешься собрать и выдать старшему товарищу как можно больше исходных данных, половина проблем решаются сами собой.
Во-вторых, ситуацию, когда уже пора задать вопрос, нужно отличить от ситуации «лень посмотреть в MSDN, google и т.п.». Даже если нужно полчаса на то, чтобы понять, какую функцию можно использовать для решения задачи, это вполне оправданно. Такое исследование добавит опыта начинающему программисту и позволит не отвлекать куратора. Кстати, Дж. Спольски писал о том, что простой вопрос, на который приходится отвлечься, отнимает у программиста 15 минут эффективного рабочего времени — а за эти 15 минут ваш куратор, который скорее всего является одним из опытных членов команды, мог бы сделать много полезного.
В-третьих, опытному программисту радостно отвечать на хороший и интересный вопрос. Пусть даже ответ для него очевиден, он с готовностью поможет и «зарядит» в итоге как знаниями, так и общими советами, инициативой и хорошим настроением. А если бегать к старшим товарищам спрашивать, как преобразовать строку, раз в 5 минут, то есть большие шансы ничего кроме «ну что там опять?» и «гугл в помощь» не услышать.
Во-первых, при правильной формулировке вопроса (а она порой занимает очень много времени), когда стараешься собрать и выдать старшему товарищу как можно больше исходных данных, половина проблем решаются сами собой.
Во-вторых, ситуацию, когда уже пора задать вопрос, нужно отличить от ситуации «лень посмотреть в MSDN, google и т.п.». Даже если нужно полчаса на то, чтобы понять, какую функцию можно использовать для решения задачи, это вполне оправданно. Такое исследование добавит опыта начинающему программисту и позволит не отвлекать куратора. Кстати, Дж. Спольски писал о том, что простой вопрос, на который приходится отвлечься, отнимает у программиста 15 минут эффективного рабочего времени — а за эти 15 минут ваш куратор, который скорее всего является одним из опытных членов команды, мог бы сделать много полезного.
В-третьих, опытному программисту радостно отвечать на хороший и интересный вопрос. Пусть даже ответ для него очевиден, он с готовностью поможет и «зарядит» в итоге как знаниями, так и общими советами, инициативой и хорошим настроением. А если бегать к старшим товарищам спрашивать, как преобразовать строку, раз в 5 минут, то есть большие шансы ничего кроме «ну что там опять?» и «гугл в помощь» не услышать.
Вот когда что-нить новичок сломает и потом придется все приводить в нормальный вид уже его тим-лиду или еще кому, уже не очень весело становится.
Как только я вижу статью которая начинается с «Десять советов...», «Двенадцать способов», «Пять правил успешного...», можно с 90% уверенностью предположить что под катом скрыватся Капитан Очевидность с очередной порцией общих (а значит несовместимых с жизненными реалиями) или очевидных любому неидиоту и само собой разумеющихся советов. Так и вышло.
Вы не представляете насколько разные люди могут быть, я кстати это указал в послесловии, то есть отдаю себе отчет этом.
UFO just landed and posted this here
Проблема в том, что если человек следует т.е. реально следует _очевидным_ советам, то в общем он сам уже кого хочешь чему хочешь научит.
Опять же правила которым можно следовать они должны быть очевидными иначе не работают. И вообще что еще Вы ожидали увидеть под заголовком учись работать? Мега сложный секртный совет-заклинание? Я думаю 99% всего что тут есть просто должно быть очевидным иначе это не получится использовать.
Опять же правила которым можно следовать они должны быть очевидными иначе не работают. И вообще что еще Вы ожидали увидеть под заголовком учись работать? Мега сложный секртный совет-заклинание? Я думаю 99% всего что тут есть просто должно быть очевидным иначе это не получится использовать.
Ага, а еще бывает смотришь на какую-то страшную лажу и думаешь, «блин, а почему человек не сделал вот такой элементарной, очевидной и простой вещи, чтобы этот предотвратить?». Идешь и спрашиваешь его. А он говорит: «Да? А ведь и вправду, можно было сделать так...»
Если 100 таких тредов сделают из одного, как Вы выразились, идиота одного Нормального Начинающего Программиста — то это будет победа, труд был не напрасен.
По некоторым пунктам узнал себя в далекой молодости ;) особенно в оценке тасков… до сих пор промахиваюсь :)
Наиболее важные, имхо, это умение задавать вопрос правильно. Иногда достаточно правильно сформулировать свой вопрос, как решение всплывает тут-же, и становится всё очевидным сразу.
Наиболее важные, имхо, это умение задавать вопрос правильно. Иногда достаточно правильно сформулировать свой вопрос, как решение всплывает тут-же, и становится всё очевидным сразу.
8 = самый надежный путь загнуться от переутомления. Я последний год занимаюсь в среднем 3-4 проектами одновременно (это кроме работы), и постепенно качество выполнения каждого проекта падает, как и качество меня самой :-)
Поддерживаю. Не ленится оно хорошо, но вот качество исполнения от этого часто падает. Я вот в отпуске нормальной небыл уже хз сколько и в данный момент я жалкое подобие того, что было 2-3 года назад в плане эффективности. Вот пилю начальство и уйду в месячный отпуск при первой же возможности и больше никогда не буду идти на компромисы вида «А давай мы на недельку сейчас, и недельку потом». За неделю не одхохнёшь, да и за 2 частенько тоже фиг успеваешь расслабится после интенсивной работы.
Согласен!
Я бы вместо этого сделал бы пункт:
8. Будьте ленивыми!
Ведь только ленивый человек сначала поудмает как ему не делать чего-то, а потом только примется делать. Не будь талантливые разработчики ленивыми, мы бы никогда не узнали про шаблоны и генерацию кода и про многие другие плюшки современного мира разработки ПО.
Сейчас я работаю сразу над 3 проектами и периодически ну так сильно ленюсь, что уезжаю на все выходные на природу — зато потом на целую неделю такой заряд сил, что это с лихвой компенсирует «упущенное время».
В общем, находите время лениться, господа программисты и им сочувствующие!
Я бы вместо этого сделал бы пункт:
8. Будьте ленивыми!
Ведь только ленивый человек сначала поудмает как ему не делать чего-то, а потом только примется делать. Не будь талантливые разработчики ленивыми, мы бы никогда не узнали про шаблоны и генерацию кода и про многие другие плюшки современного мира разработки ПО.
Сейчас я работаю сразу над 3 проектами и периодически ну так сильно ленюсь, что уезжаю на все выходные на природу — зато потом на целую неделю такой заряд сил, что это с лихвой компенсирует «упущенное время».
В общем, находите время лениться, господа программисты и им сочувствующие!
Ох, сколько уже было этих «10 советов начинающим программистам»… А на деле пережевывание прописных истин и советы, как быть внимательным, и ответственным человеком. Эти советы можно использовать где угодно, поменяв десяток слов в тексте быстрой заменой.
«Особенно это касается нашей сферы дЕТЯельности.» :)
В целом отличная статья. Спасибо. Для меня, как для начинающего тем более полезно.
В целом отличная статья. Спасибо. Для меня, как для начинающего тем более полезно.
0. Читайте Хабр :)
11. Закрывайте хабр, начинайте программировать.
12. goto 0
Чревато.
xkcd.com/292/
xkcd.com/292/
UFO just landed and posted this here
спасибо за статью, сохранил в evernote. сам потихоньку шарп учу, эти советы явно помогут правильнее подходить к процессу.
и ещё — может кто-то посоветует сайт или книжку с практическими задачами по этому языку? было бы просто замечательным подспорьем.
и ещё — может кто-то посоветует сайт или книжку с практическими задачами по этому языку? было бы просто замечательным подспорьем.
Все могу, все делаю, но с 7 пунктом — «Цените свой труд», как-то туговато(
11. Пишите код аккуратно и комментируйте!
Через неделю даже вы не поймете что это за ересь написана.
12. Не вступайте в холивары по поводу расстановок скобок и количества пробелов в табуляции.
Через неделю даже вы не поймете что это за ересь написана.
12. Не вступайте в холивары по поводу расстановок скобок и количества пробелов в табуляции.
11 да, хотя ИМХО это так сказать вторичный вывод.
по поводу 12 — я бы сказал вступайте в холивары, не будьте конфиормистами, грамотный и обстоятельный холивар может принести много пользы. Главное обстоятельно спорить а не брызгать слюной.
Просто не приниайте это к сердцу, не теряйте чувства юмора. Я могу яростно учавствовать в холиваре Java vs PHP на строне Явы но через день порекомендовать для проекта PHP просто потому что для данного проекте он более уместен.
по поводу 12 — я бы сказал вступайте в холивары, не будьте конфиормистами, грамотный и обстоятельный холивар может принести много пользы. Главное обстоятельно спорить а не брызгать слюной.
Просто не приниайте это к сердцу, не теряйте чувства юмора. Я могу яростно учавствовать в холиваре Java vs PHP на строне Явы но через день порекомендовать для проекта PHP просто потому что для данного проекте он более уместен.
Чтобы холиварить, нужно иметь солидную базу знаний предмета холивара, иначе это… ну сами понимаете.
Нет. Холивар он тем и полезен что помогает эту базу приобрести. Вот я Яву защищаю, а мне говорят, а ты знаешь что в Яве вот такая засада есть? Посмотрел и правда есть. Приобрел опыт.
Просто холивар это абсолютно не серьезное занятие, очень любимое джуниорами. Если у Вас есть солидная база то холиварить тяжело. Я вот практически не могу. Ну наехать на какую-то технологию еще получается, но потом как бы всерьез из-за этого рубиться — уже не прикольно.
А для джуниоров вид спорта в самый раз, главное, повторюсь, не принимать близко к сердцу. Прямо таки упражение для джуниоров нашел
1. Найдите аткивную технологическую тусовку
2. Выберите произвольный технологический холивар
3. Выберите понравившуюся сторону
4. Аргументированно порубитесь какое-то время
5. Возьмите другой ник, так же по взрослому и аргументированно порубитесь за другую сторону.
6. Напишите статью A vs B хотя бы просто для себя
Проделайте несколько раз с разными холиварами Java vs .Net, .Net vs PHP, Windows vs Linux, и т.п.
Просто холивар это абсолютно не серьезное занятие, очень любимое джуниорами. Если у Вас есть солидная база то холиварить тяжело. Я вот практически не могу. Ну наехать на какую-то технологию еще получается, но потом как бы всерьез из-за этого рубиться — уже не прикольно.
А для джуниоров вид спорта в самый раз, главное, повторюсь, не принимать близко к сердцу. Прямо таки упражение для джуниоров нашел
1. Найдите аткивную технологическую тусовку
2. Выберите произвольный технологический холивар
3. Выберите понравившуюся сторону
4. Аргументированно порубитесь какое-то время
5. Возьмите другой ник, так же по взрослому и аргументированно порубитесь за другую сторону.
6. Напишите статью A vs B хотя бы просто для себя
Проделайте несколько раз с разными холиварами Java vs .Net, .Net vs PHP, Windows vs Linux, и т.п.
Все эти советы это попытка поделиться опытом, но они редко усваиваются начинающими программистами. Пока сами не обожгутся — не поймут толком. Но ничего, все «умные дядьки» когда то были ни бум-бум.
Мне все эти «советы начинающим» очень напоминают нотации детям. Ты вот рассказываешь, он все понимает и махает головой, но все равно делает по своему. И делает он по своему не потому-что он тупой или вредный, а потому-что он ребенок.
Тут мне кажется тоже самое. Начинающий не будет следовать всем этим правилам именно потому-что он начинающий, а если же будет, то это уже не начинающий :-)
Тут мне кажется тоже самое. Начинающий не будет следовать всем этим правилам именно потому-что он начинающий, а если же будет, то это уже не начинающий :-)
Толково. Добавлю только — 11. общайтесь 12. общайтесь про активно.
На счёт лени не совсем согласен. В том разрезе в котором её описываете вы «Да», но «лень как таковая вообще» может быть очень и очень полезна.
Поясню, если речь идёт о действительно начинающем программисте (который ещё не наступал на кучу граблей) то тут лень может очень здорово помочь. Как говорил один знаменитый (хоть и в узких кругах) программист «сложный код пишет тот, кто не умеет то же самое сделать просто».
У меня около шести лет назад был почти юмористический случай, я написал код на неизвестном мне до этого языке (в совершенно новой для меня области)
Я разбил написание на несколько этапов.
— Постарался написать его настолько просто, на сколько это возможно
— Усложнял этот код, добавлял костыль за костылём, пытался сделать «по уму»
Результат этого действия меня веселит и по сей день, рано или поздно добавляя новые костыли, переосмысливая необходимость старых и удаляя их, в итоге я вернулся к почти что тому самому первому варианту.
Просто всё что надо было, это полениться писать код, а вместо этого только чуть больше времени уделить «формулированию задачи» (посидеть попить чаю, прикинуть «а что я собственно делаю, и нафига»)
Поясню, если речь идёт о действительно начинающем программисте (который ещё не наступал на кучу граблей) то тут лень может очень здорово помочь. Как говорил один знаменитый (хоть и в узких кругах) программист «сложный код пишет тот, кто не умеет то же самое сделать просто».
У меня около шести лет назад был почти юмористический случай, я написал код на неизвестном мне до этого языке (в совершенно новой для меня области)
Я разбил написание на несколько этапов.
— Постарался написать его настолько просто, на сколько это возможно
— Усложнял этот код, добавлял костыль за костылём, пытался сделать «по уму»
Результат этого действия меня веселит и по сей день, рано или поздно добавляя новые костыли, переосмысливая необходимость старых и удаляя их, в итоге я вернулся к почти что тому самому первому варианту.
Просто всё что надо было, это полениться писать код, а вместо этого только чуть больше времени уделить «формулированию задачи» (посидеть попить чаю, прикинуть «а что я собственно делаю, и нафига»)
Гы :-)
>Если у вас есть какой-то вопрос, и вы не знаете как с ним поступить, то… и конечно же хабра.
Может лучше пусть мануал почитают?
>Если у вас есть какой-то вопрос, и вы не знаете как с ним поступить, то… и конечно же хабра.
Может лучше пусть мануал почитают?
По поводу «5. Не забывайте о всей картине системы» хочется добавить «читай код». Советую всем поискать в гугле пост уважаемого Gaperton'а по этим двум словам.
Честно говоря, никогда не видел необходимости в распечатанной диаграмме классов или тем более схеме алгоритма. Полгода назад начал втягиваться в новый проект (порядка 10Мб Java-кода). Сейчас у меня неплохое представление о системе в целом и о детальном устройстве многих компонентов, хотя я не видал диаграмм классов более сложных, чем Type hierarchy в эклипсе (то есть полная иерархия отдельно взятого типа). Имхо, побегать по проекту в IDE в интерактивном режиме, пользуясь средствами навигации, гораздо полезнее, чем изучать бумажку.
Бумажку, которая на практике редко бывает актуальной. Обычно на поддержании огромного объема актуальной проектной документации в реальной жизни людей не хватает (если только такая документация не является частью итоговой поставки заказчику).
Почитайте Фаулера, его точка зрения на UML мне очень нравится: UML for sketches only. Реально очень помогает общаться.
Не хочу писать отдельную статью, присобачусь тут в комменте.
1. Читайте на английском, для этого совсем не обязательно целенаправленно учить английский. Начните со справочников, язык там очень простой, зачастую даже не понимая слов можно по примерам кода понять, о чем идет речь. Когда в справочниках все станет понятно, можно перейти к техническим статьям. Сначала будет болеть голова, но если информация интересная, то вы все равно будете ее читать и слова выучатся сами собой. Большинство стоящих статей (на Хабре к примеру) — это секондхенд, запоздалые и некачественные переводы статей с популярных англоязычных ресурсов. Иногда информация до русскоязычного сообщества доходит годами, иногда — не доходит вообще. Не зная английского вы не читаете практически ничего стоящего.
2. Научитесь печатать вслепую. Представьте себе программирование с помощью Т9. Вот этим вы примерно и занимаетесь, если не печатаете вслепую.
3. Не ведитесь на паттерны, UML, ООП, «правильные» способы разработки и «правильные» языки. Не верьте никому. Я не могу предложить стратегию, как не дурить себе голову, но наверное дело в полном понимании и ясности. Если вы хотите написать профессиональный код, и знаете что для этого нужно использовать классы, то не используйте их ни в коем случае! Классы нужно использовать только тогда, когда задача хорошо описывается классами. А вы не будете этого знать, пока не столкнетесь с проблемами, которые классы призваны решить, не идентифицируете эти проблемы, и не изобретете свой способ их решения. Вот тут скорее всего у вас получатся классы, и с этого момента вы будете понимать, зачем они нужны.
4. Не тратьте много времени на проектирование. Во время реализации вы поймете, что не учли множество деталей; решение будет уродливое, но времени на переделку уже не останется. Лучше напишите очень грязный, но рабочий вариант. Рассчитайте время так, чтобы успели еще 2-3 раза его переписать. Понимаю, что этот подход далеко не интутивный. Просто имейте его в виду. Он дает лучшее качество кода и больше спокойствия, потому что код всегда работает. Может он не вылизанный, может чего-то не хватает, но он всегда готов.
5. Вникайте в бизнес. Общайтесь с людьми из других отделов, проявите инициативу поработать менеджером. Осознайте за счет чего делаются деньги, кто вовлечен в процесс, какова роль программирования. Если вы этого не знаете, то центр вселенной для вас скорее всего смещен. Вы слишком много внимания уделяете тому, что неважно, и слишком мало тому, что важно.
1. Читайте на английском, для этого совсем не обязательно целенаправленно учить английский. Начните со справочников, язык там очень простой, зачастую даже не понимая слов можно по примерам кода понять, о чем идет речь. Когда в справочниках все станет понятно, можно перейти к техническим статьям. Сначала будет болеть голова, но если информация интересная, то вы все равно будете ее читать и слова выучатся сами собой. Большинство стоящих статей (на Хабре к примеру) — это секондхенд, запоздалые и некачественные переводы статей с популярных англоязычных ресурсов. Иногда информация до русскоязычного сообщества доходит годами, иногда — не доходит вообще. Не зная английского вы не читаете практически ничего стоящего.
2. Научитесь печатать вслепую. Представьте себе программирование с помощью Т9. Вот этим вы примерно и занимаетесь, если не печатаете вслепую.
3. Не ведитесь на паттерны, UML, ООП, «правильные» способы разработки и «правильные» языки. Не верьте никому. Я не могу предложить стратегию, как не дурить себе голову, но наверное дело в полном понимании и ясности. Если вы хотите написать профессиональный код, и знаете что для этого нужно использовать классы, то не используйте их ни в коем случае! Классы нужно использовать только тогда, когда задача хорошо описывается классами. А вы не будете этого знать, пока не столкнетесь с проблемами, которые классы призваны решить, не идентифицируете эти проблемы, и не изобретете свой способ их решения. Вот тут скорее всего у вас получатся классы, и с этого момента вы будете понимать, зачем они нужны.
4. Не тратьте много времени на проектирование. Во время реализации вы поймете, что не учли множество деталей; решение будет уродливое, но времени на переделку уже не останется. Лучше напишите очень грязный, но рабочий вариант. Рассчитайте время так, чтобы успели еще 2-3 раза его переписать. Понимаю, что этот подход далеко не интутивный. Просто имейте его в виду. Он дает лучшее качество кода и больше спокойствия, потому что код всегда работает. Может он не вылизанный, может чего-то не хватает, но он всегда готов.
5. Вникайте в бизнес. Общайтесь с людьми из других отделов, проявите инициативу поработать менеджером. Осознайте за счет чего делаются деньги, кто вовлечен в процесс, какова роль программирования. Если вы этого не знаете, то центр вселенной для вас скорее всего смещен. Вы слишком много внимания уделяете тому, что неважно, и слишком мало тому, что важно.
пятый совет замечательный, не нужно ограничиваться программированием, нужно развиваться в разных областях и не забывать жить.
По поводу пункта 4 немного не согласен. Надо написать две-три грязные итерации, после чего уже сесть, подумать, и грамотно всё спроектировать, зная уже про все подводные камни. Последняя, чистовая итерация будет уже правильной и красивой. Только надо помнить, что каждую новую итерацию надо писать с нуля, нельзя заимствовать ничего из предыдущих.
Есть один очень важный пункт именно для программиста (начинающего, опытного) — читать умные книжки по программированию.
И первую книжку которую я бы посоветовал начинающему — «Совершенный код» Стива Макконнелла — после прочтения этой книги от корки до корки, я смотрел на свой старый код и плакал, пришлось даже переписать несколько проектов :)
И первую книжку которую я бы посоветовал начинающему — «Совершенный код» Стива Макконнелла — после прочтения этой книги от корки до корки, я смотрел на свой старый код и плакал, пришлось даже переписать несколько проектов :)
советчиков что-то развелось…
Грамотно.
Добавил бы пункт 11 «Иногда все-таки будьте ленивы». Начинающие программисты брызжущие энергией такооого могут наворотить…
Добавил бы пункт 11 «Иногда все-таки будьте ленивы». Начинающие программисты брызжущие энергией такооого могут наворотить…
Правило номер 8 на первое место вынести и возвести в абсолют. Тогда, имхо, остольные правила не нужны. Ну точнее все остальные правила выработаются как будто бы сами)
Ценный материал, я пытаюсь постоянно объяснить это своим коллегам
UFO just landed and posted this here
Sign up to leave a comment.
Десять советов начинающим программистам