Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
… я не умный, я просто перечитал 2 раза этот пост и не понял зачем это здесь…
Есть такая поговорка — «если долго мучиться, что-нибудь получится». Если долго кодить, неизбежно будешь кодить удовлетворительно, на своём опыте наделав все возможные ошибки в архитектуре, паттернах и т.д.
Вот об этом пост
Вот об этом пост
Судя по всему, по такому же правилу нужно читать статью.
в том-то и дело, что весь смысл данного поста умещается в вашем комментарии )
автор, без обид ;)
автор, без обид ;)
Комментарий не будет висеть на странице. Теперь если кто-то вдруг открыл гениальную вещь в трех строчках текста на японском языке — тоже пихать в комментарий в силу краткости или переводить в статью? Бред!
Наконец чувак работает в IBM и окончил ливерпульский университет. Вполне достойно быть опубликованным, при грамотном исходном тексте, а текст хорош.
Тем более перевод (что там написано) — отличный стимул подстегнуть новичков.
Да и чего далеко ходить, новостные посты Ализара с картинками порой меньшего объема, хотя ему вполне хватило одной статьи и комментариев.
Наконец чувак работает в IBM и окончил ливерпульский университет. Вполне достойно быть опубликованным, при грамотном исходном тексте, а текст хорош.
Тем более перевод (что там написано) — отличный стимул подстегнуть новичков.
Да и чего далеко ходить, новостные посты Ализара с картинками порой меньшего объема, хотя ему вполне хватило одной статьи и комментариев.
Если долго-долго-долго кодить что-нибудь до позднего-позднего-позднего вечера/утра, то в итоге на следующий день придется долго-долго-долго разбираться «зачем и пму?!».
Ежели в смысле времени и практики, то проще и эффективнее подсмотреть чье-то решение и вдуплить отчего и почему они так сдедали.
Это экономит время, повышает скилл анализа чужого кода и сразу направляет на верный путь + учит пользоваться поисковиком.
Ежели в смысле времени и практики, то проще и эффективнее подсмотреть чье-то решение и вдуплить отчего и почему они так сдедали.
Это экономит время, повышает скилл анализа чужого кода и сразу направляет на верный путь + учит пользоваться поисковиком.
С одной стороны, если долго мучиться, что-нибудь получится — это факт. Причем что-нибудь однозначно будет при этом «как-нибудь». Но во-всяком случае получение усталости гарантировано, что всяко может быть истолковано, как вариант подмножества «что-нибудь».
С другой стороны, лично мой опыт, пока еще крайне малый, программирования под андроид, говорит, что мой опыт программирования (на любительском уровне — больше 20 лет) не дает мне никакого преимущества, и даже вредит! Принципиально иная идеология, победить которую на основе новой интерпретации старых знаний просто невозможно. Поэтому над каждой строчкой кода приходится сидеть по 10 часов — это тоже факт из личного опыта.
Что неимоверно удручает, это темпы изменения технологий программирования. Если освоив (сами понимаете, как) в институте паскаль я методом научного тыка за неделю освоил Borland Pascal for Windows, причем до уровня полезных приложений, а не хелловордов; если после этого за 2 недели я освоил так же без чтения книжек Delphi исключительно чтением хелпа к ней; если «с лету» у меня получалось править скрипты CMS Joomla под собственные нужды (до этого php в глаза не видел) — то все это давало мне право надеяться, что я умный на самом деле. И вот теперь я понимаю, что с андроидом я не просто тупой — я безмозглый даун! И пока я смогу отречься от всего, что накопилось в моей голове и разберусь с ныне существующим API 23 (или уже 24?!), окажется, что все это уже никому не надо — уже и андроид будет 125-й версии, и API изменится до неузнаваемости, а может и Java умрет… Причем будет это через год, а не через 20…
Поэтому я бы резюмировал статью так: вы умны, пока не знаете, что и как делают другие. Я сидел над этим больше вас, но я гораздо «тупее» любого, кто занялся этим только-что…
С другой стороны, лично мой опыт, пока еще крайне малый, программирования под андроид, говорит, что мой опыт программирования (на любительском уровне — больше 20 лет) не дает мне никакого преимущества, и даже вредит! Принципиально иная идеология, победить которую на основе новой интерпретации старых знаний просто невозможно. Поэтому над каждой строчкой кода приходится сидеть по 10 часов — это тоже факт из личного опыта.
Что неимоверно удручает, это темпы изменения технологий программирования. Если освоив (сами понимаете, как) в институте паскаль я методом научного тыка за неделю освоил Borland Pascal for Windows, причем до уровня полезных приложений, а не хелловордов; если после этого за 2 недели я освоил так же без чтения книжек Delphi исключительно чтением хелпа к ней; если «с лету» у меня получалось править скрипты CMS Joomla под собственные нужды (до этого php в глаза не видел) — то все это давало мне право надеяться, что я умный на самом деле. И вот теперь я понимаю, что с андроидом я не просто тупой — я безмозглый даун! И пока я смогу отречься от всего, что накопилось в моей голове и разберусь с ныне существующим API 23 (или уже 24?!), окажется, что все это уже никому не надо — уже и андроид будет 125-й версии, и API изменится до неузнаваемости, а может и Java умрет… Причем будет это через год, а не через 20…
Поэтому я бы резюмировал статью так: вы умны, пока не знаете, что и как делают другие. Я сидел над этим больше вас, но я гораздо «тупее» любого, кто занялся этим только-что…
Если долго кодить, неизбежно будешь кодить удовлетворительно, на своём опыте наделав все возможные ошибки в архитектуре, паттернах и т.д.
Вот об этом пост
Нет, это название об этом. А сам пост не об этом.
Пост о том, что нужно делать продукт, а не писать код. О том, что код это средство для создания продукта, а не самоцель. поэтому не надо слишком сильно переживать о коде — всё это придёт само. Надо делать продукты, вот что важно.
И даже не об этом, а о том, что одним доставляет удовольствие написание кода, другим — создание продукта.
На вкус и цвет друга нет.
На вкус и цвет друга нет.
Если подходить к пониманию статьи таким образом, то можно заметить данное в явном виде высказывание, что может быть человек и не очень умный, но хорошие продукты это создавать не помешает. А про то, что одним доставляет удовольствие написание кода, а другим создание продукта в статье вооще нет. То есть вообще нет слова удовольствие :)
Мне эта статья напомнила эффект Даннига-Крюгера.
Чтобы стать по настоящему хорошим программистом мало «бороться» с программированием. Нужно уметь абстрагироваться, толку постоянно долбится в новую технологию, тратя по 20 часов в сутки на это, если это не приводит к появлению в мозгу новых абстракций, понимания того общего, что есть во всем программировании.
Лучше уж тогда потратить эти 20 часов на изучение и понимание computer science, хотя бы его основ. Если охота заниматься графикой и анимацией, то явно не лишним было бы знать аналитическую геометрию. А уж вычислительная сложность это вообще must have.
Если же даже это всё не заставляет мозг видеть за всеми этими фреймворками, языками, парадигмами какой-то сути, то надежды нет.
Лучше уж тогда потратить эти 20 часов на изучение и понимание computer science, хотя бы его основ. Если охота заниматься графикой и анимацией, то явно не лишним было бы знать аналитическую геометрию. А уж вычислительная сложность это вообще must have.
Если же даже это всё не заставляет мозг видеть за всеми этими фреймворками, языками, парадигмами какой-то сути, то надежды нет.
То же самое касается и фреймворков, не важно что это react, angular, backbone, polymer или что-то еще. Вам не нужно учить их все, просто знайте о них, и выбирайте тот, который подходит для ваших нужд.
WAT??
Простите, написано что-то весьма непонятное.
Как можно выбирать инструмент не зная его?
Есть такая штука, ударная дрель. И это не тоже самое что перфоратор. Вот я как не профессиональный строитель знаю, что оба эти инстрменты сверлят и долбят. Но как мне понять, какой из них мне нужен для конкретной задачи?
Тоже самое с фреймворками. Чтобы правильно выбрать фреймворк — нужно знать его слабые и сильные стороны, его особенности.
В противном случае можно брать любой — они все позволяют решать широкий спектр задач.
Ну, тут мне кажется в крайности главное не впадать. Всё же иметь по году опыта работы с каждым из них и наизусть знать документацию — перебор. Знание подводных камней конкретного фреймворка сильно помогает, кто бы спорил, но для многих проектов хватит знания основ и принципов каждого из них. Если проводить сравнения, то речь идёт о выборе сверла нужного типа и диаметра, поведение которых можно грубо предсказать, зная как работает дрель, и что за стену надо сверлить.
Программирование — это искусство.
Нет, ремесло.
Проектирование — это тоже ремесло.
Дайте определение слов «искусство» и «ремесло», а то обычно такие споры из-за недопонимания того, что люди понимают под данными терминами.
По мне так «ремесло» — это и искусство, которым зарабатывают на жизнь. Художник, рисующий картины за деньги, тоже ремесленник. А значит одно другому не противоречит.
По мне так «ремесло» — это и искусство, которым зарабатывают на жизнь. Художник, рисующий картины за деньги, тоже ремесленник. А значит одно другому не противоречит.
Лучше исходить из принципа:
Я классный! именно потому, что сижу за этим занятием чуть дольше… а вы лентяи не смогли сделать так же
Знайте себе цену.
Я классный! именно потому, что сижу за этим занятием чуть дольше… а вы лентяи не смогли сделать так же
Знайте себе цену.
"… я не умный, просто мои мозги работают немного лучше ваших": )
У перевода сильно страдает литературный стиль — не говорят так по-русски. В дальнейшем имеет смысл после такого перевода «начерно» бить его на абзацы и излагать своими словами, сохраняя смысл. Почему в школе никогда не рассказывают о том, как важно уметь писать сочинения?
По теме — в тексте есть одна умная мысль — с точки зрения бизнеса функционал и время, потраченное непосредственно на кодинг функционала важнее, чем архитектура, красота и повторное использование.
Перфекционизм хорош в больших командах, когда твой код видит много людей и знания о проекте передаются по наследству. В бизнесе прежде всего — время. Раньше покажешь людям, раньше соберешь отзывы, раньше получишь клиентскую базу, раньше пойдут первые деньги.
Моё мнение — что для своего кода главное, чтобы ты смог через полгода вспомнить, что это вообще такое и как его запускать. Поэтому — модульность, документирование модулей, автоматизация сборки и деплоймента, самодокументируемость (все запускаемые приложения при старте должны выдавать вменяемый хелп о назначении и возможных параметрах конфигурации). А внутри может быть что угодно, лишь бы работало хорошо.
Но все равно мешает проклятый перфекционизм :-)
По теме — в тексте есть одна умная мысль — с точки зрения бизнеса функционал и время, потраченное непосредственно на кодинг функционала важнее, чем архитектура, красота и повторное использование.
Перфекционизм хорош в больших командах, когда твой код видит много людей и знания о проекте передаются по наследству. В бизнесе прежде всего — время. Раньше покажешь людям, раньше соберешь отзывы, раньше получишь клиентскую базу, раньше пойдут первые деньги.
Моё мнение — что для своего кода главное, чтобы ты смог через полгода вспомнить, что это вообще такое и как его запускать. Поэтому — модульность, документирование модулей, автоматизация сборки и деплоймента, самодокументируемость (все запускаемые приложения при старте должны выдавать вменяемый хелп о назначении и возможных параметрах конфигурации). А внутри может быть что угодно, лишь бы работало хорошо.
Но все равно мешает проклятый перфекционизм :-)
У перевода сильно страдает литературный стиль — не говорят так по-русски. В дальнейшем имеет смысл после такого перевода «начерно» бить его на абзацы и излагать своими словами, сохраняя смысл.
Согласен с вами,- перевел сходу. Нужно было отложить на время, затем перечитать, сформулировать своими словами и опубликовать. За это прошу прощения у читателей, т.к. перевожу на хабре в первый раз. И, судя по реакции большинства, в следующий раз 10 раз подумаю, что и где переводить.
Как будто этот текст написал я! Я именно также отношусь к проектам, мне не важно качество кода, а важно как проект будет выглядеть в конце разработки для посетителя. И всегда меня удивляет, когда люди по сотни часов сидят над рефакторингом кода, при этом продукт выглядит посредственно.
Спасибо за пост! Плюсанул и сам пост и вашу карму. А на минусы не обращайте внимание, здесь всем почему-то важнее сама технология, а не конечный результат.
Спасибо за пост! Плюсанул и сам пост и вашу карму. А на минусы не обращайте внимание, здесь всем почему-то важнее сама технология, а не конечный результат.
Спасибо, я просто перевел)
И то и другое — крайность. Рефакторингом занимаются, когда планируют развивать проект. Это вы просто не участвовали в разработке действительно больших систем. Там без рефакторинга в какой-то момент вообще невозможно вносить изменения, если изначально код был так себе. Да даже если вы все писали «правильно», то через время код обрастает деталями и фиксами, которые все равно придется рефакторить. Это лишь надо делать разумно, без фанатизма.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я не умный, я просто сидел над этим дольше вас