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