Comments 95
Правило, которое выучил я (навеяло заглавной картинкой):
Никогда не ставьте кофе так близко от рабочего ноутбука, любая чашка однажды опрокинется. Минимум на расстоянии вытянутой руки. Лучше, на другом столе.
Никогда не ставьте кофе так близко от рабочего ноутбука, любая чашка однажды опрокинется. Минимум на расстоянии вытянутой руки. Лучше, на другом столе.
И желательно, чтобы он был без сахара — когда вы его таки разольёте — будет проще отмывать.
Ваш совет реально полезнее всего, что написано в посте.
Вы когда-нибудь пили кофе по 20 000 рублей за чашку? И я пил. Ваш совет крайне полезен.
Буквально пару дней назад как менял клавиатуру на ноутбуке по этой причине.
Это был худший розыгрыш себя самого на первое апреля.
И перед собой тоже не стоит ставить — очень легко задеть рукой. Когда-то я у меня была такая привычка, но после нескольких инцидентов я научился ставить чашку далеко в стороне :)
Если уж очень хочется кофе или чая, то можно взять большую чашку с широким основанием. Я использую чашку объемом 800 миллилитров. Даже при поперечном ударе в верхнюю кромку она не переворачивется, в отличие от обычных чашек.
Семь вещей, которые нужно знать начинающему программисту:
- Двоичная система счисления
- Типы переменных
- Логические операции
- Блок-схемы
- Циклы
- Функции
- Рекурсия
Двоичная система счисления
а можно узнать почему?
не программист, но со всем остальным согласен
Не обязательно двоичная, но ту, которую использует процессор под который разрабатываешь — знать обязательно. От этого зависит длина слова, от неё зависит определение сложности алгоритма.
если вы про Low-level типа ассемблера, то да.
а как работает интегральная схема процессора или трансформатор в блоке питания надо знать?
п.с. я не спорю, просто интересно знать более конкретное обоснование
а как работает интегральная схема процессора или трансформатор в блоке питания надо знать?
п.с. я не спорю, просто интересно знать более конкретное обоснование
Ещё есть поля с флагами и операции над ними (установка, проверка, снятие)
А ещё знание двоичной системы нужно, чтобы понимать, почему 0.1 * 10 не равно единице.
Я про тот low level, который доходит до самого верха. Предположим что у нас есть алгоритм сортировки. Хороший алгоритм, все знают что у него логарифмическая сложность. Но есть один нюанс — эта сложность будет только если у нас переменная меньше либо равна разрядности процессора. Если же мы возьмём и воспользуемся в алгоритме 128 битными переменными, то в лучшем случае всё ухудшится в 4 раза, а скорее всего выползет квадрат. А теперь вопрос — как программист без знаний низкого уровня будет оптимизировать приложение когда упрётся в боттлнэк? Он может поставить больше серверов, но там вылезают эта же двоичная система, но приминительно к сетям. Ровно в тот момент когда для программиста заканчивается вся магия низкого уровня — приходит понимание. Что оптимизации, что хайлоада. Я бы не сказал что это ненужные знания, я соглашусь что они могут не пригождаться очень долго, возможно даже — никогда, но вот ровно до того момента пока есть запас производительности.
Если же мы возьмём и воспользуемся в алгоритме 128 битными переменными, то в лучшем случае всё ухудшится в 4 раза
То есть сложность не изменится :)
Так «в лучшем» же :)
Константа резко поплывёт. Обычно одна инструкция за такт (+\-, иногда могут несколько уместиться), а тут резко все действия становятся медленнее. И нам ещё повезло что современный процессор похож на многоленточную машину тьюринга, во времена одноленточной задавшему вопрос рассмеялись бы в лицо!
Константа резко поплывёт. Обычно одна инструкция за такт (+\-, иногда могут несколько уместиться), а тут резко все действия становятся медленнее. И нам ещё повезло что современный процессор похож на многоленточную машину тьюринга, во времена одноленточной задавшему вопрос рассмеялись бы в лицо!
Новое слово в компьютерной науке!
Это азы работы компютера и, как по мне, их стоит знать как и историю своей страны (не из-за пользы). Так же, знание бинарки сильно позволяет экономить ресурсы. Ибо обычный человек думает, что в 3-х bool переменных можно хранить 3 единицы информации, а программист должен знать, что это 8 единиц информации.
Ну, и плюс, моё, личное — я не люблю поверхностную информацию. Она очень часто ведёт к неправильным выводам. Поэтому знание бинарки, как и базового устройства железа считаю обязательными.
Ну, и плюс, моё, личное — я не люблю поверхностную информацию. Она очень часто ведёт к неправильным выводам. Поэтому знание бинарки, как и базового устройства железа считаю обязательными.
в 3-х bool переменных можно хранить 3 единицы информации, а программист должен знать, что это 8 единиц информации.
это конкретно bool, про что уже говорит пункт №2
UFO just landed and posted this here
Извиняюсь. Разумеется это ошибка в используемых мной названиях.
Архиватор сделать не проблема, проблема сделать разархиватор.
>> А то ведь можно было бы сделать прикольный архиватор, который сжимает любые данные до 1-го бита
Так сразу в /dev/null, чего мелочиться :)
Так сразу в /dev/null, чего мелочиться :)
А то ведь можно было бы сделать прикольный архиватор, который сжимает любые данные до 1-го бита. ;)
Так ведь уже три года назад.
Но по факту, все равно один bool занимает 8 бит в памяти. И три bool можно уместить в 8 бит минимум, и то через битовые маски. Так что в некотором роде комментатор прав.
Но по факту, все равно один bool занимает 8 бит в памяти.
Не факт. Зависит от компилятора.
Фиг там, в современных языках логическая переменная занимает одно машинное слово — используется тип INTEGER. С чем это связано? А банально с производительностью… современному процессору сложнее оперировать байтами — для этого ему нужно из кеша/памяти извлечь слово и отсечь всё лишнее — а это дополнительные операции и соответственно замедление работы. Ещё хуже — использовать для этого отдельные биты.
Но для ХРАНЕНИЯ данных на внешних носителях экономичней всего хранить логические переменные именно в БИТАХ, но этим как правило брезгуют — лишняя морока ради экономии 128 байт на логических переменных из сотен килобайт сопутствующих данных. Шевелится начинают когда выигрыш более 50% или объём данных находится на грани, чтобы уложится в размер определённого слота и т.д.
Но для ХРАНЕНИЯ данных на внешних носителях экономичней всего хранить логические переменные именно в БИТАХ, но этим как правило брезгуют — лишняя морока ради экономии 128 байт на логических переменных из сотен килобайт сопутствующих данных. Шевелится начинают когда выигрыш более 50% или объём данных находится на грани, чтобы уложится в размер определённого слота и т.д.
UFO just landed and posted this here
Несколько не так, переменная типа BOOL это на самом деле INTEGER, который равен машинному слову используемой системы. т.е. нынче это 32/64 бита. Мало кто работает с BOOL как с отдельными битами т.к. из-за этого сильно страдает производительность и имеет смысл только для долговременного хранения состояния и в случае массовой обработки бинарных состояний(маски прозрачности изображений?). В целом, работать с битами процессору очень накладно, он умеет эффективно работать только группами бит по 32-64 за раз. А некоторые системы работают большими порциями — например по 1024 бита за раз(привет видеокартам и аналогичным числовым ускорителям) и им крайне накладно работать с одиночными битами.
Как-то я вас не понимаю. Операция по установке бита занимает от силы 3-4 такта процессора, для снятия 4-5. Слишком накладно для процессора это с fload/double работать, вместо fractional
И потом, следуя Вашей логике выходит, что и в степень двойку возводить лучше умножением чем сдвигом?
У Вас в профиле указано, что работа связана с МК и ассемблером… но почему-то мне страшно представить код после Вашей оптимизации.
Sorry за оффтопик. Если по теме, то я считаю, что обязательно нужно знать операции с фиксированной точкой.
И потом, следуя Вашей логике выходит, что и в степень двойку возводить лучше умножением чем сдвигом?
У Вас в профиле указано, что работа связана с МК и ассемблером… но почему-то мне страшно представить код после Вашей оптимизации.
Sorry за оффтопик. Если по теме, то я считаю, что обязательно нужно знать операции с фиксированной точкой.
Вы не учитываете что при этом если переменная не находится в кеше L1 нужно подтянуть её из оперативки, а это может занять уже до сотни тактов и очень неочевидно. И при этом процессор хоть из кеша хоть из оперативки вынужден читать словами, т.е. если надо где-то изменить один бит он читает 64/128 бит меняет их и ложит обратно. При этом операции с кешем могут затрагивать блоки гораздо большего размера — например страницу кеша в 64 байта… т.к. процессор/чипсет не умеет извлекать одиночные байты/слова и вынужден при операциях с данными оперировать объёмами кратными размеру страницы кэша, что в итоге выливается в очень много тактов простоя из-за таких простых операций, зато в отличие от бит он УЖЕ способен работать с числами с плавающей запятой гораздо быстрее — результат вычисления над числами с плавающей запятой появляется уже через 2..10 тактов. А в некоторых системах умножение матриц чисел 8x8 занимает 2..3 такта. По сравнению с этим, операции с битами выглядят крайне неэффективными.
В любом случае, работать с битами проще всего только в регистрах что и практикуется, но одиночное использование логической переменной очень не оптимально.
В любом случае, работать с битами проще всего только в регистрах что и практикуется, но одиночное использование логической переменной очень не оптимально.
Основная форма представления данных в самых распространенных, на сегодняшний день, ВС. Сильно поможет «заглянуть под капот».
Она тесно связана с элементарными логическими операциями.
К тому же, понимание двоичной системы счисления даёт обьяснение таким странным магическим числам как 1024, 32768, 65535 и многим другим непонятным ограничениям(ограничение размера файла в 4Гб на FAT32, 32Гб на размер винчестера в старых системах...).
Так же, приноси понимание почему математическая операция 10.0/10.0 = 1.0 не имеет смысла и очень часто даёт ложный результат, почему к примеру не всегда получится прибавить 1 к числу вроде 1E+37. Всё это завязано на двоичную систему счисления чуть более чем полностью.
К тому же, понимание двоичной системы счисления даёт обьяснение таким странным магическим числам как 1024, 32768, 65535 и многим другим непонятным ограничениям(ограничение размера файла в 4Гб на FAT32, 32Гб на размер винчестера в старых системах...).
Так же, приноси понимание почему математическая операция 10.0/10.0 = 1.0 не имеет смысла и очень часто даёт ложный результат, почему к примеру не всегда получится прибавить 1 к числу вроде 1E+37. Всё это завязано на двоичную систему счисления чуть более чем полностью.
0. Конечные автоматы
Правильно так:
10 вещей, которые нужно знать начинающему программисту:
0. Двоичная система счисления
1. Еще FF всяких полезных вещей
10 вещей, которые нужно знать начинающему программисту:
0. Двоичная система счисления
1. Еще FF всяких полезных вещей
Можешь посоветовать книгу начинающему?
Что прочесть в первую очередь?
Что прочесть в первую очередь?
Вам для начала стоит определиться каким программированием вы хотите заняться. На вскидку могу определить три области, железячники, которые начинают с ардуино и продолжают на микроконтроллерах, системные программисты, которые пишут прикладные программы и веб разработчики, которые строят сайт. Это все очень грубые упрощения.
Вы описали очень интересные области. Если судить так, то вот вопрос: Что можете посоветовать для начинающего в области программирования, ну т.е. написание системных программ?
системные программисты, которые пишут прикладные программы
Это уж слишком грубое упрощение.
Системы программисты пишут, как ни странно, системные программы, а прикладные программы, включая веб, пишут прикладные программисты.
Я не знаю в какой сфере вы хотите писать (может вы и сам еще не определились), но вкупе с литературой вашего направления рекомендую Стива Макконнелла — Совершенный код.
Сразу учитесь структурировать и оформлять свои мысли, а параллельно сразу учитесь писать тесты.
Сразу учитесь структурировать и оформлять свои мысли, а параллельно сразу учитесь писать тесты.
Ч.Петцольд — Код. Тайный язык информатики. Идеально для начинающего. Проверил лично.
Причем рекурсию надо знать, что бы потом бежать от нее подальше. Она хороша при обучении, алгоритмы с рекурсией красивы и как правило занимают немного строк кода. Но когда выясняется, что например алгоритм обхода графа падает при обходе реального графа с десятками тысяч параметров, приходит понимание, что алгоритмы из учебника в реальном мире спотыкаются о такие ограничения операционной системы, как размер стека.
К сожалению, об этом часто не задумываются даже очень опытные программисты. Как пример — недавняя проблема в компиляторе андроид, использовавшемся в миллионах телефонов по всему миру:
https://android.googlesource.com/platform/art/+/e5f01223ae03b89767dc7881d75dca061121ee36%5E!/
Обход графа был реализован рекурсивным алгоритмом и вызвал то самое переполненение стека.
https://android.googlesource.com/platform/art/+/e5f01223ae03b89767dc7881d75dca061121ee36%5E!/
Обход графа был реализован рекурсивным алгоритмом и вызвал то самое переполненение стека.
Не всегда это так.
В функциональных языках многие вычисления естественно выражать в виде рекурсивных функций.
Т.к. транслятор может заменять хвостовую рекурсию на итерацию.
В функциональных языках многие вычисления естественно выражать в виде рекурсивных функций.
Т.к. транслятор может заменять хвостовую рекурсию на итерацию.
Никто и не говорит, что всегда. Но многие алгоритмы проще выражаются не хвостовой рекурсией, и здесь компилятор уже беспомощен. К примеру, такой "красивый", прямо математичный, факториал:
pure ulong factorial(uint n)
{
return n <= 1 ? 1 : n * factorial(n - 1);
}Чтобы рекурсию сделать хвостовой, надо уже городить вложенную функцию или нечто иное.
А если ничего не городить и написать вот так
factorial(x, fac) {
if (x == 1)
return fac;
else
return factorial(x-1, x*fac);
}
factorial(x, fac) {
if (x == 1)
return fac;
else
return factorial(x-1, x*fac);
}
Прошу прощение за форматирование
UFO just landed and posted this here
«Огласите весь список, пжлста»(ц)
Вам нужна функция с одним параметром? Нет проблем:
tail_fac(N) -> tail_fac(N,1).
tail_fac(0,Acc) -> Acc;
tail_fac(N,Acc) when N > 0 -> tail_fac(N-1,N*Acc).
Теперь не подойдёт из-за наличия 2-х функций?
Тогда возьмите язык, в котором есть возможность задавать значения по-умолчанию для аргументов функции.
Вам нужна функция с одним параметром? Нет проблем:
tail_fac(N) -> tail_fac(N,1).
tail_fac(0,Acc) -> Acc;
tail_fac(N,Acc) when N > 0 -> tail_fac(N-1,N*Acc).
Теперь не подойдёт из-за наличия 2-х функций?
Тогда возьмите язык, в котором есть возможность задавать значения по-умолчанию для аргументов функции.
UFO just landed and posted this here
Мы с Вами едины в непонимании))
«Чтобы рекурсию сделать хвостовой, надо уже городить вложенную функцию...» — показал, как можно обойтись без вложенной функции
"… факториал по определению функция с одним параметром, а у вас два..." — привел пример с одним параметром и без вложенной функции
И всё равно мимо кассы.
Поэтому и попросил огласить весь список требований, а то создается впечатление(мозгами понимаю, что скорее всего ложное), что требования выдумываются на ходу.
«Чтобы рекурсию сделать хвостовой, надо уже городить вложенную функцию...» — показал, как можно обойтись без вложенной функции
"… факториал по определению функция с одним параметром, а у вас два..." — привел пример с одним параметром и без вложенной функции
И всё равно мимо кассы.
Поэтому и попросил огласить весь список требований, а то создается впечатление(мозгами понимаю, что скорее всего ложное), что требования выдумываются на ходу.
UFO just landed and posted this here
> Не совсем понял, где тут были требования.
Если один, другой варианты не подходят это означает, что существуют требования из-за которых варианты не подходят. Верно?
> Ваши оба примера как раз подходят под «нечто иное»
Согласен. Оба примера подходят под «нечто иное». Но, если последовать такому подходу, то нерекурсивное решение попадает тоже в категорию «нечто иное».
> Представьте себе, что вам нужна функция sin(x)…
Введите в область видимости функцию-обертку с нужным количеством аргументов.
> Единственный момент, с которым я не могу согласиться — «Тогда возьмите язык, в котором»
Подумайте, зачем придумали такое количество языков? И может ли это быть связано с тем, что некоторые языки не предназначены для решения некоторых задач?))
P.S. кстати, требований по поводу языка никто не предъявлял
Если один, другой варианты не подходят это означает, что существуют требования из-за которых варианты не подходят. Верно?
> Ваши оба примера как раз подходят под «нечто иное»
Согласен. Оба примера подходят под «нечто иное». Но, если последовать такому подходу, то нерекурсивное решение попадает тоже в категорию «нечто иное».
> Представьте себе, что вам нужна функция sin(x)…
Введите в область видимости функцию-обертку с нужным количеством аргументов.
> Единственный момент, с которым я не могу согласиться — «Тогда возьмите язык, в котором»
Подумайте, зачем придумали такое количество языков? И может ли это быть связано с тем, что некоторые языки не предназначены для решения некоторых задач?))
P.S. кстати, требований по поводу языка никто не предъявлял
UFO just landed and posted this here
> Верно. Они не подходят под ваше утверждение «А если ничего не городить».
> Определение «городить» было дано выше.
Подходят, по причине того, что дополнительные условия появлялись уже после приводимых решений.
Кстати, могли бы Вы процитировать определение «городить» во избежании путаницы?
> «Чтобы рекурсию сделать хвостовой» означает, что нерекурсивное решение не
> подходит вообще. Т.е. задача стояла сделать из общей рекурсии хвостовую.
> Избавление от рекурсии не решает задачу переделки ее в хвостовую. Но решает
> задачу «посчитать факториал». Которая уже была решена.
Простите, позднее время суток и самочувствие не дают понять «кто на ком стоял». Вы уж не серчайте))
> Я всего лишь хотел сказать, что заставлять пользователя давать функции
> непонятные константые аргументы несколько странно.
Замечательно)) Не хотите заставлять — не надо заставлять. Мы ведь совсем не об этом говорим, не так ли?
> А если ваша задача включат в себя множество подзадач, каждая их которых
> решается лучше всего на своем, отдельном языке?
Посмотрите на игрушки, в которых используется не один язык и каждый для своих задач. Без конкретных примеров задач, которые нужно решать говорить можно долго.
> Или даже так, вам дали проект, вы выбрали язык исходя из описания, работаете,
> пишете, и тут вдруг приходит дополнение, и там посчитать факториал нужно, а ваш
> язык даже хвостовую рекурсию не поддерживает (PHP какой-нибудь).
А давайте немного не так? Представим, что надо посчитать не факториал, а что-то «иное», что составляет львиную долю всего проекта. И тут оказывается, что при рекурсии экономятся ресурсы, а язык уже выбран.
> И никто не говорил, что у вас неудачный выбор языка.
Я снова обращаю внимание, что изначально не было требований к языку, но появились потом и уже с учетом новых требований оценивался предложенный мной вариант.
> Определение «городить» было дано выше.
Подходят, по причине того, что дополнительные условия появлялись уже после приводимых решений.
Кстати, могли бы Вы процитировать определение «городить» во избежании путаницы?
> «Чтобы рекурсию сделать хвостовой» означает, что нерекурсивное решение не
> подходит вообще. Т.е. задача стояла сделать из общей рекурсии хвостовую.
> Избавление от рекурсии не решает задачу переделки ее в хвостовую. Но решает
> задачу «посчитать факториал». Которая уже была решена.
Простите, позднее время суток и самочувствие не дают понять «кто на ком стоял». Вы уж не серчайте))
> Я всего лишь хотел сказать, что заставлять пользователя давать функции
> непонятные константые аргументы несколько странно.
Замечательно)) Не хотите заставлять — не надо заставлять. Мы ведь совсем не об этом говорим, не так ли?
> А если ваша задача включат в себя множество подзадач, каждая их которых
> решается лучше всего на своем, отдельном языке?
Посмотрите на игрушки, в которых используется не один язык и каждый для своих задач. Без конкретных примеров задач, которые нужно решать говорить можно долго.
> Или даже так, вам дали проект, вы выбрали язык исходя из описания, работаете,
> пишете, и тут вдруг приходит дополнение, и там посчитать факториал нужно, а ваш
> язык даже хвостовую рекурсию не поддерживает (PHP какой-нибудь).
А давайте немного не так? Представим, что надо посчитать не факториал, а что-то «иное», что составляет львиную долю всего проекта. И тут оказывается, что при рекурсии экономятся ресурсы, а язык уже выбран.
> И никто не говорил, что у вас неудачный выбор языка.
Я снова обращаю внимание, что изначально не было требований к языку, но появились потом и уже с учетом новых требований оценивался предложенный мной вариант.
Такая штука, как TCO поможет не упасть рекурсивному алгоритму.
Я дико извиняюсь, но:
1. Что за двоичная система «счисления»? Если вы про булевую математику, но вроде как используется только в вентильной системе, до которой вас не допустят. И на секунду, процессор оперирует командами вроде как.
2. Может быть типы данных? А еще лучше разобрать разницу между статичной типизацией и динамической?
3. Логические операции… Это вообще что значит? Паттерны?
4. Другими словами UML.
5. Почему циклы? а почему не массивы?)
6. Какие функции? или вы имели ввиду методы? ну тогда это ведь зависит от фреймворка и парадигмы программирования.
1. Что за двоичная система «счисления»? Если вы про булевую математику, но вроде как используется только в вентильной системе, до которой вас не допустят. И на секунду, процессор оперирует командами вроде как.
2. Может быть типы данных? А еще лучше разобрать разницу между статичной типизацией и динамической?
3. Логические операции… Это вообще что значит? Паттерны?
4. Другими словами UML.
5. Почему циклы? а почему не массивы?)
6. Какие функции? или вы имели ввиду методы? ну тогда это ведь зависит от фреймворка и парадигмы программирования.
Семь вещей, которые нужно знать начинающему программисту:
- Двоичная система счисления
- Типы переменных
- Логические операции
- Блок-схемы
- Циклы
- Функции
- Семь вещей, которые нужно знать начинающему программисту
блок-схемы не нужны, для этого используется мозг
Только в очень простых случаях. Из-за эффекта «дверного проёма» есть огромные шансы упустить важные детали и по этой причине очень быстро закопаться в многочисленных недоработках, недодумках и банальной забывчивости.
Не знаю насчет блок-схем, но диаграммы классов и последовательности действий бывают нужны, поскольку они помогают быстро въехать в архитектуру проекта.
del
UFO just landed and posted this here
Честно говоря, я очень плохо отношусь к статьям подобного рода: «21 способ похудеть, лёжа на диване» или «35 мест, где должен побывать турист». То же касается программирования. Тут один совет: у человека должна быть голова на отведённом ею эволюцией месте, а конкретный способ организации своей деятельности он сам определит, исходя из конкретных условий работы и задач, которые нужно решать.
Вот смотрите сами: «научитесь писать тесты». Что это за совет вообще? Давайте я попробую давать подобные советы: «научитесь программировать без ошибок», «научитесь решать задачи», «научитесь писать код», «научитесь читать код». Ну вот! Теперь Вы на 100500 шагов впереди тех, кто этих советов не знает…
Вот смотрите сами: «научитесь писать тесты». Что это за совет вообще? Давайте я попробую давать подобные советы: «научитесь программировать без ошибок», «научитесь решать задачи», «научитесь писать код», «научитесь читать код». Ну вот! Теперь Вы на 100500 шагов впереди тех, кто этих советов не знает…
Я всё-таки попробую улучшить статью. Восьмой совет.
Научитесь решать задачи
Некоторые разработчики уверены в критической важности умения решать задачи, которое подразумевают написание кода, делающего то, что задумал разработчик. Среди этих людей — Васька Фёдоров, мой сосед, разработчик баз данных в Seventh April Systems. Он пишет: «Думаю, что лучший совет, который я могу дать начинающему разработчику — научиться решать задачи как можно раньше».
Научитесь решать задачи
Некоторые разработчики уверены в критической важности умения решать задачи, которое подразумевают написание кода, делающего то, что задумал разработчик. Среди этих людей — Васька Фёдоров, мой сосед, разработчик баз данных в Seventh April Systems. Он пишет: «Думаю, что лучший совет, который я могу дать начинающему разработчику — научиться решать задачи как можно раньше».
Нужна статья — 45 вещей о которых не нужно писать)
Как-то преподаватель в университете озвучил мне 2 закона.
1. Написанный код с первого раза запустится с ошибкой.
2. Если он запустился без ошибки, значит он работает не правильно.
1. Написанный код с первого раза запустится с ошибкой.
2. Если он запустился без ошибки, значит он работает не правильно.
Научитесь думать абстрактно.
Учитесь проектировать Системы.
Учитесь управлять зависимостями.
Учитесь декомпозировать.
Учитесь писать читаемый код.
Изучите основные алгоритмы.
Учитесь упрощать все и везде, насколько это возможно.
Учитесь писать гибкий расширяемый код.
Познайте среду исполнения с ее возможностями и ограничениями.
Ну и авторитетная цитата: "Учиться, учиться и еще раз учиться!" В. И. Ленин.
deleted
У вас последний абзац переведен неправильно. Там смысл такой — что пишИте хороший код, который можно отдать другим на поддержку. И люди к вам потянутся. И работа будет. А если держаться за свое место и подминать под себя неподдерживаемый другими код — то перестанешь расти как профессионал.
Как-то уже давно, лет 8-10 назад, ко мне на работу устроился студент-отличник (в зачетке все пятерки). Он успорял, что много знает и что умеет программировать. На первый же вопрос, который я обычно задаю всем новичкам, он ответил (со знаком «минус»). Вопрос был таков: «Как наиболее просто узнать значение заданного бита в 16-разрядном слове?» Он написал функцию на ассемблере в >100 строчек кода, применив, наверное, весь знакомый математический аппарат — и это только для выделения заданного бита. На слово мне он не хотел верить, что я все это могу уместить в «одну строчку» кода на том же ассемблере)))))))))) Пришлось доказать))))) Работал он не долго — сами догадаетесь почему))) Потом он устроился в банк, в кредитный отдел… вскорости банк «лопнул» (и тут я закончил линию логических умозаключений))))))
Все это я к чему повествую? А к тому, что не менее важно уметь пользоваться знаниями! Навыки анализа задачи, поиска и сопоставления знаний нужно вывести на уровень условных рефлексов. А без алгоритмического мышления (способности строить алгоритмы) стать программистом (хорошим) очень сложно… Даже имея обширные знания в различных сопутствующих областях…
З.Ы.
Сейчас у меня работает девушка наподобие описанного студента… Зачатки навыка алгоритмизации у нее появились, когда я ей стал давать задачи на GO))) (комплимент этому ЯП)
Все это я к чему повествую? А к тому, что не менее важно уметь пользоваться знаниями! Навыки анализа задачи, поиска и сопоставления знаний нужно вывести на уровень условных рефлексов. А без алгоритмического мышления (способности строить алгоритмы) стать программистом (хорошим) очень сложно… Даже имея обширные знания в различных сопутствующих областях…
З.Ы.
Сейчас у меня работает девушка наподобие описанного студента… Зачатки навыка алгоритмизации у нее появились, когда я ей стал давать задачи на GO))) (комплимент этому ЯП)
UFO just landed and posted this here
Sign up to leave a comment.
Семь вещей, которые нужно знать начинающему программисту