Комментарии 47
НЛО прилетело и опубликовало эту надпись здесь
Согласен. Когда поем, то в сон сразу клонит. Поэтому обхожусь промежуточными перекуса.
Ем 4-5 раз в день, на работе —
И 2-2,5 л воды в день. Удобно вести отчет времени по Помидорро — большой перерыв — обед. Всегда легко сыт и голова не забита перевариванием большого кол-ва еды
- второй завтрак — мюсли с молоком, углеводы — топливо для мозга
- обед через 1,5-2 часа — делю свой большой обед из дома на 2 части, углеводы и белки, например, рис и курица, гречка и мясо
- полдник — фрукты, 2 яблока и 2 банана, можно разделить на 2 части
- за час до конца раб. дня — 2 часть обеда
И 2-2,5 л воды в день. Удобно вести отчет времени по Помидорро — большой перерыв — обед. Всегда легко сыт и голова не забита перевариванием большого кол-ва еды
Точно, я если хочу есть, то кодить вообще не могу.
Как насчет писать код в программе, которую вообще мало понимаешь?
Если смотришь на программу и она кажется абсурдом, нагромождением хаоса, спагетти?
А нужно развить или дополнить ее функционал.
Если смотришь на программу и она кажется абсурдом, нагромождением хаоса, спагетти?
А нужно развить или дополнить ее функционал.
вставьте в любое место `println` или брекпоинт и посмотрите в какой момент туда попадет код. Посмотрите, что происходит в этом месте. Делайте так до тех пока не станет понятно хоть что-то.
Так и делаю. Но есть большая разница между понятно «хоть что-то» и «все понятно».
Когда понятно все, то можно сделать красивое решение. Когда понятно что-то, то можно сделать решение, но скорее всего будет костыль.
Когда понятно все, то можно сделать красивое решение. Когда понятно что-то, то можно сделать решение, но скорее всего будет костыль.
если для проекта в котором ничего не понятно вы делаете костыль, то вероятно вы используете бестпрактис этого проекта, а как результат не будете выделяться на общем фоне и нарушать хрупкий баланс и эстетику остального кода
Пожалуй это надо заскринить, распечатать и повесить на стену…
к сожалению бывает, когда разработчики меняются, то в хорошо написанном проекте с тестами и прочим, новые люди даже не пытаются разобраться и сразу начинают пихать костыли везде.
кажется, после вашего комментария, мне перестанут сниться кошмары по ночам
Я как-то допиливал pandoc, чтобы он генерировал хабра-разметку. Это при том, что Haskell я как не знал, так и не знаю. Тут главное научиться собирать и запускать код. Если это умеешь, то дальше проще.
Ищешь по ключевым словам, если код более менее, то дальше будет понятно, как сделать какое-то мелкое изменение. Дальше делаешь его, запускаешь код и смотришь — оправдывает он твои ожидания, или нет. И так повторять до полной победы.
Не удалось найти в репе ничего по слову habr :) Можете кинуть PR или issue — тоже надо бы допилить pandoc для лучшей поддержки codeproject разметки.
Это было достаточно давно, с тех пор в pandoc накомитили более 1000 коммитов. Под хабра разметкой имеется в виду хабровский html — он немного особенный. pr я не делал и issue не создавал. Просто поправил и использовал для своих нужд. Код можно найти в в моём маленькм форке. Там взят стандартный html, в который внесены модификации. Они там в четырёх коммитах. Название нового формата — habr. Если это вам чем-то поможет — буду рад.
Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто».
Диалектичненько.
То есть чем быстрее вы как программист — тем меньше влияния на качество вашего кода имеют дедлайны.
Или можно произнести равноценную: «Чем
Короче, как в известном анекдоте: Что тут думать — трясти надо
Полную версию бы того самого анекдота, который все знают
Привожу.
Идет физик-теоретик по пустыне. Жарко. Пить хочется. Видит кокосовая пальма. Подбежал, стал трясти. Не стрясается. Так, надо подумать. Огляделся, увидел палку. Кинул, сбил орех. Напился и пошел дальше.
Идет физик-экспериментатор по пустыне. Жарко. Пить хочется. Видит кокосовая пальма. Подбежал, стал трясти. Не стрясается. Так, надо подумать. А что тут думать — трясти надо.
Идет физик-теоретик по пустыне. Жарко. Пить хочется. Видит кокосовая пальма. Подбежал, стал трясти. Не стрясается. Так, надо подумать. Огляделся, увидел палку. Кинул, сбил орех. Напился и пошел дальше.
Идет физик-экспериментатор по пустыне. Жарко. Пить хочется. Видит кокосовая пальма. Подбежал, стал трясти. Не стрясается. Так, надо подумать. А что тут думать — трясти надо.
Программировать — это не всегда кодить, на самом деле.
Мне иногда приходится неделями обдумывать, как подступиться к какой-то проблеме, но этим я уберегаю себя от зря потраченного времени на написание кода, который тупо пойдет в топку.
Мне иногда приходится неделями обдумывать, как подступиться к какой-то проблеме, но этим я уберегаю себя от зря потраченного времени на написание кода, который тупо пойдет в топку.
С другой стороны, за эти недели можно было написать несколько прототипов и посмотреть на проблему с разных сторон. Попутно, прокачивается куча разных навыков, начиная со скорости набора кода до более высокоуровневых.
Для того, чтобы написать несколько эффективных прототипов, надо определить, как эти протитипы оценивать. А то знаю я таких горе-разработчиков, которые напишут что-нибудь на коленках, а потом туча времени уходит на поддержку этого «прототипа».
Прежде всего, нужно осознавать соблазн признать прототип итоговым продуктом. Причем соблазн и со стороны разработчика и со стороны заказчика. Первому хочется быстрее получить деньги, второму готовый продукт. Заказчик может убедить разработчика, что и так всё уже хорошо работает. При этом разработчик может смириться с набором костылей в реализации с сдать продукту в продакшен. Ведь можно перейти к разработке другого продукта и получить дополнительный доход.
А вопрос соотношения доли костылей в архитектуре приложения остается открытым. Это вопрос финансовой оптимизации. Если работает, и не требуется сопровождение, и проще его переписать чем вносить правки, так зачем вкладываться в правильную архитектуру? А если есть потребность сопровождать и получать за это доход, тогда нужно оптимизировать архитектуру для снижения себестоимости сопровождения.
Прототип всегда пишут «на коленке». Он для того и нужен, чтобы понять, что еще за функционал потребуется прикрутить. После осмысления ТЗ (внешнего описания по Жоголеву), можно полностью с нуля спроектировать правильное приложение. А можно и докрутить прототип за несколько циклов спирали.
А вопрос соотношения доли костылей в архитектуре приложения остается открытым. Это вопрос финансовой оптимизации. Если работает, и не требуется сопровождение, и проще его переписать чем вносить правки, так зачем вкладываться в правильную архитектуру? А если есть потребность сопровождать и получать за это доход, тогда нужно оптимизировать архитектуру для снижения себестоимости сопровождения.
Прототип всегда пишут «на коленке». Он для того и нужен, чтобы понять, что еще за функционал потребуется прикрутить. После осмысления ТЗ (внешнего описания по Жоголеву), можно полностью с нуля спроектировать правильное приложение. А можно и докрутить прототип за несколько циклов спирали.
Они, конечно, правы в том, что в условиях сжатых сроков разработчики, как правило, будут писать сложный код
Причем сложный код, не значит сложная архитектура, а код без какой либо структурированности, накиданный наспех.
Вообще, как говорил один из моих наставников, когда видишь код и не понимаешь что тут происходит, начни с рефакторинга. Особенно когда код в этом очень нуждается.
В любой неопнятной ситуации гугли или читай доки. Вроде очевидная вещь, но часто сидишь и тупишь от недопонимания.
Если тебе спускают подробное ТЗ на каждую задачу, где всё описано от и до — то да, ты кодер, и можешь строчить абы что и абы как, лишь бы побыстрее и в спецификацию уложиться. А если тебе нужно сначала принять решение «как это сделать», чтобы вписать в архитектуру и не нагородить костылей, и лишь потом фигачить код, то тут уже спешка и попытки «не думать» могут привести к плачевным результатам в виде будущих факапов и необходимости рефакторинга.
Поэтому, было бы интересно сначала узнать о типе решаемых автором статьи задач и об организации рабочего процесса и постановки этих задач. От этого очень много зависит в режиме работы программиста. Я бы даже сказал — всё.
Поэтому, было бы интересно сначала узнать о типе решаемых автором статьи задач и об организации рабочего процесса и постановки этих задач. От этого очень много зависит в режиме работы программиста. Я бы даже сказал — всё.
На самом деле в процессе разработки архитектуры похожие техники тоже применимы — просто либо ты пытаешься всю архитектуру (или требуемое её изменение) удержать в голове и продумать целиком, либо начинаешь выносить отдельные части наружу (что-то нарисовать, для какого-го мелкого и понятного элемента написать спеку, изменить схему БД в более-менее нужном направлении, провести мелкие нагрузочные тесты каких-то подсистем, почитать более детально доку по малоизвестным фичам ЯП или БД, etc.) и в процессе много проясняется быстрее, чем если делать всё это в голове.
Не совсем понятно, на какой вывод наталкивает автор. "Меньше думай — пиши больше (говно) кода и делай это быстрее?"
Скорее так — «не думай Лети» — в контексте — «пиши Не думая СЛИШКОМ много, позволяя коду появлятся без затруднений» — сложная на самом деле методика когда что то пишешь или кодишь, но когда умеешь «ловить» такие трансовые состояния процесс идет очень быстро — правда иногда проблема с последующим пониманием принципов работы…
Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто».
Проблема в данном подходе — это то, что на следующий task/story/feature/project ты получишь еще меньший дэдлайн и это станет нормальной практикой. Проблема в том, что поставить дедлайн меньше и научиться быстрее кодить, вещи по сложности не сопоставимые.
В целом согласен с утверждениями автора, но он не уточняет один вопрос очень важный для программиста — качество сформулированной задачи. Если взять за аксиому что задача описана детально то да, статья описывает, на мой взгляд, все важные аспекты быстрого написания программ и соблюдения дедлайнов в конечном итоге.
Я очень много раз был свидетелем того что программисту давали задачу которая формулировалась двумя-тремя предложениями и подразумевала создание достаточно сложного продукта, без конкретных требований к составляющим. Ну и разумеется дедлайн из разряда: «Да че там писать, за неделю управишься!».
Поэтому я бы добавил еще один пункт к статье — Требуйте детального технического задания, и расписал бы соответственно плюсы и минусы наличия такового, а то начинающие программисты могут подумать что только на них лежит отвественность за срыв сроков выполнения проекта из-за того что они пишут код медленнее по причинам зависящим только от них.
Я очень много раз был свидетелем того что программисту давали задачу которая формулировалась двумя-тремя предложениями и подразумевала создание достаточно сложного продукта, без конкретных требований к составляющим. Ну и разумеется дедлайн из разряда: «Да че там писать, за неделю управишься!».
Поэтому я бы добавил еще один пункт к статье — Требуйте детального технического задания, и расписал бы соответственно плюсы и минусы наличия такового, а то начинающие программисты могут подумать что только на них лежит отвественность за срыв сроков выполнения проекта из-за того что они пишут код медленнее по причинам зависящим только от них.
НЛО прилетело и опубликовало эту надпись здесь
Всё сказанное в посте верно в большинстве случаях, Но не каждому человеку подойдёт, у некоторых всё же другой подход(я замечал).
Название статьи вводит в заблуждение. Она должна называться «10 очевидных вещей, ни одна из которых не является особенно важной». Я заходя думал, что тут будет какая-то методика — как любую сложную задачу превратить в мгновенный код. А тут банальная и очевидная бытовая туфта. Похоже даже мои джуниоры больше знают о том как кодить быстро, чем это ваш Макс из Гугла.
Этот совет годится для программистов, у которых уже есть какой-то бессознательный набор знаний, которые они могут применять. Для тех, кто программирует регулярно меньше года (или нерегулярно всю жизнь) — большая часть знаний находится пока в сознательной области, и «не думать» не получится
Думаю, что, имея представление о функционировании велосипеда в реальном мире, полученное из анализа предметной области, написать класс Колесо можно без всякого представления о классе Велосипед. Это называется программированием снизу-вверх и ещё принципом инкапсуляции. А умельцы в цирке могут даже ездить на колесе без велосипеда (это низкоуровневый внешний интерфейс).
Согласен с автором текста. У меня все эти факторы присутствуют)
Мне кажется, что не был упомянут достаточно значительный факт, как производительность инструментов разработки: программные и аппаратные. Недостаточная производительность которых может привести к значительным паузам. И чем больше эти паузы, тем опаснее, так как могут вывести разработчика из состояния потока.
Все так!
Не хочу никого обидеть, но выглядит как пособие для индусов code monkey. Все сводится к тезисам вида «быстро писать код = быстро разрабатывать продукт».
Для сайта-визитки это, может и актуально, но разве этот подход будет работать для более серьезного функционала?
На протяжении всей статьи автор постулирует, что работа программиста = написание кода. Ни больше ни меньше. И когда ты не стучишь по клаве, значит случилось что-то плохое и мешает тебе «работать».
Да, такое мнение было (и есть?) распространено среди руководителей, не знакомых со спецификой работы программиста (и R&D в целом), умеющих оценивать только количество. Также это актуально и для задач, не требующих высокой квалификации, например, когда вся архитектура уже написана (или ее нет, как таковой), и нужно только перенести эту идею в код, не добавляя ничего от себя. Ну к фрилансерам с почасовой оплатой тоже можно притянуть, хотя я сомневаюсь, что люди уровня выше code monkey на фрилансе большинство времени тратят на набор текста. Это только в фильмах про хакеров так. В остальных же случаях процесс написания кода — это лишь следствие процесса работы программиста, без которого не обойтись, но который не является сутью работы сам по себе. Этакий boilerplate-процесс, если можно так выразиться.
Нет, я очень хорошо понимаю посыл автора. Иногда действительно застрянешь в какой-то умозрительной проблеме, когда можно было бы написать проще ии так сгодится ни к чему усложнять на ровном месте. Да и с отдельными пунктами я согласен. Но с общей идеей — абсолютно нет. И странно слышать от разработчика такие вещи
Для сайта-визитки это, может и актуально, но разве этот подход будет работать для более серьезного функционала?
На протяжении всей статьи автор постулирует, что работа программиста = написание кода. Ни больше ни меньше. И когда ты не стучишь по клаве, значит случилось что-то плохое и мешает тебе «работать».
Да, такое мнение было (и есть?) распространено среди руководителей, не знакомых со спецификой работы программиста (и R&D в целом), умеющих оценивать только количество. Также это актуально и для задач, не требующих высокой квалификации, например, когда вся архитектура уже написана (или ее нет, как таковой), и нужно только перенести эту идею в код, не добавляя ничего от себя. Ну к фрилансерам с почасовой оплатой тоже можно притянуть, хотя я сомневаюсь, что люди уровня выше code monkey на фрилансе большинство времени тратят на набор текста. Это только в фильмах про хакеров так. В остальных же случаях процесс написания кода — это лишь следствие процесса работы программиста, без которого не обойтись, но который не является сутью работы сам по себе. Этакий boilerplate-процесс, если можно так выразиться.
Нет, я очень хорошо понимаю посыл автора. Иногда действительно застрянешь в какой-то умозрительной проблеме, когда можно было бы написать проще и
Есть ещё один способ быстрого программирования — это использование готового кода (повторное использование). Можно использовать как программные библиотеки так и шаблоны алгоритмов, изменяя их или комбинируя.
А иногда всё-таки можно задуматься и часть кода вообще не писать, за не надобностью. Например иногда можно решить проблему другим способом (не программным) или окажется что надо решать совсем другую проблему (и соответственно писать другую программу).
А иногда всё-таки можно задуматься и часть кода вообще не писать, за не надобностью. Например иногда можно решить проблему другим способом (не программным) или окажется что надо решать совсем другую проблему (и соответственно писать другую программу).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Секрет быстрого программирования: не задумывайтесь