Это то же самое, только в профиль. Т.е. «стать известным» в какой-то сфере. Когда всё, что надо, есть, еще бы славы )))
По моему, это не коррелирует даже с желанием знать побольше, делать работу качественнее, интересом и любовью к программированию. По крайней мере, я не встречал много людей, которые искренне желают быть известными. Но если хотят, то пусть добиваются. Тем не менее, я не вижу причин на собеседованиях ставить это во главу угла.
Получать от работы удовольствие, конечно, важно. Но, ИМХО, эмоции — лишнее.
Хотя бы потому, что если Вы сделаете
комплексную программу проектов общим объемом 6000 чел.*мес. Для меня это вызов.
, после этого за подобную задачу не будет интересно браться. А как быть опытному программисту, когда он уже поучаствовал в нескольких десятках проектов, многие сделал сам, и они охватывают уже все интересные для него сферы? Бросать работу и идти в космонавты ))
Озвучить можно мягко, конечно. Честным быть хорошо.
Но это так же и очевидно. Если человек на собеседовании начнет прямо говорить, что меняет работу ради +ХХХ денег, то как-то не сумел выглядеть немеркантильным, жаждущим знаний, с четкой жизненной позицией и т.д. (прямо по статье). А если еще добавит, что мудаки на прошлой работе достали )))) Тогда Вы его точно не возьмете.
Но ведь человек в первую очередь решает свои личные проблемы. Не надо врать, что он за идею работает.
Конечно, когда опыт большой, когда уже нет особой разницы — везде платят хорошо, то иногда могут найти какой-то интересный плюс в какой-то другой компании. Вроде командировок в Лондон или просто компания более известная. Но опять же, по этим причинам с текущей работы не уходят. Уходят только тогда, когда вынуждают более веские причины.
за всех и сразу отвечу: практически всегда уходят по одной из двух причин или двум сразу — первое, хотят больше зп, второе — напряженные отношения в коллективе (часто с начальством). Ни первое ни второе на собеседованиях никто в своем уме озвучивать не будет.
По-моему, плохой вариант собеседования. Хотя верно, вы же ищете похожих по менталитету, вы и барин.
«Нет «горения» — минус» и «Зрелость личности» — несовместимые вещи. Студентам огня в глазах хоть отбавляй.
Когда компания на собеседованиях давит на то, что им нужны амбициозные люди, с огнем в глазах, у меня сразу же появляется перевод: компания ищет раба за небольшие деньги. На чем еще можно играть, урезая бюджет? На мифических нематериальных бонусах, вроде получения бесценного опыта в интереснейшем проекте лучшей в мире компании.
Зрелость личности — это умение работать без особых мотивационных заморочек. Стрелянный волк, т.е. опытный программист видел разные проекты, все время работает. Работа — это просто рутина и те, кто умеют делать рутину — настоящие профессионалы. Достигают результатов в чем либо только те, кто работает над чем-то каждый день, переводит занятие в привычку. Огни в глазах перегорают за месяц.
Когда слышу слово «воля», «успех» и тому подобное, возникают те же стойкие ассоциации, что либо хотят нанять студента, либо просто общаюсь с человеком с другой по сравнению с моей планетой. Воля нужна для того, чтобы что-то преодолевать. Что-то преодолевать нужно, если есть внутренние барьеры. Внутренние барьеры к работе возникают, только если человек не самоорганизован. Несамоорганизованность появляется от безделья.
Успех — это вообще жесткий мем. Современная промывка мозгов. Как-то без конца слышал про успех, успешность, успешных людей. Ни разу не говорилось, что это успешный хирург (не по баблу, а по знаниям), или успешный физик (10 лет изучал физику и обрел знания). Нет, сейчас успех — это самостоятельное слово. Как бы настолько нагло промывают мозги, мол «вы же сами понимаете, что значит успех».
Прошу прощения за косноязычность. Конечно, я не подразумевал, что ради единственного Last() надо кругом всё превращать в массивы. Ответ немного выше.
Но снова об оптимизации. Зло это. Вообще, думать об оптимизации. Я со всем согласен и с Вами и с постом, не нравится только ракурс — рассматривание проблемы с т.з. того, как это плохо — многократные итерации. И Ваша т.з. — как это плохо — складирование строк в памяти. Как вроде ничего больше в программировании интересного и нет )
Но вообще, действительно, надо выбирать компромисс. Last() — не является родной операцией для IEnumerable(), но при этом, бессмысленно для одного Last() делать какое-то копирование в массив. Там, внутри Last тоже делается свое либо приведение либо какие-то оптимизации, чтобы находить последний элемент без приведения.
Добавить своих расширяющих методов можно. Часто передаются IEnumerable<> кругом. Но при этом, если программисты пользуются в своим коде List<>. Чтобы не идти на компромиссы, выбирая, что же надо передавать кругом — связный список (IEnumerable<>) или список с индексным доступом(IList<>), а ToList() делает копию, что бывает накладно, то можно добавить такой метод:
IReadOnlyList<> ToReadOnlyListByRefOrCopy(...)
А там проверять, если это список, то приводить просто по ссылке и возвращать враппер, если нет — враппер над копией.
Таким образом получите некий компромисс между производительностью и выразительностью кода. Как только нужен индексный доступ — вызвали этот метод.
Типами можно хорошо описывать намерения. Не всегда всё гладко получается и с типизацией проблемы, но имхо, лучше уже так, чем просто беспорядочно IEnumerable<> использовать.
У IEnumerable просто даже нет последнего элемента по смыслу. Это просто множество без заданного порядка. Нет гарантии, что два перебора дадут тот же самый порядок и что один и тот же элемент будет в конце.
Сложная тема. Последняя строка как по мне — недостаточно. Поиск последней строки — это тоже индексный поиск. Также Count() — неродная операция.
У интерфейсов есть назначение. IEnumerable нужен только для перебора, возможно бесконечных множеств. Если программист объявляет такой тип, он это и декларирует — ему надо перебрать, ему не важен порядок элементов (индексы) и т.д.
ElementA(), Last(), Count() — это всё экстеншин методы, они не входят в IEnumerable. По моему, типами, программист также говорит о том, что он собирается делать. Это улучшает читаемость.
Если бы C# был таким чистым функциональным языком с немутабельными типами — то особых проблем бы не было с вызовом этих методов и с итерациями. Можно бы было один список, как в Lisp использовать для всего. C# не может гарантировать в общем случае, что в множестве не изменяются элементы от вызова к вызову, поэтому не может использовать ленивые оптимизации.
А поэтому, лучше использовать правильные типы.
Если нужен индексный доступ, то по смыслу самому List (в смысле вектор для плюсовиков) подходит явно. Конечно, на любых переборах, не зависимо от структуры данных программист может найти по индексу элемент. И не должен задумываться, что там за структура.
Но и интерфейсы тоже не говорят, что за структуры на самом деле используются. Поэтому тут дело не в оптимизации. Если программист в методе решил использовать индексный доступ, то он декларирует это типом переменной.
Повсеместное использование в сигнатурах методов IEnumerable нарушает принципы программирования по контракту и ведет к ошибкам.
Неожиданный вывод. IEnumerable только говорит о том, что программист собрался перебрать элементы, не более. И очень часто именно это и надо, чаще, чем остальные случаи.
var lines = File.ReadLines("data.txt");
string lastLine = lines.ElementAt(lines.Count());
Говорит только о том, что здесь явно не IEnumerable нужен. ElementAt — это просто не родная операция для него. Если решили использовать Count() или ElementAt() — то скорее контракт нарушен, когда заводили переменную/параметр типа IEnumerable
Как раз я тот фильм и подразумевал. Это в нем юмор такой, потому что обыватели смеялись из этой комбинации с возгласами: ну и какая же вероятность такой комбинации? ))
Работает мозг просто так — он категоризирует. Если он хочет случайное число, то он делит на субъективные группы, потом группы на группы. Причем, конец, начало и середина — по размерам не одинаковы. А самое последнее число явно последнее всех. В лотереях, думаю, не было подражателей. Просто потому, что человек явно начинает понимать что вероятность такой комбинации низкая. А если он бы понимал, что любая комбинация имеет такую вероятность, то не играл бы в лотереи )
Это не недостаток самой идеи реляционных баз данных. Сейчас крайне модно и даже никто не видит подвоха — создавать 2 конкурирующих сервера, решающих одну и ту же задачу — на языке вроде джавы, шарпа, который «взаимодействует» с БД. Вся цель его, всего лишь ослабить реляционную модель, бороться с ней, дублировать логику (писать классы, отражающие таблицы), гонять данные туда сюда с сериализацией, создать свой транзакционный механизм, который, конечно, слабее. Т.е. в любом проекте с БД, создается такой велосипедище, причем это считается правилом хорошего тона.
Думаю, сервер должен быть один. В теории. Не надо дублировать логику, дублировать схему. К сожалению, на мой взгляд реляционные СУБД для этого могли бы сгодиться, но они не доделаны. SQL хорош, но недостаточен. А процедурные языки унылы и неудобны. Бросили нас производители реляционных СУБД и гоняются только между собой за производительность некоторых операций.
конечно, не будет. Когда человека просят выбрать случайное число, он его выбирает не случайно. В лотереях, например, никто не выбирает значение 1, 2, 3, 4, 5, 6. Хотя вероятность выпасть такой комбинации одинакова с любой другой.
Так и здесь. Примерно, мыслят так. Чтобы было абсолютно случайное, надо брать не по краям и не максимум с минимумом. А то эти значения для мозга слишком выделяются.
И еще, почему я думаю, что надо ошибкам активно себя проявлять вплоть до падения. Проявления ошибок и количество ошибок — разные вещи. Ошибок на самом деле не много. Я думаю, можно писать без ошибок. Мнение, что ошибки есть всегда, стало настолько популярным, что почти приравнивается к «давайте не искать». Даже в больших системах, если не рассматривать потенциальные баги, неверную архитектуру, то ошибок в районе — 10-20. А проявляться они могут сколько угодно раз в день.
Чем активнее применяются методы для их отлова, тем быстрее код станет чистым. И один из самых эффективных способов — это написание кода так, чтобы в нем не было компромиссов. Каждый метод делает что-то одно, представляет, что ему дают параметры такие как надо, если нет — падает, а также, если он не смог выполнить то, что от него требуется — падает.
Что-то я не помню в своем опыте такого, чтобы заплатки на самом деле делали что-то полезное, а не делали кажущуюся полезность. Бывает, сталкивался с чужим кодом. И не всегда, правда, можно сказать: а была ли заплатка. При детальном рассмотрении оказывается, что баг работает невидимым в продакшене полгода-пара лет. И он не просто там был и ел какие-то ресурсы процессора. Он приносил денежные убытки.
Если же Вы рассматриваете заплатку — как разработка нового функционала в старой системе без детального раздумывания над архитектурой и без рефакторинга, то может быть.
А вообще, я не согласен с роликом, что эволюция работает. В наших языках программирования не работает. Погибает вся популяция ) Она бы работала, если бы языки были подобны генетическим алгоритмам и создавался сразу большой оверхед — на каждое требование рождалось много разных решений и в процессе эволюции плохие погибали, лучшие оставались. Заплатки чтобы временно действовали, я сам движок искал новые правильные решения. Может быть когда-то такие языки будут.
А сейчас мы пишем только одно решение. И оно либо верно, либо нет. Причем, «некритичных» ошибок практически не бывает. Отрисовка в ГУИ некритична, но такие ошибки редкие. Каждая ошибка нарушает процесс работы системы. И урон зависит разве что от того, зачем сделана система.
Вот, один из примеров заплаток. В компании N ищут клиента банка по базе. Если почему-то не находят (а должны), берут первого попавшегося случайного. Какая жесть с ним дальше может произойти, даже рассказывать не буду.
Если же Вы рассматриваете какую-то онлайн-игру, где потеря виртуальных денег или чего-то там, разве что сильно расстроит игрока, но не нанесет ему никакого материального ущерба — то можно при наличии тысяч ошибок лепить заплатки. Но если Вы надеетесь, что они приживутся, то Вы рассматриваете код, как человек, впервые севший за компьютер, обучаться программированию. Когда у него сдают нервы и он начинает менять в программе наугад разные части, чтобы ответ начал сходиться к правильному.
какое-то свободное манипулирование цифрами и законом Мура.
Оттого, что количество багов растет квадратично (это в очень плохом случае, наверное), не следует вывод — что их не надо искать, а писать заплатки. Такие заплатки — сами по себе очень сильно влияют на количество багов. Это не независимые вещи. Скрыли баг, плюс к этому еще скорее увеличили урон. Заплатка — это код, который связан с багом. Таким образом, выпилить баг, если его еще видеть будут — будет значительно сложнее. Количество кода связанного с багами растет.
Поэтому нельзя рассматривать рост количества багов без учета того, что делается, чтобы их не было.
Второе — баги могут быть очень вредны. Т.е. если что-то с производительностью — это куда не шло. А если самолет упадет, сердце станет? Да и просто банковские операции. Клиент не обрадуется, если деньги пропадут.
Третье, наши языки программирования все таки не нейронные сети и не генетические алгоритмы. Они не умеют «самолечиться», выводить закономерности. Так что заплатки резко тянут корабль ко дну.
Язык программирования — язык выражения мыслей. Как инглишь. Можно знать грамматику, но это не делает лингвистом и переводчиком. На языке можно говорить о космосе, о погоде, о музыке, о чем угодно, а не о презент континиус и наречиях. Но тем не менее, можно и о наречиях тоже.
Беда в том, что в основном программисты только о грамматике и пишут в коде.
Тем не менее, те, кто могут писать не о грамматике, точно так же могут писать о грамматике. Они в этом не ущербнее. Правильнее сказать: возможно, джедаи хоть в созданиях фреймворков пригодятся. Но я бы не надеялся )
Тут и не поспоришь. Кроме уточнения с велосипедами. С велосипедами нужен баланс. В реальном проекте надо как можно больше использовать готовых решений, чтобы сэкономить себе и заказчику нервы. Но с оглядкой.
1. Затраты на изучение работы с чужим функционалом должны быть меньше, чем создание и поддержка своего. Если нужно всего немного функционала, и пишется он легко, — то возможно не надо чужой код. Часто чужие библиотеки несут большой оверхед, но что обидно, бывает при этом, не дают нужного функционала точно для текущего проекта.
2. Учитывать риски в связи с кодом от третьих лиц. Лучше использовать известное, отработанное решение. Потому как в другом случае и багов может быть в нем много и поддержки никакой.
А велосипеды, да, каждый программист просто обязан пописать, чтобы понять как оно устроено, понять сложности и не писать в реальных проектах, уважать чужой труд.
Фичи и новые фреймворки не являются приоритетом, хотя для себя надо их по мере возможности изучать и понимать, что они могут дать. Не являются приоритетом, потому что заказчика не мотивируешь тем, что в коде используется что-то модное. И как раз по моему, самая главная отличительная черта профессионала в любом деле — в том, что он принимает и решает любую проблему как свою личную. Если он создает проект для заказчика, то он стремится к качеству и уменьшению сроков. Если программист считает, что заказчик должен ему просто так платить и он будет фаном заниматься, потому что других не найдет — это уже как-то не серьезно. Стремиться к качеству и уменьшению сроков — это тоже интересно и приносит удовольствие. Самоорганизовывает, заставляет включать в процесс разработки не только код, но и другие вещи, делает интересной работу, которая могла бы показаться в других случаях неинтересной.
Вы смотрите с позиции оптимизации. Если выбор пал на int только потому, что он меньше в памяти занимает и якобы хватает — то это, понятно, не верно.
Я имею ввиду, если переменная должна хранить по смыслу количество или что-то, счетное. Double — тоже может. Но такой выбор — потенциальный баг
Пост ровно о том, как не писать говнокод. Если думаете, что возможно либо писать продуманную архитектуру, либо говнокод, то вот:
Смешная вымышленная история, как архитектор вообще не смог завершить проект: Как два программиста хлеб пекли
И моя попытка показать, что второй программист не обязан быть говнокодером: Хлеб Маркуса и YAGNI
Краткость — не только сестра таланта, но и сестра абстрагирования. Абстрагирование в программировании — это по сути — избавление от рутины, т.е. повторяющейся деятельности. Т.е. повторяющегося кода. Плюс такого подхода, что абстракции если и возникают, то возникают совершенно обоснованно, а не как карта легла у креативного программиста в голове.
По сути, такой подход к разработке отличается от предварительного планирования только тем, что программист «планирует в действии». Есть люди, которые любят играть в шахматы в уме. Но проще на доске. И от мазохизма избавляемся. Язык программирования — отличная вещь для представления абстракций. И программист, следуя прямому выражению мысли, меняющимся требованиям не брезгует прикасаться к клавиатуре, когда планирует. Он как бы еще при этом пользуется настоящим языком программирования, как своим родным языком — показывая, что он никакой не сантехник, не бухгалтер и не электрик — ему роднее язык программирования.
А так, в принципе, то же самое планирование, только на языке программирования и в действии. Человек в голове тоже обычно задачи на куски разбивает, не может всё одновременно продумывать. Так почему бы не записывать.
Это то же самое, только в профиль. Т.е. «стать известным» в какой-то сфере. Когда всё, что надо, есть, еще бы славы )))
По моему, это не коррелирует даже с желанием знать побольше, делать работу качественнее, интересом и любовью к программированию. По крайней мере, я не встречал много людей, которые искренне желают быть известными. Но если хотят, то пусть добиваются. Тем не менее, я не вижу причин на собеседованиях ставить это во главу угла.
Получать от работы удовольствие, конечно, важно. Но, ИМХО, эмоции — лишнее.
Хотя бы потому, что если Вы сделаете, после этого за подобную задачу не будет интересно браться. А как быть опытному программисту, когда он уже поучаствовал в нескольких десятках проектов, многие сделал сам, и они охватывают уже все интересные для него сферы? Бросать работу и идти в космонавты ))
Но это так же и очевидно. Если человек на собеседовании начнет прямо говорить, что меняет работу ради +ХХХ денег, то как-то не сумел выглядеть немеркантильным, жаждущим знаний, с четкой жизненной позицией и т.д. (прямо по статье). А если еще добавит, что мудаки на прошлой работе достали )))) Тогда Вы его точно не возьмете.
Но ведь человек в первую очередь решает свои личные проблемы. Не надо врать, что он за идею работает.
Конечно, когда опыт большой, когда уже нет особой разницы — везде платят хорошо, то иногда могут найти какой-то интересный плюс в какой-то другой компании. Вроде командировок в Лондон или просто компания более известная. Но опять же, по этим причинам с текущей работы не уходят. Уходят только тогда, когда вынуждают более веские причины.
«Нет «горения» — минус» и «Зрелость личности» — несовместимые вещи. Студентам огня в глазах хоть отбавляй.
Когда компания на собеседованиях давит на то, что им нужны амбициозные люди, с огнем в глазах, у меня сразу же появляется перевод: компания ищет раба за небольшие деньги. На чем еще можно играть, урезая бюджет? На мифических нематериальных бонусах, вроде получения бесценного опыта в интереснейшем проекте лучшей в мире компании.
Зрелость личности — это умение работать без особых мотивационных заморочек. Стрелянный волк, т.е. опытный программист видел разные проекты, все время работает. Работа — это просто рутина и те, кто умеют делать рутину — настоящие профессионалы. Достигают результатов в чем либо только те, кто работает над чем-то каждый день, переводит занятие в привычку. Огни в глазах перегорают за месяц.
Когда слышу слово «воля», «успех» и тому подобное, возникают те же стойкие ассоциации, что либо хотят нанять студента, либо просто общаюсь с человеком с другой по сравнению с моей планетой. Воля нужна для того, чтобы что-то преодолевать. Что-то преодолевать нужно, если есть внутренние барьеры. Внутренние барьеры к работе возникают, только если человек не самоорганизован. Несамоорганизованность появляется от безделья.
Успех — это вообще жесткий мем. Современная промывка мозгов. Как-то без конца слышал про успех, успешность, успешных людей. Ни разу не говорилось, что это успешный хирург (не по баблу, а по знаниям), или успешный физик (10 лет изучал физику и обрел знания). Нет, сейчас успех — это самостоятельное слово. Как бы настолько нагло промывают мозги, мол «вы же сами понимаете, что значит успех».
Но снова об оптимизации. Зло это. Вообще, думать об оптимизации. Я со всем согласен и с Вами и с постом, не нравится только ракурс — рассматривание проблемы с т.з. того, как это плохо — многократные итерации. И Ваша т.з. — как это плохо — складирование строк в памяти. Как вроде ничего больше в программировании интересного и нет )
msdn.microsoft.com/en-gb/library/hh881542.aspx
Но вообще, действительно, надо выбирать компромисс. Last() — не является родной операцией для IEnumerable(), но при этом, бессмысленно для одного Last() делать какое-то копирование в массив. Там, внутри Last тоже делается свое либо приведение либо какие-то оптимизации, чтобы находить последний элемент без приведения.
Добавить своих расширяющих методов можно. Часто передаются IEnumerable<> кругом. Но при этом, если программисты пользуются в своим коде List<>. Чтобы не идти на компромиссы, выбирая, что же надо передавать кругом — связный список (IEnumerable<>) или список с индексным доступом(IList<>), а ToList() делает копию, что бывает накладно, то можно добавить такой метод:
IReadOnlyList<> ToReadOnlyListByRefOrCopy(...)
А там проверять, если это список, то приводить просто по ссылке и возвращать враппер, если нет — враппер над копией.
Таким образом получите некий компромисс между производительностью и выразительностью кода. Как только нужен индексный доступ — вызвали этот метод.
Типами можно хорошо описывать намерения. Не всегда всё гладко получается и с типизацией проблемы, но имхо, лучше уже так, чем просто беспорядочно IEnumerable<> использовать.
У интерфейсов есть назначение. IEnumerable нужен только для перебора, возможно бесконечных множеств. Если программист объявляет такой тип, он это и декларирует — ему надо перебрать, ему не важен порядок элементов (индексы) и т.д.
ElementA(), Last(), Count() — это всё экстеншин методы, они не входят в IEnumerable. По моему, типами, программист также говорит о том, что он собирается делать. Это улучшает читаемость.
Если бы C# был таким чистым функциональным языком с немутабельными типами — то особых проблем бы не было с вызовом этих методов и с итерациями. Можно бы было один список, как в Lisp использовать для всего. C# не может гарантировать в общем случае, что в множестве не изменяются элементы от вызова к вызову, поэтому не может использовать ленивые оптимизации.
А поэтому, лучше использовать правильные типы.
Но и интерфейсы тоже не говорят, что за структуры на самом деле используются. Поэтому тут дело не в оптимизации. Если программист в методе решил использовать индексный доступ, то он декларирует это типом переменной.
Неожиданный вывод. IEnumerable только говорит о том, что программист собрался перебрать элементы, не более. И очень часто именно это и надо, чаще, чем остальные случаи.
Говорит только о том, что здесь явно не IEnumerable нужен. ElementAt — это просто не родная операция для него. Если решили использовать Count() или ElementAt() — то скорее контракт нарушен, когда заводили переменную/параметр типа IEnumerable
Работает мозг просто так — он категоризирует. Если он хочет случайное число, то он делит на субъективные группы, потом группы на группы. Причем, конец, начало и середина — по размерам не одинаковы. А самое последнее число явно последнее всех. В лотереях, думаю, не было подражателей. Просто потому, что человек явно начинает понимать что вероятность такой комбинации низкая. А если он бы понимал, что любая комбинация имеет такую вероятность, то не играл бы в лотереи )
Лучший способ сломать систему — иметь кубик )
Думаю, сервер должен быть один. В теории. Не надо дублировать логику, дублировать схему. К сожалению, на мой взгляд реляционные СУБД для этого могли бы сгодиться, но они не доделаны. SQL хорош, но недостаточен. А процедурные языки унылы и неудобны. Бросили нас производители реляционных СУБД и гоняются только между собой за производительность некоторых операций.
Так и здесь. Примерно, мыслят так. Чтобы было абсолютно случайное, надо брать не по краям и не максимум с минимумом. А то эти значения для мозга слишком выделяются.
Чем активнее применяются методы для их отлова, тем быстрее код станет чистым. И один из самых эффективных способов — это написание кода так, чтобы в нем не было компромиссов. Каждый метод делает что-то одно, представляет, что ему дают параметры такие как надо, если нет — падает, а также, если он не смог выполнить то, что от него требуется — падает.
Если же Вы рассматриваете заплатку — как разработка нового функционала в старой системе без детального раздумывания над архитектурой и без рефакторинга, то может быть.
А вообще, я не согласен с роликом, что эволюция работает. В наших языках программирования не работает. Погибает вся популяция ) Она бы работала, если бы языки были подобны генетическим алгоритмам и создавался сразу большой оверхед — на каждое требование рождалось много разных решений и в процессе эволюции плохие погибали, лучшие оставались. Заплатки чтобы временно действовали, я сам движок искал новые правильные решения. Может быть когда-то такие языки будут.
А сейчас мы пишем только одно решение. И оно либо верно, либо нет. Причем, «некритичных» ошибок практически не бывает. Отрисовка в ГУИ некритична, но такие ошибки редкие. Каждая ошибка нарушает процесс работы системы. И урон зависит разве что от того, зачем сделана система.
Вот, один из примеров заплаток. В компании N ищут клиента банка по базе. Если почему-то не находят (а должны), берут первого попавшегося случайного. Какая жесть с ним дальше может произойти, даже рассказывать не буду.
Если же Вы рассматриваете какую-то онлайн-игру, где потеря виртуальных денег или чего-то там, разве что сильно расстроит игрока, но не нанесет ему никакого материального ущерба — то можно при наличии тысяч ошибок лепить заплатки. Но если Вы надеетесь, что они приживутся, то Вы рассматриваете код, как человек, впервые севший за компьютер, обучаться программированию. Когда у него сдают нервы и он начинает менять в программе наугад разные части, чтобы ответ начал сходиться к правильному.
Оттого, что количество багов растет квадратично (это в очень плохом случае, наверное), не следует вывод — что их не надо искать, а писать заплатки. Такие заплатки — сами по себе очень сильно влияют на количество багов. Это не независимые вещи. Скрыли баг, плюс к этому еще скорее увеличили урон. Заплатка — это код, который связан с багом. Таким образом, выпилить баг, если его еще видеть будут — будет значительно сложнее. Количество кода связанного с багами растет.
Поэтому нельзя рассматривать рост количества багов без учета того, что делается, чтобы их не было.
Второе — баги могут быть очень вредны. Т.е. если что-то с производительностью — это куда не шло. А если самолет упадет, сердце станет? Да и просто банковские операции. Клиент не обрадуется, если деньги пропадут.
Третье, наши языки программирования все таки не нейронные сети и не генетические алгоритмы. Они не умеют «самолечиться», выводить закономерности. Так что заплатки резко тянут корабль ко дну.
Язык программирования — язык выражения мыслей. Как инглишь. Можно знать грамматику, но это не делает лингвистом и переводчиком. На языке можно говорить о космосе, о погоде, о музыке, о чем угодно, а не о презент континиус и наречиях. Но тем не менее, можно и о наречиях тоже.
Беда в том, что в основном программисты только о грамматике и пишут в коде.
Тем не менее, те, кто могут писать не о грамматике, точно так же могут писать о грамматике. Они в этом не ущербнее. Правильнее сказать: возможно, джедаи хоть в созданиях фреймворков пригодятся. Но я бы не надеялся )
1. Затраты на изучение работы с чужим функционалом должны быть меньше, чем создание и поддержка своего. Если нужно всего немного функционала, и пишется он легко, — то возможно не надо чужой код. Часто чужие библиотеки несут большой оверхед, но что обидно, бывает при этом, не дают нужного функционала точно для текущего проекта.
2. Учитывать риски в связи с кодом от третьих лиц. Лучше использовать известное, отработанное решение. Потому как в другом случае и багов может быть в нем много и поддержки никакой.
А велосипеды, да, каждый программист просто обязан пописать, чтобы понять как оно устроено, понять сложности и не писать в реальных проектах, уважать чужой труд.
Фичи и новые фреймворки не являются приоритетом, хотя для себя надо их по мере возможности изучать и понимать, что они могут дать. Не являются приоритетом, потому что заказчика не мотивируешь тем, что в коде используется что-то модное. И как раз по моему, самая главная отличительная черта профессионала в любом деле — в том, что он принимает и решает любую проблему как свою личную. Если он создает проект для заказчика, то он стремится к качеству и уменьшению сроков. Если программист считает, что заказчик должен ему просто так платить и он будет фаном заниматься, потому что других не найдет — это уже как-то не серьезно. Стремиться к качеству и уменьшению сроков — это тоже интересно и приносит удовольствие. Самоорганизовывает, заставляет включать в процесс разработки не только код, но и другие вещи, делает интересной работу, которая могла бы показаться в других случаях неинтересной.
Я имею ввиду, если переменная должна хранить по смыслу количество или что-то, счетное. Double — тоже может. Но такой выбор — потенциальный баг
Смешная вымышленная история, как архитектор вообще не смог завершить проект:
Как два программиста хлеб пекли
И моя попытка показать, что второй программист не обязан быть говнокодером:
Хлеб Маркуса и YAGNI
Краткость — не только сестра таланта, но и сестра абстрагирования. Абстрагирование в программировании — это по сути — избавление от рутины, т.е. повторяющейся деятельности. Т.е. повторяющегося кода. Плюс такого подхода, что абстракции если и возникают, то возникают совершенно обоснованно, а не как карта легла у креативного программиста в голове.
По сути, такой подход к разработке отличается от предварительного планирования только тем, что программист «планирует в действии». Есть люди, которые любят играть в шахматы в уме. Но проще на доске. И от мазохизма избавляемся. Язык программирования — отличная вещь для представления абстракций. И программист, следуя прямому выражению мысли, меняющимся требованиям не брезгует прикасаться к клавиатуре, когда планирует. Он как бы еще при этом пользуется настоящим языком программирования, как своим родным языком — показывая, что он никакой не сантехник, не бухгалтер и не электрик — ему роднее язык программирования.
А так, в принципе, то же самое планирование, только на языке программирования и в действии. Человек в голове тоже обычно задачи на куски разбивает, не может всё одновременно продумывать. Так почему бы не записывать.