Comments 131
А так, главное в программирование такое же как и везде — четкое видение результата. Если оно есть, то код пишется легко и свободно, если программирование идёт с трудом, то значит либо цель поставлена плохо, либо это не ваше.
Иногда сталкивался с ситуациями когда результат ясен, но достижение результата дается тяжело, хотя бы по причине необходимости освоить новую, не очень простую предметную область.
Поэтому, если программирование при решении задачи придаёт вам сил, значит это ваше, если отнимает силы — значит не ваше.
P.S.
Девушка вымышленная и вы не позволяете ей собой манипулировать.
Рутиной было бы сферическое программирование в вакууме. Положение спасают программисты. Они привносят первозданный хвос в этот процесс, делая его нескучным вплоть до адреналиновой интоксикации.
А какой весёлый/нескучный/ужасный код они пишут! Особенно этот подлец, Я-вчерашний.
А в программировании, сегодня сложная задача, завтра решается в 10 минут написание кода
Немного не так. Сегодня сложная задача, завтра её кто-то решил, послезавтра есть готовая либа, которой все спокойно пользуются.
Сложно от ВИЧ вылечится. Высокая смертность.
То что сложно сегодня, завтра обыденность. Буквально недавно появились новые антиретровирусные препараты и вакцины которые повышают устойчивость к вирусу до 99%. (у Шимпанзе во всяком случае). Да и вот только недавно у исследователей инструменты нормальные появились. Уж не говоря о том что начало изучению ДНК не сильно то и много, а вот уже и CRISPR, и вот уже у первого человека "пофиксили" ген.
По факту "сложность" тут — этические ограничения и очень долгий цикл от возникновения до проверки идей.
Сложно на Марс полететь. 50% полетов неудачные.
Как будто бы программирование тут не причем.
код то да, не сложно писать, сложность во всех остальных аспектах работы программиста.
Логика программирования заключается в том, чтобы разбить большую задачу на маленькие подзадачи и последовательно реализовать их, а потом связать воедино.согласен на 100%. Этот подход стоит использовать и в управлении проектом (макро). Видел сам, как опытные программисты впадают в уныние, когда перед ними стоит плохо описанная, большая задача. Если ее не разбить на мелкие, легко выполнимые задачи, то можно засесть в таком «болоте» надолго. И тут нельзя не отметить (из чистого прагматизма), что agile, как методика, делает именно это.
Друг резюмировал, что это как раз потому так легко получилось, что задача была чётко расписана по пунктам. и советовал мне всегда так делать )
У меня всегда такая проблема. И в работе и в жизни и вообще(( даже не знаю что делать.
Еще хорошо помню, недавно было. Изучал самое начало, делал задание по видео (по сути потворить только), но как только дошел до CheckBox, все забросил и появилась (опять таки подсказывали в инете) нужная и полезная для себя программа. Вторая рождается уже, как впрочем и вопросы с нею, почему так работает правильно, а так нет. Но после этого все же вернусь обучаться дальше по сценарию :), может еще что-то попадется интересное.
почему-то так сложилось, что я могу продуктивно кодить только в подобии «биполярного расстройства», когда кидает из эйфории в депрессию и обратно.
Точное следование самому подробному уроку не помогает.
а с каких пор оно должно помогать? Это урок. Там обычно учат делать что-то одно и оно чаще не прибавляет понимание того как это работает. Читайте документацию, следите за изменениями фреймворка в ишус трекерах/пул реквестах (благо сейчас это просто), читайте исходники (если совсем круто хотите знать инструмент, чаще это не нужно).
нужен какой-то бек, в котором нет желания разбираться, если ты пытаешься быть фронт.
Пишите бэк на nodejs, сейчас к тому же есть масса serverless решений.
Меня к примеру в уныние и тоску повергают люди которые хотят развиваться но ничего для этого не делают. И таких много. А еще — часто проблема не в том что "технологий много и быстро развиваются" а скорее в хайпе. Технологии достаточно медленно развиваются и концепции в целом имеют более цикличный характер. Сейчас модно то что было модным 10 лет назад просто в другом контексте.
Просто прекрасно понимаю, что при должном упорстве моем и планировании почти любая задача посильна. Всегда только встает вопрос, а сколько времени это займет: неделя, месяц или вовсе полгода?
Могу конечно лениться как последний разгильдяй, находиться в прокрастинации перед новой для меня сложной задачей, но при этом не считаю себя ничтожеством или еще кем-то нехорошим =)
В какой-то момент бывает радуюсь очень, что решил эту, будь она неладна, задачу, которая недели две насиловала мне мозг. Горжусь собой, но разве это возвышение себя Олимп, не думаю.
Много знаю людей, которые профессиональнее меня во многом, смотря на них, хочется расти дальше, но и вижу много людей, которые менее профессиональны и тут грустно, хочется как-то поделиться опытом, помочь.
Какая яма? Зачем? Почему?
То что я чего-то не знаю не повод себя угнетать и никогда им не станет.
Никогда не боялся показать себя дураком. Спокойно задаю глупые вопросы, дабы потом поумнеть.
Но бывают такие регионы, где очень трудно найти постоянную стабильную работу IT-шнику. Где недостаток рабочих мест. Тут только по фриланс подаваться или любую работу брать, лишь бы выжить.
Согласен, это может очень угнеть, но веру в себя терять не стоит =)
Особенно матерюсь, когда мой код начинают дорабатывать люди, которые не особо разбираясь впихнут кусок говнокода. Приходится потом рефакторить в рамках смежных задач.
Порой случается ошибка в ТЗ и приходится переделывать много, иногда играем с тестировщиками в пинг-понг с целью: кто прав, кто виноват.
Стресса хватает, но это даже весело. Особенно когда что-то на проде ломается и надо шустро починить, быстрая доза эйфории =)
habrahabr.ru/post/275841
А к теме что сложного, вот неплохие статьи:
habrahabr.ru/post/120471
eax.me/caching-is-hard
А в ней ничего сложного обычно нет
ну как сказать, конкретно в этом случае сложность в том как уменьшить количество кэш мисов.
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
Есть только две трудные задачи в области информатики: инвалидация кеша и придумывание названий
Мне больше по душе другая версия этого изречения (:
Есть только две трудности в программировании: инвалидация кеша, придумывание названий и ошибки на единицу
«Хорошая новость про компьютеры: они всегда делают то, о чем вы их просите. Но есть и плохая: они всегда делают то, о чем вы их просите.»
Жаль, но в современном мире компьютеры делают не только то, о чем их просите вы, а ещё прорву разных дел, о которых его просили разработчики ОС и ПО, которое на ней установлено. И из-за этого бывает так, что криво написанное ПО "Х" ломает твою хорошую программу "У". Про IME и ему подобные просто молчу. Для простых программ, к счастью, такие проблемы обычно не актуальны, но бывает и иначе...
Пункт 2 привёл меня в программирование. Когда я понял, что все только в моих руках, что между идеей и реализацией стоит только моё незнание я начал постоянный ликбез, короче, очень увлекательно и некого винить.
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
Хотя описанные в статье вещи действительно не так очевидны и просты как кажутся.
Для этого существуют бизнес-аналитики. Хотя в общем знать область деятельности очень желательно, но не жизненно необходимо.
Проекты бывают разные и каждый требует особых знаний, так что это скорее естественное умение в нашем ремесле — уметь понимать любую Предметную Область.
Программирование оторванное от мира не несет смысла.
Уже как мантра звучит мнение о том, что постоянно нужно изучать новые и новые технологии. А учитывая контекст советов в данной статье, для меня это звучит как призыв поучаствовать в гонке за модой, так как зачастую ничего нового в этих "новых" технологиях нет. Не понимаю этого.
Если фундаментальные принципы меняются редко, то инструменты — чуть ли не каждый день. Важно следить за всеми новинками и уметь самостоятельно осваивать необходимые для вас.
Да, вы можете выбрать какую-то одну вещь и стать специалистом в ней, но тогда вы очень рискуете, что в это же время появилось что-то новое, многократно превосходящее вашу технологию и это нечто завоюет рынок, в то время как вы держитесь за старьё обеими руками.
Инструменты решают лишь технические проблемы. И знание большого количества инструментов, не всегда ведет к пониманию концептуальной проблемы. Фундаментальные знания, напротив, позволяют широко мыслить о проблеме и приводят к правильному выбору инструментов для ее технического решения. Например, не нужно глубоко знать все языки, чтобы понимать какой лучше применить, для решения некой задачи, достаточно лишь понимать, на каких принципах основан язык, и на сколько хорошо эти принципы могут помочь для решения задачи, в контексте с прочими факторами. Следовательно важны базовые знания и понимание предметной области проблемы, а не знание конкретных технологий, которое очень быстро выветривается, если перестать этими технологиями пользоваться.
Я не говорю, что не нужно актуализировать инструменты, особенно если они дают существенные преимущества для решения некоторых проблем. Но нужно стремиться к тому, что бы базовые знания, давали представление о технологии, а не непосредственное изучение конкретной технологии.
Например, берем Node, видим что она работает в одном потоке, код выполняется асинхронно, а связывающим звеном является event-loop. Это уже дает представление, о том как различные части программы могут взаимодействовать между собой, какие плюсы и минусы из этого можно получить. Берем экспресс, видим что API позволяет нам обрабатывать данные по средствам обратных вызовов, а часть типовой логики предлагается вынести в промежуточные обработчики запросов (middleware), и понимаем, что с чем и как должно работать тут, какие задачи могли возникнуть не только у вас (авторизация, рендер шаблонов и все такое), а следовательно для чего могут быть уже готовые решения на базе этого Express. Берем Koa, видим корутины и опять же делаем выводы о концепции библиотеки и с какой стороны лучше подходить к ее использованию, а дальше дело лишь за изучение API. И так далее, от общего к частному.
хотя умом понимаю, что много теряю от такого подхода
Аналогии не всегда корректны бывают, но если говорить про вождение машины, то например умом вы должны понимать, что чем ниже передача, тем большее ускорение вы можете получить, допустим, при старте или двигаясь в гору. Совершенно не обязательно знать при этом как устроена коробка передач вплоть до каждого болта. Посмотрите на профессиональных гонщиков, они имеют ясное представление о том как давление в шинах или температура тех же покрышек влияют на управляемость, а это лишь малая часть из тех нюансов, касательно шин, за которыми постоянно нужно следить, для обеспечения максимальной эффективности их работы. И вовсе не обязательно понимать, каким образом скорость движения атомов, в некотором веществе, влияет на сцепление этого вещества с другим. Понимание некоторых вещей может приходить опытным путем и доведено до автоматизма, но теоретические знания позволяют иметь более широкое представление о каком-либо явлении и позволяют делать различные следствия, особенно когда теория начинает коррелировать с опытом.
Если говорить про первый ангуляр, то например не понимая того как работает digest-цикл, можно долго искать ответы на SO, почему некоторая последовательность вызовов не приводит к отображению результата на странице. Или не понимания того как происходит поиск изменений в данных для отображения, также долго можно разбираться, почему данные при определенных условиях начинают обрабатываться рекурсивно, блокируя при этом все остальное. Не говоря уже про более тонкие подходы к различным оптимизациям.
А судя по большому количеству статей по первому ангуляру в прошлом, изучение фреймворка предполагало понимание не этих базовых вещей, на которых он построен, а изучение различий между сервисом и фабрикой условно, что по сути различия между инстансом одиночки и классом, в сильном упрощении, но достаточном если знать особенности JS. И к вопросу об изучении фреймворка в принципе, если таким же образом упрощать прочие его особенности и накладывать на эти упрощения свои теоретические знания, можно быстро докопаться до сути вещей происходящих внутри всей этой магии. А понимание внутренних процессов инструмента, ведет к эффективному использованию его, и дает возможность делать очевидные выводы о работе тех или иных частей и предполагать различные следствия, для моментов, про которые в документации даже и сносок никаких может не быть.
Сам кодинг, технические сложности, дедлайны, недостаток знаний и опыта — это всё решаемо. Всегда можно сесть и ещё подумать, ещё получше разобраться. Но потом сдвинуть всю махину в правильную сторону — big deal.
По моему мнению самое сложное в программировании это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.
По моему мнению самое сложное в медицине это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.
ну или так
По моему мнению самое сложное в индустриальном дизайне это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.
Словом вы поняли. Программирование тут отличается только большим количеством хайпа, и скил фильтрации и анализа информации очень хорошо помогает.
Самое сложное лично для меня это:
писать письма;
выяснять почему опять свалился девелоперский энв;
разбираться руководствуясь каким пунктом в спецификации тестировщик завёл тот или иной баг;
мягко объяснять бизнес-аналитику, что эта фича у нас исторически так работает и новую подобную фичу лучше реализовать в том же духе;
заводить дурацкие годовые цели и потом рассказывать менеджеру как я мощно их достиг;
И всё прочее в этом роде.
То есть, деятельность с программированием связанная весьма опосредованно.
А когда есть чё задевелопить, и задача понятна — это просто праздник какой-то. Отдых, можно сказать.
У меня 10 утра. Это относительно рано. Просто я рано лёг. Мне надо вставать и работать. Компьютерное кресло придвинуто к дивану. Самое сложное в программировании — вставать по утрам.
Даже поступил в универ, думал, там дадут понимание, как учиться.
Выучить синтаксис какого-то языка и уметь пользоваться гуглом — ещё не всё, как и какие-то знания об алгоритмах и математике, статистике.
Самого главного, как проектировать приложение, как систематизировать его части, какие части вообще должны быть и как их связать между собой, вообще почти нигде не говорится.
Интуитивно понятно, что писать всё в одном файле, классе, нельзя. Но книги обычно начинают и заканчивают одной простынёй кода, где в начале идёт одно, потом другое, потом главная функция, которая порождает классы, описанные выше, какой-то цикл обработки событий или класс, в котором куча отдельных обработчиков у отдельных объектов, и в каком проценте файла что находится, начинаешь быстро теряться.
Когда проект начинает разрастаться до миллиона строк и сотни файлов, один человек уже с трудом справляется, где что лежит и как за что отвечает.
Я начинал с процедурного кода, в котором всё шло линейно, оказалось, так писать очень сложно. Потом стал фанатом функций, всё оборачивал в функции. После понял, что нужно писать классы и методы. Но сложность возросла многократно. А без понимания, как нужно проектировать, программисту сложно реализоваться.
Возможно, зря я отчислился с третьего курса, но когда преподаватель даёт задание спроектировать какую-то систему под определённый функционал, я ожидаю, что нам хотя бы дадут минимальную теорию. Для этого я в универ и шёл.
Что касается необычайных преимуществ программирования, то вот они:
все перечисленные там преимущества относятся к любой человеческой деятельности — от вязания на спицах до инженерии
В реальной жизни не всё так идеально, как на учёбе
если у вас было все идеально на учебе — то это было просиживание штанов а не учеба.
полусамостоятельное освоение предмета во время учебы не сильно отличается от полусамостоятельного освоения нового языка программирования на работе.
Совершенно несогласен. Сравнение неверное.
Сравнивается какой-то неисправный кусочек кода, который может исправить один программист, видимо в маленьком продукте, где кусок кода принадлежит именно этому проекту, с автомобилем, который является продуктом целого поколения, завода и различных мастеров.
Давайте сравним исправление кусочка кода и починку слегка изогнутого гвоздя, который собственно при небольшом владении руками можно и кривой забить без потери надежности сцепления.
Или сравним замену пробитой покрышки и исправление бага в коде, который связан с багой в проприетарном движке купленном за много денег, и который на самом деле связан с багом в платформе, на которой крутится этот движок. И посмотрим сколько инстанций нужно подключить чтобы устранить баг, или хотя бы найти адекватный воркэраунд.
Статья неплохая, но много сравнений идет в духе “простые проблемы в коде» и «сложные проблемы в реальном мире».
У меня множество примеров, когда проблема интеллектуально легко решается, но требует множества денег на новое оборудование, на новые лицензии, на то, что нужно реорганизовать внутреннюю службу безопасности, то есть упирается в тоже, что и реальная жизнь — деньги и бюрократия.
Мы же обсуждаем не манкикодинг а полный цикл разработки?
Эта причина почему область считается сложной чтобы пройти в ИТ нужно быть очень терпеливым, большинство просто не могут даже начать.
Примите факт, что компьютер всегда прав, а вы — нет
Ой, не факт! Десять минут назад MS Edge отказался выходить в интернет. Единственный браузер, который не смог. Он прав? Нет! А что насчёт third-party решений? Например, поповеры в четвёртом бутсрапе, которые отказываются работать, если им в заголовок передать int, даже если оно преобразовано в строку? Компьютер не всегда прав. Поэтому, мы можем делать форки недоработанных пакетов, либо присоединяться к их разработке и скидывать патчи.
Готовьтесь к худшим сценариям
Для этого есть тестировщики. По опыту могу сказать, что самая лажа начинается тогда, когда ты сидишь и пытаешься предусмотреть все линии поведения. В итоге, пишешь тонну ненужных валидаций и ограничений. Сперва пишем функционал, потом находим того, кто будет тестить, закрываем дыры, которые он обнаружил, и то не факт, что это нас спасёт от нестандартного поведения. В любом случае, есть паттерны, и если заказчик хочет, чтобы в его уникальном проекте была жопа, на которой в рамках капчи надо посчитать прыщи, пусть в неё и идёт.
Контроль за эмоциями
Да, пусть ваш мат в четыре утра слышат соседи! Потому что потом они услышат вашу новую аудиосистему, купленную с очередного транша!
Самостоятельность
Не совсем понимаю, как декомпозиция задач соотносится с самостоятельностью. Самостоятельность в программировании важна, но только в рамках пользования гуглом. На самом-деле, опытные программисты не любят, когда новички пристают к ним с вопросами, и им выгодно говорить о самостоятельности. Нифига это не так. Надо включить дурака и доканывать профи на форумах, выясняя как сделать задачу и как работает та функция, что применил профи.
Невозможно всё знать
И не надо: в голове надо держать только то, что нужно для решения текущих задач. Об этом ещё Конан Дойл писал. Но вот если у вас заказ на допилку JS интерфейса, а вы решили подучить трюки на Nginx'е, то у вас проблемы! Бросайте эту затею и возвращайтесь к JS. И лучше-всего — к поставленной задаче. Аналогично, если вам нужно повесить событие на кнопку, и в своих поисках вы дошли до принципа заполнения памяти JS кодом, вы пошли явно не туда. Если задача не решается простыми средствами, нужно её разбить на подзадачи, либо изменить формулировку.
В реальной жизни не всё так идеально, как на учёбе
Поэтому, бросайте заниматься ерундой и, пока учитесь, берите коммерческий проект в разработку. То, что не приносит никакого дохода, кроме стипендии, в реальных условиях будет забыто за несколько дней.
Балансирование между теорией и практикой
Во-первых, надо начать. А именно, найти самые простые материалы для начала работы. Простейшую статью по тому же WordPress. Сразу поставить LAMPP, сделать Hello World, задуматься над тем, как сохранить это приветствие в базе, перелопатить сотню сайтов, обнаружить, что монга и PostgreSQL не совсем подходят для решения поставленной задачи, вернуться к первому варианту, реализовать на третий день задумку и т.д.
Проблема программирования в том, что здесь нельзя сначала изучать, а потом внезапно сделать. Нужно начать делать, и когда не получится, начать изучать. Теория в начале не даёт понимания этого неповторимого чувства — извлечения кролика из шляпы. Т.е. ощущения создания чего-то из ничего. Сперва нужно осознать ту пустоту, с которой работаешь. Новичок будет думать, что для программирования уже есть своя инфраструктура: достаточно сказать пару слов, и процессор преобразует их в чудесный алгоритм. Либо, достаточно подвигать мышкой, и компьютер научится понимать этот жест и создаст логику. Это не так. Мы работаем всегда с чистым листом. Даже если это — чистый лист внутри фреймворка.
Компьютер не всегда прав.
комьютер делает то что ему сказали разработчики. Да, существуют баги на уровне железа но это можно воспринимать как те же сторонние библиотеки. Ну и подобными ошибками в большинстве своем можно пренебречь. А вот ошибки которые люди совершают — это естественный ход вещей.
Для этого есть тестировщики.
Да, это же так удобно перекладывать ответственность на других. При том что пофиксить то они не смогут. И многие баги даже не смогут найти просто потому что для этого нужно хорошо понимать нюансы технической реализации, а для проявления других нужно немало времени.
У большинства разработчиков очень плохо с анализом и управлением рисками. Кто-то просто забивает, а другие стараются минимизировать риски вместо того что бы минимизировать затраты на устранение последствий (то есть часто дешевле быстрее проблему задетектить и пофиксить нежели пытаться предугадать все )
Нифига это не так. Надо включить дурака и доканывать профи на форумах, выясняя как сделать задачу и как работает та функция, что применил профи.
Подобное стимулирует лень. И в итоге вы получите разработчика который при малейшей сложности не лезет разбираться, а сразу пихает свои вопросы и ожидает решения. Это не добавляет понимания и не даст человеку самостоятельно решить задачу.
берите коммерческий проект в разработку.
Что происходит когда новичек который только-только начинает учиться берет коммерческий проект. Вопервых чаще всего он не в состоянии его сделать и потому будет пытаться "на форумах" добиться от более опытных как же это все сделать. Поскольку обучение и работа будут отнимать у начинающего огромное количество времени, и поскольку проект коммерческий, дедлайны резко выбьют из разработчика всякое желание разбираться и он будет делать "абы работало".
Как итог — скорее всего проект будет зафэйлен, клиент недоволен, а разработчик получит лишь долю опыта которую мог бы получить напиши он некоммерческий проект например.
Что касается тестировщиков, то никогда ни один программист не сможет своим замыленным глазом предусмотреть все варианты использования конечным потребителем. Если только он не работает с одной кнопкой «ОК», и то не факт, что пользователь воспользуется ей правильно. Но, согласитесь, что разработчик не будет сидеть и писать обработчик множественных нажатий на эту кнопку. В большинстве случаев, он не сделает даже disabled статуса на кнопке после первого нажатия. По одной простой причине: сперва надо повешать на неё события, а потом уже применить все знакомые ему методы защиты. Но, опять же, если он будет ещё неделю перехватывать все кейпрессы и нажатие на кнопку из консоли, то он дурак. Сперва делается функционал, потом реализуются стандартные паттерны защиты. Если нужно что-то ещё, пусть заказчик ищет тестировщика или доплачивает разработчику за пользовательское тестирование. Что значит «перекладывать ответственность»? Тестирование интерфейса — это такая же оплачиваемая работа. И, кстати, в ней тоже есть свои методики и средства автоматизации. Если программист с ними не знаком, он не обязан проводить эти действия. Только хуже сделает.
Со стимулированием лени почти согласен. Почти — потому что я указал, что нужно не просто искать готовое решение, но и требовать объяснить принцип его работы. В любом случае, человек без наставлений и без поиска готовых решений повышать уровень не сможет. Я знаю много молодых людей, которые стесняются требовать от наставников информацию. Знаю людей, которым это не интересно. При этом, они прекрасно пользуются гуглом и годами сидят в маркетинговых фирмах. Сайт-визитка за 8 000, магазин — за 20 000, первая цифра — их белая зарплата, вторая — то, что они сверху получают в конверте. Скрипты они писать могут. Не программы.
Стажировка в коммерческих проектах приносит человеку больше пользы, чем разработка собственных CMS и ORM. Почти каждый с этого начинает. Но именно работа над коммерческим проектом, хотя бы стажёром, даёт опыт получения прибыли и развития нужных навыков. Никто не говорит о том, что новичок должен лезть в крутые проекты. Достаточно сделать за пару тысяч знакомой фирме сайт-визитку или прибиться стажёром в какую-нибудь команду.
не сможет своим замыленным глазом предусмотреть все варианты использования конечным потребителем.
Потому есть сказ о "трех амиго", dev + qa + product owner. Из того как вы это подаете создается ощущение что качество это целиком и полностью обязанность QA и разработчику об этом думать не стоит. Вопрос же в командной работе, когда разработчик смотрит с технической стороны вопроса, а QA с позиции пользователя. Да, без QA никуда, но хороший разработчик обязан уметь придумывать тест кейсы. Что до замыленнсти — если генерить тест кейсы на чужую часть работы — то выходит лучше. Что до автоматизации, то тут еще больше стирается грань между чисто dev и чисто qa.
Ну и еще ремарка про пограничные/негативные кейсы. Не стоит еще забывать про приоритизацию багов. На многие баги можно просто закрыть глаза в силу того, какой эффект они вызывают. Фиксить все не эффективно с экономической точки зрения.
чем разработка собственных CMS и ORM
я где-то что-то говорил про свои CMS/ORM?
Но именно работа над коммерческим проектом, хотя бы стажёром
тогда уточняйте что речь идет о работе в команде.
В области автоматизации пользовательского тестирования, действительно, QA выходит на уровень скриптов. Но разработчик — хороший разработчик — никогда даже додуматься не сможет о некоторых вариантах использования. А вообще, нужно чётко разделять разработку на готовых шаблонах и командную разработку. Допустим, мы говорим о Web. Есть CMS, которые уже имеют в реализации часть защиты, как и расширения для них. Этого достаточно для того, чтобы один специалист смог написать и продать проект на этой CMS. Он не будет заморачиваться дополнительной защитой до момента возникновения бага. Есть разработка в команде, когда наличие пользовательского тестирования — обязательно. Это не означает, что в команде есть QA, но тестирование может проводить менеджер. Это обязательное условие, поскольку программист почти никогда не производит таких тестов. Как-правило, в командах без QA есть список известных багов, которые проверяются вручную перед релизом.
А теперь, внимание, всё выше изложенное — о коммерческой разработке. Отсюда следует простой вывод, что новичок не получит этого опыта вне коммерческой разработки. И отсюда же следует вывод, что он не обязан работать в команде. Он может делать проекты на CMS. Но, допустим, человек не делает ничего на CMS. Он пишет свои велосипеды. И смысла проверять качество этих велосипедов у него нет. Они не поедут, и денег за них он не получит. Одно вытекает из другого: нужно изучать готовые паттерны защиты от непредсказуемых действий. Не обязательно знать как поведёт себя пользователь. Достаточно знать, что надо вот тут сделать кнопку disabled после первого нажатия, а там применить ORM с экранированием спецсимволов, вместо прямого обращения к базе. Либо работать в команде, но там точно так же наставник скажет: «после нажатия замьють кнопку» или «нафиг ты делаешь коннект к мускулу? Мы используем эту ORM. Зачем? Чтобы не писать лишний код и не заботиться об эскейпе символов при защите от инъекций».
И я же видел молодых людей, которые приходили стажироваться и всё время кидали понты в духе: «да я написал плеер на дельфях». Или «У меня свой сайт — крутой». В итоге, когда они косячат, проверяются предметы их гордости, и оказывается, что плеер не работает, а сайт сделан на юкозе без изменения в коде и шаблонах — слишком сложно было залезть в код. А особый смак — когда оказывается, что поделка была курсовой работой, и человек за нерабочий продукт получил отличную оценку.
Разумеется, я выступаю за стажировку, за создание собственных коммерческих проектов и за активное участие молодых программистов в профессиональной разработке. Разумеется, последнее должно быть только в формате простой работы, рутины и т.д. В любом случае, это колоссальный опыт командной работы, опыт работы в различных методологиях организации процесса, опыт работы с контролем версий, опыт тестирования, опыт отчётности и первичные знания маркетинга в IT сфере.
а разработчик получит лишь долю опыта которую мог бы получить напиши он некоммерческий проект например.
Некоммерммерческий проект, в первую очередь — это отсутствие лица, заинтересованного в результате. Т.е. это возможность девелоперу с заумным видом ковырять в носу и пытаться разродиться никому на. не нужными фантазиями и идеями в стиле «что бы такое еще залепить чтобы круто было». Вы действительно считаете, что такая графомания может дать что-то более позитивное к продаваемому опыту чем умение выполнять в срок реальные поставленные задачи?
Про юмор могу сказать, что в каждой шутке есть доля правды. Автор статьи оассматривал программирование с точки зрения идеализма: искать наставника (куратора), самостоятельно искать ответы на вопросы, и т.д. ерунда это всё! Если поиск ответа в гугле занимает сутки, а профи знает решение, которое реплизуется за час, почему бы не подаставать профи с час, чтобы он всё рассказал? Кураторов у новичков нет. Иметь куратора — вредно. Нужно, чтобы код читало несколько разных человек. Если ни один из них не плюётся, код может быть неплохим. Ну и, разумеется, без реальной разработки программист учится не тому. Он может работать в каком угодно коллективе, изучать любые методологии. Пол дня заигрывать с девчонками-менеджерами, жрать шоколодки и пить чай, потом писать несколько строчек на HTML и идти домой. Или может изучать теории разработки, непрерывные и водопадные схемы интеграции. Может постоянно разбивать задачи на подзадачи и обнаружить в итоге целую гору незакрытых вопросов. Может, пока не перестанет заниматься ерундой и не пойдёт в крупный проект. Там его научат, что тестировать продукт он не может (поскольку не умеет и находится внутри процесса разработки, а QA — снаружи), задачи будет ставить менеджер, а по вопросам можно дёргать основного инженера.
Самое сложное в программировании это… программирование
Починить неисправный код можно одной лишь силой ума, в отличии от, например, сломанной машины, которая требует покупки дорогих запчастей.
Едва ли это применимо к крупным проектам, где ошибка может потребовать оплаты дорогих человеко-часов
Самое сложное в программировании — нейминг
Самое сложное в программировании это…
придумывать имена переменных же
Самое сложное в программировании — это
- надо думать. много. не все это любят.
- надо иметь развитое абстрактное мышление. чтобы мыслить на уровне модулей и потоков данных. не всем это дано.
- надо учиться. всю жизнь, 5 лет в IT — это вечность. зачем, если вокруг столько куда менее напряжных профессий?
Хорошая статья!
У меня на собеседовании по java как то спросили теорему Чёрча-Росса в трех видах.
До сих пор чешу репу, — действительно ли я чего-то не знаю? :)
Невозможно все знать!
И возникает парадокс Сократа: “я знаю, что ничего не знаю”.
Но я же знаю, как говорил Сократ. А раз знаю что надо знать, значит буду знать!!
Был на втором курсе предмет по основам программирования на Delphi, а я уже заблаговременно имел за спиной большой опыт в программировании. Так вот, одногруппники все время ныли «Почему он не запускается от того я не поставил один раз точку с запятой?», ну а я вот фразу нужную подобрать не мог:)
Самое сложное в программировании это…