Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 116
за это я и люблю программирование — иногда чувствуешь себя богом.
Вот богом я перестал себя чувствовать еще в детсве. Сейчас остался просто ценный духовный опыт. К которому привык :(
Как будто сейчас нельзя создавать ничего нового…
создавать новое конечно можно, вот только это получается как то гораздо быстрее. я, вот, уже в голове вырисовываю алгоритм решения той или иной программы еще даже не сев за компьютер, а когда уже сел, то просто код льется рекой и максимум что из ошибок тут допускается, как верно подметил автор, просто кто то отвлек или хочется спать, в общем по большей часи это синтаксические ошибки. В следствии всего этого потерялся тот детский интерес (
Ты понимаешь меня ;)
А я сейчас уже перешел грань, когда ты стараешься объяснить себе, что это не баг, и не ошибка, это космические лучи делают биты ломают… Старость?
А я сейчас уже перешел грань, когда ты стараешься объяснить себе, что это не баг, и не ошибка, это космические лучи делают биты ломают… Старость?
Вы, наверное, не видите никакой идеи… Вам вдохновление надо… Найдите свою тему нишу, заболейте нею… И тогда Вас раздражать будет только то что почему же я не умею писать в 10 раз быстрее… :)
Хм. А я считаю что лучшая программа, это та, которая не написана. И если можно сделать что-то не программируя, то стоит сделать это не программируя.
Вручную? ;)
Слишком общими фразами бросаетесь, а без уточнений они ложны.
Слишком общими фразами бросаетесь, а без уточнений они ложны.
Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C”.
The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”
Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C”.
The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”
Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C”.
The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”
The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.
“And how many hours would you require to implement and debug that C program?” asked Nubi.
“Many”, admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him”.
“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Upon hearing this, the programmer was enlightened.
The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”
Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C”.
The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”
Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C”.
The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”
The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.
“And how many hours would you require to implement and debug that C program?” asked Nubi.
“Many”, admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him”.
“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Upon hearing this, the programmer was enlightened.
А здесь кто-то говорил о С? о_О
Чем написание скриптов не программирование? Или, по-вашему, скрипт — это не программа, написанная на языке, доступном её интерпретатору?
Мало того, практически все скриптовые языки — полные по Тьюрингу.
Мне тут мерещатся следы какого-то глупого холивара на тему искусственного разделения «админов» и «программеров» с отдачей в ведомо первых писания скриптов, а вторых — писания на всяких «труЪ языках» вроде С.
Чем написание скриптов не программирование? Или, по-вашему, скрипт — это не программа, написанная на языке, доступном её интерпретатору?
Мало того, практически все скриптовые языки — полные по Тьюрингу.
Мне тут мерещатся следы какого-то глупого холивара на тему искусственного разделения «админов» и «программеров» с отдачей в ведомо первых писания скриптов, а вторых — писания на всяких «труЪ языках» вроде С.
А мне кажеться, что вы ищете черную кошку в черной комнате.
Я хочу сказать ровно одно, что чем меньше ты пишешь программ, тем лучше. Лучшая программа, это не написаная программа, и если ты можешь сказать:
cat file | sort | uniq > file2
а не писать программу для этого, то лучше это сказать. Да, ты не будешь программировать. Но ты решишь свою задачу. Программирование это просто способ, инструмент, решения задач.
Основная идея поста, главного, была, что этот инструмент учит призновать свои ошибки. И в них, наверное, и есть духовная сила программирование. Она важна, не спорю. Но решить исходную задачу, важнее.
Я хочу сказать ровно одно, что чем меньше ты пишешь программ, тем лучше. Лучшая программа, это не написаная программа, и если ты можешь сказать:
cat file | sort | uniq > file2
а не писать программу для этого, то лучше это сказать. Да, ты не будешь программировать. Но ты решишь свою задачу. Программирование это просто способ, инструмент, решения задач.
Основная идея поста, главного, была, что этот инструмент учит призновать свои ошибки. И в них, наверное, и есть духовная сила программирование. Она важна, не спорю. Но решить исходную задачу, важнее.
То есть, программирование действий интерпретатора коммандной строки вы за программирование не считаете? =)
cat file | sort | uniq > file2 — это, по вашему, не программа, написанная в одну строку? =)Да, она использует просто вызов внешних исполняемых модулей с параметрами, но чем это отличается от вызова функций стандартных библиотек в С? ;)
для меня в этом, намного больше программирования, чем в 100500 тысячах строк на Си. Ибо тут, ты программируешь (=решаешь задачу), не программируя (=не создавая не строчки кода).
По-моему, фразы вроде «программировать не программируя» — это просто запутывание в терминах и сродни <a href="«lurkmore.ru/Взаимоисключающие_параграфы»>кащенизму
Не понимаю, почему строка команды не является строкой «кода».
Не понимаю, почему строка команды не является строкой «кода».
По-доброму завидую вам. Хотелось бы и мне так уметь. Интересно — да, но вот как получить эти знания…
Создать новое и чувствовать себя богом — слишком разные вещи. Нет сейчас этой детской радости.
а было ли за что чувствовать себя богом в детстве? а за что чувствовать себя богом сейчас? Может стоит подвинуть планку повыше и таки бросить всё и допрыгнуть? А то слишком низкая планка не дает совести считать это достижением…
Вы как то выпускаете из виду результат.Меня очень радует пордукт который получается на выходе.Прикольно закончить большой долгий проект, подвести так сказать черту.
это само собой радует, но не так уже, не те уже ощущения, раньше пока кодишь был такой прилив адреналина, думаю не меньше чем у человека который с парашютом прыгает впервые, а теперь нету этого, программирование превратилось просто в написание текста понятного немногим, ей богу как в матрице ) просто смотришь в буквы и цифры, а видишь целую картину…
Проект, результат. Почему я это опускаю? Сдал продукт, молодец. Сдал хороший продукт, молодец, теперь ты богатый, у тебя есть яхта.
Но не это меня привлекает в программирование. Не результат.
Но не это меня привлекает в программирование. Не результат.
Нет причем тут молодец? я имел виду принцип «Любим процесс помним о результате».Я не о материальной стороне, а о чувстве удовлетворения хорошо проделанной работой.Чувстве гордости.
Ну знаете такая приятная пустота, как после закрытия сессии в институте...=))
Правда со временем я стал считать героизмом не добавление недокументированных фич, а просто сдачу качественного проекта в срок.
Касательно той части что «процесс»… но просто может не стоит романтизировать так сильно нашу с вами работу? Это такая же работа как все остальные.Просто делайте небольшие проекты для души.
Сделайте сайт любимому бару, любимой группе.Напишите маленькую Open Source утилиту.
И не забивайте себе голову всякими размышлениями, тем более перед новым годом.
«Никто не запомнит вас за ваши мысли»@Г.М. Маркес
Ну знаете такая приятная пустота, как после закрытия сессии в институте...=))
Правда со временем я стал считать героизмом не добавление недокументированных фич, а просто сдачу качественного проекта в срок.
Касательно той части что «процесс»… но просто может не стоит романтизировать так сильно нашу с вами работу? Это такая же работа как все остальные.Просто делайте небольшие проекты для души.
Сделайте сайт любимому бару, любимой группе.Напишите маленькую Open Source утилиту.
И не забивайте себе голову всякими размышлениями, тем более перед новым годом.
«Никто не запомнит вас за ваши мысли»@Г.М. Маркес
Нет причем тут молодец? я имел виду принцип «Любим процесс помним о результате».Я не о материальной стороне, а о чувстве удовлетворения хорошо проделанной работой.Чувстве гордости.
а разве материальная составляющая не лудшая часть удоволетворения от работы?
Ну знаете такая приятная пустота, как после закрытия сессии в институте...=))
Хм. Нечего делать. Знаю, помню. Сейчас такого нет :)
Правда со временем я стал считать героизмом не добавление недокументированных фич, а просто сдачу качественного проекта в срок.
Может с увелечением размера проекта? Просто чем больше проект, тем больше сложность его…
Касательно той части что «процесс»… но просто может не стоит романтизировать так сильно нашу с вами работу? Это такая же работа как все остальные.Просто делайте небольшие проекты для души.
Сделайте сайт любимому бару, любимой группе.Напишите маленькую Open Source утилиту.
Так получилось, что я давно стал прогматиком в плане программирования. Вы не увидели мысль, а может я ее не явно преподнес, но то, как вы поняли мои мысли, тоже интересно.
Делать маленькие проекты для души? В них нет того, что я ищу в программирование ;)
а разве материальная составляющая не лудшая часть удоволетворения от работы?
Ну знаете такая приятная пустота, как после закрытия сессии в институте...=))
Хм. Нечего делать. Знаю, помню. Сейчас такого нет :)
Правда со временем я стал считать героизмом не добавление недокументированных фич, а просто сдачу качественного проекта в срок.
Может с увелечением размера проекта? Просто чем больше проект, тем больше сложность его…
Касательно той части что «процесс»… но просто может не стоит романтизировать так сильно нашу с вами работу? Это такая же работа как все остальные.Просто делайте небольшие проекты для души.
Сделайте сайт любимому бару, любимой группе.Напишите маленькую Open Source утилиту.
Так получилось, что я давно стал прогматиком в плане программирования. Вы не увидели мысль, а может я ее не явно преподнес, но то, как вы поняли мои мысли, тоже интересно.
Делать маленькие проекты для души? В них нет того, что я ищу в программирование ;)
Для меня программирование интересно, пока есть нерешенные ПРОБЛЕМЫ (именно так, с большой, мелкие баги не так интересны). Не придуман алгоритм вычисления чего-то, нужна оптимизация сложнейшего запроса… Знакомство с новыми технологиями…
А вам часто приходиться придумывать новый алгоритм? А технологии… А давно было что-то действительно новое, а не buzzwords?
Технологии (в данном случае) необязательно что-то глобально новое :) На самом деле даже знакомство с новым плагином/модулем для фреймворка можно сюда подогнать. Про алгоритмы то же самое — необязательно это должен быть алгоритм из области создания ИИ.
Вообще, я программирую в свободное время, для души, так что стараюсь, чтобы мне было интересно, а не клепаю одинаковых десять интернет-магазинов в месяц :)
Вообще, я программирую в свободное время, для души, так что стараюсь, чтобы мне было интересно, а не клепаю одинаковых десять интернет-магазинов в месяц :)
Вот, а это были мысли, так сказать, професионального программиста, у которого первый компьютер появился в лето, перед 1ым классом.
Это может мне каким-то образом мешать любить программирование? Или запрещает об этом вслух что-то говорить? ;)
Нет. Просто, вы меня не поймете. Я старый, занудный старпер который давно стал прогматиком.
Не поймите неправильно, но у меня первый компьютер появился только после 9 класса в связи с тяжелой экономической ситуацией, впрочем это мне не мешало торчать в компьютерном классе школы вечерами и ходить в кружок программирования, изучая и познавая этот великий созидательный процесс программирования. Я к тому, что для программирования совершенно не обязательно иметь дома личный компьютер, и не все профессиональные программисты становятся ими из-за обиды на злой компьютер; мне в первую очередь нравится ломать мозг, придумывать что-то новое, я от этого получаю непередаваемый кайф, более того я думаю, что программирование — это источник неиссякаемого самоудовлетворения, главное это понять, и тогда, как вы выразились, «кризис среднего возраста» не будет вас тревожить в возрасте 22 лет.
>На самом деле даже знакомство с новым плагином/модулем для фреймворка можно сюда подогнать.
Так только первые пару десятков. Потом это всего лиш еще один фреймворк который делает то что итак уже известно просто «впрофиль», ето еще один модуль который делает что то что итак уже делали 50 раз, просто ну чуть чуть подругому.
И я не о интернет-магазин-девелоперах… :-) Вечная гонка за новыми тезнологиями надоела, всеравно ничего оно не меняет.
Так только первые пару десятков. Потом это всего лиш еще один фреймворк который делает то что итак уже известно просто «впрофиль», ето еще один модуль который делает что то что итак уже делали 50 раз, просто ну чуть чуть подругому.
И я не о интернет-магазин-девелоперах… :-) Вечная гонка за новыми тезнологиями надоела, всеравно ничего оно не меняет.
и это еще один язык программирования, который делает что-то в профиль. Вот malbolge был интересен. Я на нем даже программу написал :) Но только интересен.
скучно программировать… ну добро пожаловать в менеджеры
а вообще программизм это отличное место для реализации своей потребности в исследованиях и самосовершенствовании. Считаете что в совершенстве овладели каким-то языком программирования или парадигмой? Переходите на другую парадигму или язык! Считаете что вашу программу уже идеальнее не написать? Забросте ее, напишите другую, и через годик вернитесь к своей старой. Думаю «ох да тут сколько можно переделать понормальному» вы себе скажете.
Но ни в коем случае не надо забывать, что программированием мир не ограничивается, если интересно, затягивает, дает драйв — занимайтесь. Если нет — оглянитесь вокруг!
а вообще программизм это отличное место для реализации своей потребности в исследованиях и самосовершенствовании. Считаете что в совершенстве овладели каким-то языком программирования или парадигмой? Переходите на другую парадигму или язык! Считаете что вашу программу уже идеальнее не написать? Забросте ее, напишите другую, и через годик вернитесь к своей старой. Думаю «ох да тут сколько можно переделать понормальному» вы себе скажете.
Но ни в коем случае не надо забывать, что программированием мир не ограничивается, если интересно, затягивает, дает драйв — занимайтесь. Если нет — оглянитесь вокруг!
Знаешь, управление проектами, пока не привлекает.
Надоело не программирование. Надоело что ценных и хороших задач там почти нет. С опытом понимаешь, что хорошую, годную задачу искать приходиться долго и попадается она иногда.
Надоело не программирование. Надоело что ценных и хороших задач там почти нет. С опытом понимаешь, что хорошую, годную задачу искать приходиться долго и попадается она иногда.
Я вообще человек не азартный, но однажды в школе я поспорил аж на 10 рублей о чем то, только потому что был прав на 120% как мне казалось. Я был готов дать голову на отсечение а не только 10 руб.
Когда я отдал свои 10 руб, я долго думал как такое могло произойти.
С тех пор я никогда не оцениваю свою уверенность в правильности решения в 100%, ни в программировании ни в жизни. Иначе получается очень дорогой способ познавать мир через СВОИ ошибки.
Теперь свои ошибки признаю с легкостью и не стараюсь выкручиваться. Окружающие это ценят. А вот люди с имиджем «непогрешимых всезнаек-гениев» обычно непопулярны. Когда такие люди садятся в лужу получается много брызг и разговоров за спиной.
Когда я отдал свои 10 руб, я долго думал как такое могло произойти.
С тех пор я никогда не оцениваю свою уверенность в правильности решения в 100%, ни в программировании ни в жизни. Иначе получается очень дорогой способ познавать мир через СВОИ ошибки.
Теперь свои ошибки признаю с легкостью и не стараюсь выкручиваться. Окружающие это ценят. А вот люди с имиджем «непогрешимых всезнаек-гениев» обычно непопулярны. Когда такие люди садятся в лужу получается много брызг и разговоров за спиной.
Очень жизненно и довольно приятно, что люди таким делятся. Да, это так — чувство «бога»/«строителя мира», называйте как хотите. Лично у меня не пропал интерес к этому с такой точки зрения, а только вновь он загорается, когда я изучаю новые технологии и тут же стараюсь их где-нибудь использовать. Я думаю всем знакомо чувство, когда ты ставишь перед собой цель, у тебя не сразу получается её достичь, а когда получается, то испытываешь неописуемое чувство восторга, но когда цель не такая большая, как затраченные усилия, то и «счастья» может не возникнуть такого =) Единственная проблема, с которой я сталкиваюсь по сей день — это нагрузки. Очень часто пытаюсь взвалить (вообще, характер такой: всё и сразу) на свои плечи сверх своих возможностей и сил, и к середине проекта мотивация начинает уходить (если проект свой, а не заказ), что очень обидно. Тут только спасение друзей и подруг как моральная и физическая поддержка. Хотя может есть какие-то другие способы добавить себе мотивации… =)
напишите свою ос. это увлекательно и быстро не напишете
Быть может стоит попробовать макраме? Или сравнительную лингвистику?
Когда начинаешь осознавать себя умудренным — явный признак, что следует перейти к области, где чувствуешь себя лошарой чилийским. Старость — это когда теряешь способность менять эту самую область.
Когда начинаешь осознавать себя умудренным — явный признак, что следует перейти к области, где чувствуешь себя лошарой чилийским. Старость — это когда теряешь способность менять эту самую область.
На мой взгляд в любом проекте можно реализовать множество очень красивых, изящных и доставляющих несравнимое удовольствие, архитектурных решений, способных повергнуть в прах труды GoF, Фаулера и прочих изыскателей «теории всего» в дизайне систем :-)
Впрочем, коммерческое программирование далеко от искусства, далеко от полёта идей и мыслей в свободном программировании. Возможно, что просто Вы дошли до той стадии программиста, когда требуется уйти в свободное плавание, до собственных проектов и изысканий? Возможно, что до стадии, когда начинаешь думать, что знаешь о программировании всё…
Впрочем, коммерческое программирование далеко от искусства, далеко от полёта идей и мыслей в свободном программировании. Возможно, что просто Вы дошли до той стадии программиста, когда требуется уйти в свободное плавание, до собственных проектов и изысканий? Возможно, что до стадии, когда начинаешь думать, что знаешь о программировании всё…
Вы, скорее всего, мне не поверите, но истинное «дао бага» заключается в том, что багов быть вообще не должно! Конечно, в реальности такого не бывает, баги есть всегда. Но баги бывают разные.
Простые баги, фактически опечатки либо от невнимательности, либо от незнания каких-то мелких нюансов — есть были и будут всегда, пока программы пишут люди. Такие баги могут существовать не обнаруженными годами, просто потому, что эту часть кода никто не использует. Но как только этот код начинает работать, баг проявляется моментально, его легко заметить, найти и пофиксить. Никакого research при этом не требуется, и никакого просветления при этом не наступает — простая, практически механическая работа по локализации ошибки, исправлению, тестированию, и релизу новой версии.
А вот сложных багов, вроде упомянутых в статье — быть не должно в принципе. И эта цель в реальности вполне достижима, в т.ч. для больших и сложных проектов. Именно сложные баги топят, в конечном счёте, проекты до состояния «надо всё переписать». Их зачастую не могут поймать, не могут понять, а иногда даже поймав и поняв не могут правильно пофиксить. Именно из-за них архитектура проекта очень быстро скрывается под толпами странных и кривых workaround-ов… Но — да, автор прав. После героических усилий по обнаружению и пониманию таких багов можно испытать некий извращённый кайф типа «gotcha» (не имеющий, впрочем, никакого отношения к просветлению).
Рецепт прост: чтобы избежать сложных багов в большом и сложном проекте — не пишите большой и сложный проект. Разделите этот проект на кучу маленьких и простых, разграничьте эти маленькие между собой чёткими и простыми интерфейсами, и вы получите функциональность большого и сложного проекта без необходимости писать сложный код. При этом не так важно, что именно будут представлять из себя физически эти маленькие и простые проекты — объекты, библиотеки, нити CSP, отдельные программы или сетевые сервисы — до тех пор, пока каждый решает свою простую задачу и между ними сохраняются чёткие и простые интерфейсы (хотя я бы рекомендовал использовать для этого отдельные программы либо сетевые сервисы — будет сложнее нарушить границы между проектами заведением, например, общих глобальных переменных).
В качестве примеров реальных больших и сложных open source проектов, разработанных по этому принципу, можете посмотреть на операционки Inferno и Plan9, утилиты DJB (qmail, djbdns, ...), etc. Безусловно, сложные баги, наверняка, встречаются и там. Но их количество и запутанность на порядки ниже тех, которые встречаются в любой навороченной CMS-ке, в то время как объективная сложность и размер, например, той же OS Inferno, на порядки выше этих CMS-ок. И если смотреть с этой, относительной точки зрения, можно честно сказать, что кол-во сложных багов в проектах, разработанных по этому принципу, пренебрежимо мало.
Что касается любви к программированию вообще, и дефицита сложных интересных задач в частности. Когда любовь к программированию вырождается в любовь к багам — это уже извращение. А сложные и интересные задачи есть всегда, они рядом, их просто надо суметь увидеть в текущей работе. Конкретнее, решить текущую задачу «настолько просто, насколько это возможно, но не проще» — это очень сложная и интересная задача. Как это ни парадоксально, но самое простое и напрашивающееся решение обычно на самом деле очень сложное и запутанное — эти решения обычно выбирают новички. А чтобы решить задачу действительно простым способом — тем самым, который не приводит позднее к появлению сложных багов — требуется иной раз очень сильно сдвинуть мозги, забыть про проторенные дорожки и шаблонные решения.
Простые баги, фактически опечатки либо от невнимательности, либо от незнания каких-то мелких нюансов — есть были и будут всегда, пока программы пишут люди. Такие баги могут существовать не обнаруженными годами, просто потому, что эту часть кода никто не использует. Но как только этот код начинает работать, баг проявляется моментально, его легко заметить, найти и пофиксить. Никакого research при этом не требуется, и никакого просветления при этом не наступает — простая, практически механическая работа по локализации ошибки, исправлению, тестированию, и релизу новой версии.
А вот сложных багов, вроде упомянутых в статье — быть не должно в принципе. И эта цель в реальности вполне достижима, в т.ч. для больших и сложных проектов. Именно сложные баги топят, в конечном счёте, проекты до состояния «надо всё переписать». Их зачастую не могут поймать, не могут понять, а иногда даже поймав и поняв не могут правильно пофиксить. Именно из-за них архитектура проекта очень быстро скрывается под толпами странных и кривых workaround-ов… Но — да, автор прав. После героических усилий по обнаружению и пониманию таких багов можно испытать некий извращённый кайф типа «gotcha» (не имеющий, впрочем, никакого отношения к просветлению).
Рецепт прост: чтобы избежать сложных багов в большом и сложном проекте — не пишите большой и сложный проект. Разделите этот проект на кучу маленьких и простых, разграничьте эти маленькие между собой чёткими и простыми интерфейсами, и вы получите функциональность большого и сложного проекта без необходимости писать сложный код. При этом не так важно, что именно будут представлять из себя физически эти маленькие и простые проекты — объекты, библиотеки, нити CSP, отдельные программы или сетевые сервисы — до тех пор, пока каждый решает свою простую задачу и между ними сохраняются чёткие и простые интерфейсы (хотя я бы рекомендовал использовать для этого отдельные программы либо сетевые сервисы — будет сложнее нарушить границы между проектами заведением, например, общих глобальных переменных).
В качестве примеров реальных больших и сложных open source проектов, разработанных по этому принципу, можете посмотреть на операционки Inferno и Plan9, утилиты DJB (qmail, djbdns, ...), etc. Безусловно, сложные баги, наверняка, встречаются и там. Но их количество и запутанность на порядки ниже тех, которые встречаются в любой навороченной CMS-ке, в то время как объективная сложность и размер, например, той же OS Inferno, на порядки выше этих CMS-ок. И если смотреть с этой, относительной точки зрения, можно честно сказать, что кол-во сложных багов в проектах, разработанных по этому принципу, пренебрежимо мало.
Что касается любви к программированию вообще, и дефицита сложных интересных задач в частности. Когда любовь к программированию вырождается в любовь к багам — это уже извращение. А сложные и интересные задачи есть всегда, они рядом, их просто надо суметь увидеть в текущей работе. Конкретнее, решить текущую задачу «настолько просто, насколько это возможно, но не проще» — это очень сложная и интересная задача. Как это ни парадоксально, но самое простое и напрашивающееся решение обычно на самом деле очень сложное и запутанное — эти решения обычно выбирают новички. А чтобы решить задачу действительно простым способом — тем самым, который не приводит позднее к появлению сложных багов — требуется иной раз очень сильно сдвинуть мозги, забыть про проторенные дорожки и шаблонные решения.
Большое спасибо за заметку и высказывание своей мысли, прочитал с удовольствием и в очередной раз посмотрел на эти вещи со стороны.
К последнему абзацу так и хочется добавить: «ничего невозможно нет» и «лёгкие пути к успеху — ни есть успех». Это имхо.
з.ы. жаль галочку поставить не могу =(
К последнему абзацу так и хочется добавить: «ничего невозможно нет» и «лёгкие пути к успеху — ни есть успех». Это имхо.
з.ы. жаль галочку поставить не могу =(
Прямо в точку=) повысил бы карму если бы мог=))
Хм. qmail говорите. А он не умеет ничего, что от него хотят. На него накладывают 100500 патчей, и там появляются баги (года 4-5 назад у меня почта жила на qmail ☺).
Вы говорите, хорошие, красивые, правильные вещи. Но они, к сожалению, совместимы, только с идеальном миром. Наш мир, ну может быть для вас идеальный. А для меня, он, бука такая, вплоне реальный.
Вы говорите, хорошие, красивые, правильные вещи. Но они, к сожалению, совместимы, только с идеальном миром. Наш мир, ну может быть для вас идеальный. А для меня, он, бука такая, вплоне реальный.
Хм. Вы удивитесь, нужды скольких людей удовлетворяет qmail без всяких патчей! Ну, если совсем точно, то с абсолютными минимумом тривиальных патчей, просто чтобы он собирался современным gcc, etc. — это называется netqmail. Можете посмотреть сам патч netqmail-1.05.patch, который накладывается на последнюю версию qmail-1.03 — он абсолютно тривиален. И даже netqmail не меняется уже почти 6 лет, посмотрите changelog.
Да, функциональности qmail достаточно для многих, но не для всех. Кто-то решает эту проблему кривыми патчами qmail, кто-то переходит на альтернативные почтовые сервера. И я считаю это абсолютно нормальным — лучше иметь простую и надёжную утилиту решающую 95% задач чем навороченный, глюкавый, дырявый и тормозящий комбайн, решающий 100% задач. В большинстве случаев можно обойтись простой утилитой, а в остальных, если очень надо, можно и комбайн поставить, осознавая плюсы и минусы такого решения.
Что касается мира — как Вы точно подметили, он для каждого свой. И Вы, и только Вы сами выбираете, каков будет мир лично для Вас. У меня мир более чем реальный, хотя по сравнению с Вашим он запросто может казаться идеальным. Но это не делает его менее реальным. :) И не означает, что для Вас этот мир не может стать реальным, если Вы того захотите.
Да, функциональности qmail достаточно для многих, но не для всех. Кто-то решает эту проблему кривыми патчами qmail, кто-то переходит на альтернативные почтовые сервера. И я считаю это абсолютно нормальным — лучше иметь простую и надёжную утилиту решающую 95% задач чем навороченный, глюкавый, дырявый и тормозящий комбайн, решающий 100% задач. В большинстве случаев можно обойтись простой утилитой, а в остальных, если очень надо, можно и комбайн поставить, осознавая плюсы и минусы такого решения.
Что касается мира — как Вы точно подметили, он для каждого свой. И Вы, и только Вы сами выбираете, каков будет мир лично для Вас. У меня мир более чем реальный, хотя по сравнению с Вашим он запросто может казаться идеальным. Но это не делает его менее реальным. :) И не означает, что для Вас этот мир не может стать реальным, если Вы того захотите.
Слишком хорошо чтобы быть правдой. Сколько вы знаете коммерческих проектов у котороых бы проходило по 12 месяцев от начала проектирования до первой строчки кода? Спешка — основной фактор слабостей дизайна тяжелых багов, хотя остается еще незнание того что требуется получить, но это слишком тонкая материя.
А кто говорил про 12 месяцев? Чтобы большой проект развалить на кучку мелких достаточно от нескольких часов до нескольких дней — зависит от опыта архитектора и наличия необходимого минимума информации о проекте. Писать маленькие простые проекты намного быстрее и легче, чем один большой и сложный — тут уже нарисовывается нехилая экономия времени разработки. Поддерживать и тестировать маленькие проекты тоже на порядок проще — экономия времени достигает невероятных масштабов. После чего всё сэкономленное время сливается на то, что вместо того, чтобы кодить в поте лица, фиксить тучи багов, и жить от дедлайна до дедлайна — очень очень лениво, даже без вхождения в «поток», не спеша, пишется простой код. :)
Преждем чем делить на части требуется определить как эти части будут взаимодействовать, как оператор будет получать результат, определить форматы файлов наконец. Вот тут-то нужны совсем не часы и не дни, а иной раз месяцы. Чем лучше все проработано, тем меньше ошибок и тем точнее можно будет определить время окончания работ.
Вы, вероятно, не до конца понимаете суть того, что я описал. Ничего такого, что Вы описываете, не требуется. Месяцы не нужны. Более того, если на эту работу нужны месяцы и всё получается настолько сложно — значит всё делается неправильно: Вы пытаетесь разделить большее приложение на меньшие части не в том месте. Именно из-за неправильного выбора этих меньших частей и возникают все сложности. И нужно не героически преодолевать эти сложности за месяцы напряжённой работы, а иначе разделить большее приложение на части — там, где оно более легко и естественно разделяется.
Eсть хорошее rule of thumb: вся эта возня с дроблением на маленькие подзадачи призвана сделать Вашу жизнь намного легче, код проще, а багов меньше. Если на практике вместо этого стало только хуже — значит Вы неправильно разделили большой проект на маленькие. И не бойтесь большого количества маленьких проектов — чем их больше, тем каждый их них меньше, писать его легче, и интерфейсы у него проще и универсальнее. (Когда в Вашем проекте появится отдельный сервис, единственной задачей которого является генерация уникальных ID по запросу другим сервисам — знайте, что Вы, скорее всего, на правильном пути. ;-))
определить как эти части будут взаимодействоватьА что тут определять? Это как раз наименее принципиальный вопрос — любой подходящий способ взаимодействия подойдёт. Например, если эти мелкие задачи оформляются в виде сетевых сервисов, значит взаимодействовать они будут либо через некий единообразный протокол вроде JSON-RPC, либо у каждой будет свой собственный протокол, наиболее подходящий для конкретно этого сервиса — у одного RPC, у другого постоянно открытый tcp-сокет по которому он отправляет события по мере их возникновения, etc. Безусловно, таких сервисов скоро станет много, и для управления ими понадобится некий реестр сервисов — но это разовая задача, которая решается один раз и дальше можно этим реестром пользоваться во всех проектах. Мы, например, вообще свой не писали, а подняли стандартный реестр сервисов из OS Inferno. Если Вы работаете в какой-нить навороченной среде, и Вас не волнует куча лишнего мусора бегающего по сети — можно использовать стандартные решения типа WS-crap/SOAP, etc. В общем, берёте любое подходящее решение для организации взаимодействия между сервисами/проектами/объектами/etc.
как оператор будет получать результатЭто тоже абсолютно не важно. Как ему удобно, так и будет. Когда проект разделён на мелкие подзадачи, то результат для оператора подготавливается просто через несколько запросов к этим подзадачам. И эта задача подготовки результата для оператора выносится в отдельную подзадачу. Нужно будет оператору получить другой результат и в другом формате — просто пишется ещё одна маленькая подзадача для этих целей. Иными словами, этой «проблемы» на этапе дробления проекта на подзадачи практически не существует, любой интерфейс для оператора всегда без проблем навешивается сверху на имеющуюся систему.
определить форматы файловНе совсем понял, причём здесь форматы файлов. Если Вы про то, что разные подзадачи будут работать с одними и теми же файлами, поэтому нужно тщательно разработать их формат — так это в корне неверно. Задачи необходимо максимально изолировать друг от друга, никаких сильных связей между задачами создавать нельзя. И, разумеется, две задачи не должны лазить в один и тот же файл, или базу данных — фактически, этот файл/база играют роль громадных глобальных переменных разделяемых несколькими задачами! У каждой задачи должны быть свои файлы/базы, а всё взаимодействие между задачами должно идти через чёткие и максимально простые интерфейсы.
Чем лучше все проработано, тем меньше ошибокНет, чем на большее количество мелких подзадачек Вы разобьёте свой большой проект, тем меньше Вас будет волновать степень общей проработанности. Простой пример: авторы никсовых утилит grep, sort, uniq, etc. и не думали прорабатывать все возможные способы способы воспользоваться их утилитами. Просто сами утилиты настолько просты, и у них настолько чёткие интерфейсы, что ими можно пользоваться для множества задач, которые авторы этих утилит даже представить себе не могли. Вот и в Вашем проекте должны быть такие же простые и более-менее универсальные маленькие задачи, на базе которых в результате можно будет собрать требуемый Вам большой проект. И если возникает потребность тщательно всё прорабатывать, постоянно выявляются ошибки в структуре и интерфейсах — значит Вы идёте не в ту сторону, скорее всего Вы не в том месте разделили большую задачу на меньшие и у Вас из-за этого появляются гораздо более сложные и менее гибкие интерфейсы между подзадачами.
Eсть хорошее rule of thumb: вся эта возня с дроблением на маленькие подзадачи призвана сделать Вашу жизнь намного легче, код проще, а багов меньше. Если на практике вместо этого стало только хуже — значит Вы неправильно разделили большой проект на маленькие. И не бойтесь большого количества маленьких проектов — чем их больше, тем каждый их них меньше, писать его легче, и интерфейсы у него проще и универсальнее. (Когда в Вашем проекте появится отдельный сервис, единственной задачей которого является генерация уникальных ID по запросу другим сервисам — знайте, что Вы, скорее всего, на правильном пути. ;-))
А можно пример проекта, который вы смогли разделить на маленькие части? Хочу узнать хоть что-то, чему повезло.
Да, вы брукса читали?
Да, вы брукса читали?
Брукса все читали. Правда, я его читал настолько давно, что уже толком ничего не помню, кроме общего ощущения тривиальности излагаемых идей. Хотя, я слышал, для многих эта книжка была настоящим открытием.
С примерами сложнее. Мой текущий проект не open source, так что показать не могу. Проекту уже 7.5 лет, 7 из которых он приносит доход моему заказчику. Было много проблем со скоростью развития проекта — чем он больше становился, тем сложнее было что-то менять, фичи добавлялись чуть ли не месяцами. Но с тех пор, как я проникся идеями OS Inferno, проект начали потихоньку дробить на подзадачи, переходить на сервис-ориентированную архитектуру, etc. и дышать чем дальше — тем легче. Код пишется быстрее и уже не требует глубокого «погружения», чтобы он был качественным и ничего не ломал в других местах проекта.
Помимо этого я практикую подход с маленькими подзадачами в небольших вспомогательных утилитах, но там какие-то серьёзные преимущества заметить сложнее, т.к. маленькую утилиту можно написать тупо и прямолинейно и тоже ничего смертельно страшного не произойдёт. Впрочем, лично для меня разница более чем заметна и в этом случае — код получается проще, яснее и элегантнее. Но эти утилитки обычно пишутся на Limbo, с использованием нитей CSP, и там отдельная подзадача это не сетевой сервис, как в нашем большом проекте, а отдельная нить. Но суть от этого не меняется.
В некоторых случаях после продумывания архитектуры и дробления на подзадачи выясняется, что часть задач уже реализована стандартными утилитами, и то, что осталось написать мне — даже стыдно немного называть «программой». Но если учесть изначальную (до дробления на подзадачи) постановку задачи, и количество кода, которое изначально планировалось писать — вполне можно гордиться результатом. Примеры таких утилит есть у меня на сайте, напр. powerbackup и powerwatchdog (к сожалению, никак руки не дойдут доку к последнему написать на сайт).
Но самые главные примеры таких проектов, это, конечно, OS Inferno и Plan9. Лучше смотреть на них, а не на меня — я только учусь применять фишки обнаруженные в OS Inferno в своих реальных проектах. Вообще, изучение кода Inferno даёт очень много в плане самообразования! Я, при моих 20-ти годах программирования и непрерывного самообразования, признаться уже думал, что учиться мне нечему. К счастью — это заблуждение быстро прошло, спасибо OS Inferno. :)
С примерами сложнее. Мой текущий проект не open source, так что показать не могу. Проекту уже 7.5 лет, 7 из которых он приносит доход моему заказчику. Было много проблем со скоростью развития проекта — чем он больше становился, тем сложнее было что-то менять, фичи добавлялись чуть ли не месяцами. Но с тех пор, как я проникся идеями OS Inferno, проект начали потихоньку дробить на подзадачи, переходить на сервис-ориентированную архитектуру, etc. и дышать чем дальше — тем легче. Код пишется быстрее и уже не требует глубокого «погружения», чтобы он был качественным и ничего не ломал в других местах проекта.
Помимо этого я практикую подход с маленькими подзадачами в небольших вспомогательных утилитах, но там какие-то серьёзные преимущества заметить сложнее, т.к. маленькую утилиту можно написать тупо и прямолинейно и тоже ничего смертельно страшного не произойдёт. Впрочем, лично для меня разница более чем заметна и в этом случае — код получается проще, яснее и элегантнее. Но эти утилитки обычно пишутся на Limbo, с использованием нитей CSP, и там отдельная подзадача это не сетевой сервис, как в нашем большом проекте, а отдельная нить. Но суть от этого не меняется.
В некоторых случаях после продумывания архитектуры и дробления на подзадачи выясняется, что часть задач уже реализована стандартными утилитами, и то, что осталось написать мне — даже стыдно немного называть «программой». Но если учесть изначальную (до дробления на подзадачи) постановку задачи, и количество кода, которое изначально планировалось писать — вполне можно гордиться результатом. Примеры таких утилит есть у меня на сайте, напр. powerbackup и powerwatchdog (к сожалению, никак руки не дойдут доку к последнему написать на сайт).
Но самые главные примеры таких проектов, это, конечно, OS Inferno и Plan9. Лучше смотреть на них, а не на меня — я только учусь применять фишки обнаруженные в OS Inferno в своих реальных проектах. Вообще, изучение кода Inferno даёт очень много в плане самообразования! Я, при моих 20-ти годах программирования и непрерывного самообразования, признаться уже думал, что учиться мне нечему. К счастью — это заблуждение быстро прошло, спасибо OS Inferno. :)
ok. А сколько человек участвует в этом проекте и какую роль ты занимаешь в этом проекте?
Я не совсем понимаю, какое отношение это имеет к обсуждаемой теме, но ответить могу: я ведущий разработчик, архитектор и, по совместительству, админ; в команде в разное время было разное количество людей, 10-15 в среднем.
Странно что для команды в 10-15 человек, один занимается фактически всем.
Ну, может оно и странно, но такая специфика. У нас много ресурсов уходит на написание, поддержку и тестирование парсеров (для работы системы требуется непрерывно выкачивать и обсчитывать данные с кучи разных сайтов), и этим занято много людей. А я ядро системы пишу и в целом за всё отвечаю. Активных разработчиков кроме меня не так много — от одного до трёх, в среднем. Возможно это так же связано со спецификой рабочего процесса — у нас по сути группа фрилансеров, а не компания, народ берётся за работу только если она интересна, заставить работать кого-то (в т.ч. и меня) если он не хочет — крайне проблематично. Так что я занимаюсь тем, что интересно лично мне, и меня мало волнует то, что это сразу несколько разных ролей/профессий — для разных видов работ клиенту просто выставляется разная почасовка. Вообще, для фрилансера это скорее норма, делать работу разных специалистов — и проекты искать, и с клиентами общаться, и тз составлять, и архитектуру делать, и код писать, и тестировать, и устанавливать, и сервер админить, и деньги как-то получать, с налогами разбираться, etc. — полный цикл, и никуда от этого не денешься. Зато, если у меня пропадает рабочее настроение, я могу просто проинформировать клиента, что в работе намечается очередной перерыв, и два месяца проваляться с книжками на диване, пока рабочее настроение не вернётся.
Ага, ясно, фактически пишешь проект один, тогда это объясняет многое.
Да, с некоторой натяжкой можно сказать и так. Но Inferno и Plan9 писал не один разработчик, не два и не три — например здесь перечислены 35 человек, и это без учёта вклада коммьюнити, только, так сказать, «родители» Plan9.
Так что не знаю, какие именно Вы сделали выводы исходя из того, что в моём случае основной разработчик один, но, боюсь, Вы исходите из неверных предпосылок и делаете неверные выводы.
Когда разработчик один, и он полностью контролирует архитектуру и код системы, он может написать и большой сложный проект избежав превращения кода и архитектуры в говно — группе разработчиков это уже намного сложнее. А в случае с кучей маленьких, независимых проектов с чёткими интерфейсами — всё наоборот, группе решить такую задачу качественно быстрее и проще, чем одиночке.
Так что не знаю, какие именно Вы сделали выводы исходя из того, что в моём случае основной разработчик один, но, боюсь, Вы исходите из неверных предпосылок и делаете неверные выводы.
Когда разработчик один, и он полностью контролирует архитектуру и код системы, он может написать и большой сложный проект избежав превращения кода и архитектуры в говно — группе разработчиков это уже намного сложнее. А в случае с кучей маленьких, независимых проектов с чёткими интерфейсами — всё наоборот, группе решить такую задачу качественно быстрее и проще, чем одиночке.
Да группе решить такую задачу быстрее и проще, пока задача не меняеться. Как только задача начинает расширяться, видоизменяться (а бизнес процессы и бизнес задачи меняються, это нормально, это жизнь) — начинаються проблемы. Вы не предусмотрели интерфейс. Надо переделывать пол системы. Или строить workaround. Такой workaround есть, например, сеть в unix. plan9 проектировали, учитывая, что сеть уже есть, например.
Вы, в своих рассуждениях, не учитываете ровно одну вещь — человеческий фактор. Пока вы работаете один, у вас его нет. Как только у вас появляется комманда — возникают эти вопросы.
Вы, в своих рассуждениях, не учитываете ровно одну вещь — человеческий фактор. Пока вы работаете один, у вас его нет. Как только у вас появляется комманда — возникают эти вопросы.
p.s. а у меня член 35 см, в ширину, в диаметре
Да, что касается «незнания того, что требуется получить». Этот фактор имеет место быть, но… если вы вместо большого проекта пишете, условно говоря, два десятка небольших утилит а-ля никсовые grep|sort|uniq|etc., то при изменении задачи есть высокая вероятность, что вы выкинете пару утилит за ненадобностью, но остальные отлично подойдут под изменившиеся условия задачи. А в случае с большим проектом бывает так, что архитектура полностью не подходит под изменившуюся задачу и нужно либо переделывать вообще всё, либо ещё до первого релиза засирать архитектуру кривыми хаками и workaround-ами.
чем более гибкий дизайн проекта вы делаете, тем больше сил требуется на его поддержку, а значит и времени и денег. У вас есть const по времени релиза и бюджет.
Вы можете сделать проект гибким, хорошим, красивым, но вы не уложитесь в бюджет. Вы не уложетесь в сроки. И оба ваших лучших программиста уйдут от вас, один отрпавиться на север, петь блюз, а другой уедет в тибет — вам придеться завершать проект горсткой дебилов, которые остались, ибо найти новых, вы не успеете.
Вы можете сделать проект гибким, хорошим, красивым, но вы не уложитесь в бюджет. Вы не уложетесь в сроки. И оба ваших лучших программиста уйдут от вас, один отрпавиться на север, петь блюз, а другой уедет в тибет — вам придеться завершать проект горсткой дебилов, которые остались, ибо найти новых, вы не успеете.
Да, если ключевое слово гибкий — Вы абсолютно правы, именно так всё и будет. Но в том подходе, о котором я пишу, ключевые слова другие: маленький и интерфейс.
Условно говоря, если разделить задачу «на месяц» на 4 задачи, что каждую из этих четырёх можно будет сделать не за неделю, а где-то за 3-4 дня. Просто за счёт того, что каждая из этих задач в несколько раз проще изначальной большой задачи. Это, в некотором смысле, аналогично тому, как локальные переменные сужают область видимости: когда пишется функция, у которой есть чёткий простой интерфейс (два параметра, одно возвращаемое значение, чётко определены типы и допустимые диапазоны принимаемых и возвращаемых значений), и которая работает только с локальными переменными (не лазит в общую базу данных, не лазит в общие файлы, не лазит в глобальные переменные, etc.), то в голове нет нужды держать весь проект, учитывать особенности взаимодействия этой функции со всеми остальными, и т.д. Так и здесь, если проект разбить на несколько меньших, и разграничить их чёткими и простыми интерфейсами, то писать код становится на порядок проще!
Меньше всего надо держать в голове, меньше требования к квалификации программистов реализующих конкретные небольшие проекты (ибо они во-первых небольшие, во-вторых простые, и в-третьих у них есть чёткие интерфейсы, благодаря которым легче писать автоматизированные тесты проверяющие корректность того, что они наваяли), появляется возможность сильнее распараллелить разработку проекта на большее количество разработчиков, если подпроекты реализовывать в стиле сетевых сервисов, то появляется возможность писать разные сервисы на разных языках и под разные ОС, и т.д. и т.п…
Безусловно, за всё надо платить, в том числе и за все эти «бонусы». В данном случае, с увеличением количества подзадач/проектов из которых собирается в результате необходимая функциональность большого проекта, сильно увеличиваются накладные расходы на поддержку всего этого хозяйства — возникает потребность в выделенном реестре сервисов, усложняется deploy системы (ибо вместо одной программы нужно установить два десятка и настроить их для совместной работы), etc. Но, по моему опыту, всё это сторицей окупается за счёт общего упрощения кода системы.
А гибкость, о которой Вы говорите, да и некая универсальность, хоть обычно и увеличиваются, но это побочный, а не основной эффект.
Условно говоря, если разделить задачу «на месяц» на 4 задачи, что каждую из этих четырёх можно будет сделать не за неделю, а где-то за 3-4 дня. Просто за счёт того, что каждая из этих задач в несколько раз проще изначальной большой задачи. Это, в некотором смысле, аналогично тому, как локальные переменные сужают область видимости: когда пишется функция, у которой есть чёткий простой интерфейс (два параметра, одно возвращаемое значение, чётко определены типы и допустимые диапазоны принимаемых и возвращаемых значений), и которая работает только с локальными переменными (не лазит в общую базу данных, не лазит в общие файлы, не лазит в глобальные переменные, etc.), то в голове нет нужды держать весь проект, учитывать особенности взаимодействия этой функции со всеми остальными, и т.д. Так и здесь, если проект разбить на несколько меньших, и разграничить их чёткими и простыми интерфейсами, то писать код становится на порядок проще!
Меньше всего надо держать в голове, меньше требования к квалификации программистов реализующих конкретные небольшие проекты (ибо они во-первых небольшие, во-вторых простые, и в-третьих у них есть чёткие интерфейсы, благодаря которым легче писать автоматизированные тесты проверяющие корректность того, что они наваяли), появляется возможность сильнее распараллелить разработку проекта на большее количество разработчиков, если подпроекты реализовывать в стиле сетевых сервисов, то появляется возможность писать разные сервисы на разных языках и под разные ОС, и т.д. и т.п…
Безусловно, за всё надо платить, в том числе и за все эти «бонусы». В данном случае, с увеличением количества подзадач/проектов из которых собирается в результате необходимая функциональность большого проекта, сильно увеличиваются накладные расходы на поддержку всего этого хозяйства — возникает потребность в выделенном реестре сервисов, усложняется deploy системы (ибо вместо одной программы нужно установить два десятка и настроить их для совместной работы), etc. Но, по моему опыту, всё это сторицей окупается за счёт общего упрощения кода системы.
А гибкость, о которой Вы говорите, да и некая универсальность, хоть обычно и увеличиваются, но это побочный, а не основной эффект.
Когда читаешь подобные заметки сразу же вспоминается рассказ с длинющей бородой,
«История одного байта» , там очень и очень раскрыта тема творца и прочий dzen программиста.
«История одного байта» , там очень и очень раскрыта тема творца и прочий dzen программиста.
Я дауншифтер и фрилансер, так стабильно и корпоративно кодить не умею и не хочу учиться принципиально.
Т.е. как бы — сочувствую, но несогласен. Но за фавикон в виде конвеевской споры (или это фишки для Го?) — в любом случае однозначно зачет.)
Т.е. как бы — сочувствую, но несогласен. Но за фавикон в виде конвеевской споры (или это фишки для Го?) — в любом случае однозначно зачет.)
и, да, я считаю, всегда есть масса проблем которые вы не закодите прям таки «плавным неотвратимым потоком»…
Под не интересной задачей, я имею ввиду задачу, которую я понимаю как решать :) То, что ее еще написать надо, поянтно. Но мой интерес иссякает к задаче, когда она обретает пути к решению.
Да, есть такой эффект, сам от него немного страдаю. Но, дело в том, что написать ещё надо суметь. То, что у Вас в голове сформировалось некое идеальное :) решение проблемы, и Вам резко стало скучно — это ещё не означает, что найденное решение реально будет работать, что оно учитывает все имеющиеся нюансы (когда пишешь код — почти всегда всплывают совершенно неожиданные проблемы, чаще мелочь, но бывают и очень серьёзные), и что Вы сможете не менее идеально реализовать его в коде — элегантно, просто, читабельно, гибко, эффективно, безопасно… и без тех самых сложных багов.
Фактически, умение именно написать код, а не решить задачу в уме, и есть программирование. Решение задачи в какой-то предметной области Вам может предоставить с самого начала специалист в этой предметной области, и Ваша задача, как программиста, это решение запрограммировать — корректно (т.е. без багов), эффективно и безопасно.
Да, сейчас этот подход почти не встречается (в реальном мире :)), поэтому программисту приходится разбираться с предметной областью заказчика, и самому искать решение его задач. Но это — не программирование. Это, скорее, работа (бизнес-)аналитика. А если предметная область это само программирование — тогда архитектора. К сожалению, если архитектор не пишет живой код, а только разрабатывает в уме архитектуру — он такого наразрабатывает, мама не горюй!
В общем, если идея писать код перестаёт вызывать энтузиазм — пора задуматься о смене профессии. Только в архитекторы не идите, пожалуйста. :)
Фактически, умение именно написать код, а не решить задачу в уме, и есть программирование. Решение задачи в какой-то предметной области Вам может предоставить с самого начала специалист в этой предметной области, и Ваша задача, как программиста, это решение запрограммировать — корректно (т.е. без багов), эффективно и безопасно.
Да, сейчас этот подход почти не встречается (в реальном мире :)), поэтому программисту приходится разбираться с предметной областью заказчика, и самому искать решение его задач. Но это — не программирование. Это, скорее, работа (бизнес-)аналитика. А если предметная область это само программирование — тогда архитектора. К сожалению, если архитектор не пишет живой код, а только разрабатывает в уме архитектуру — он такого наразрабатывает, мама не горюй!
В общем, если идея писать код перестаёт вызывать энтузиазм — пора задуматься о смене профессии. Только в архитекторы не идите, пожалуйста. :)
т.е. вы потенциально знаете как алгоритмизировать любую задачу? )
думаю это иллюзия. а те пути решения которые вам так легко видятся — носят скорее всего характер эдакого нечеткого архитектурного проектирования, причем очень далеки от того, что будет в финале.
с учетом конечно того, что задача должна быть исследовательская.
думаю это иллюзия. а те пути решения которые вам так легко видятся — носят скорее всего характер эдакого нечеткого архитектурного проектирования, причем очень далеки от того, что будет в финале.
с учетом конечно того, что задача должна быть исследовательская.
Исследовательские задачи, они интересны. Но их мало. Так получается что большая часть багов дает исследовательские задачи, для меня.
Мне нравиться строить лисапеды, писать всякие извращения; но «кушать» мне хочеться больше ;)
Мне нравиться строить лисапеды, писать всякие извращения; но «кушать» мне хочеться больше ;)
Вот расстрелял бы тех кто не умеет корпоративно кодить =) недавно был большой проект, взял программиста такого, быстро работает, результативно =) Ну а потом, он ушел. В его зоне лежал веб клиент, никто никогда туда не лез =) Разгребать запарились! В итоге чтобы проект сопровождать дальше и понимать что и как, сели и переписали все заново.
Любой хороший фрилансер понимает, что можно часть работы отдать другим фрилансерам, а себе оставить интересную задачу, а с не интересных получить процент.
Программирование — это искусство правильного ограничения абсолютной абстракции. (Из личных заметок)
Как и в любом другом искусстве предела совершенству нет=)
Как и в любом другом искусстве предела совершенству нет=)
а мне нравится решать нестандартные алгоритмические задачи и получать кайф от того, что я смог их решить.
Попробуйте новый язык программирования, новую платформу освоить, авось, и придумаете, чем себя занять :) Хотя, конечно, если все уже изучено, то тогда — увы и ах, придется вам самим придумать что-нибудь совсем новое. :)
//
А я, к примеру, в программировании люблю возможность писать код по-разному. Таким образом, появляется возможность возвращаться к уже написанному коду время от времени и каждый раз балдеть от того, что ты можешь еще и еще улучшить безопасность по отношению к типам, согласованность интерфейсов, сделать код более прозрачным или более универсальным.
Особенно полезным считаю разработку реюзабельного кода. Разработка библиотек, особенно с поддержкой концепции обобщенного программирования, — непростая и часто очень интересная задача.
//
А я, к примеру, в программировании люблю возможность писать код по-разному. Таким образом, появляется возможность возвращаться к уже написанному коду время от времени и каждый раз балдеть от того, что ты можешь еще и еще улучшить безопасность по отношению к типам, согласованность интерфейсов, сделать код более прозрачным или более универсальным.
Особенно полезным считаю разработку реюзабельного кода. Разработка библиотек, особенно с поддержкой концепции обобщенного программирования, — непростая и часто очень интересная задача.
возможность переписать код красиво для тебя в текущий момнет времени (а чувство прекрасного изменяться со временем, да) не всегда возможно. И часто глупо. Ну перепишешь ты этот кусок сейчас. А через 2 недели перепишешь еще, ибо чувство прекрасного измениться. Так и будешь ты его переписывать, не сделав людей счастливыми.
«еще те 5 штук до конца недели, а если пофиксишь » Эх хорошо бы )))))
Хорошо написано.
Но почему «Каждый баг — это research» а не к примеру «Каждый баг — это исследование»? К чему столько слов на английском явно не обусловленных контекстом?
Но почему «Каждый баг — это research» а не к примеру «Каждый баг — это исследование»? К чему столько слов на английском явно не обусловленных контекстом?
Когда хочется почувствовать себя ребенком — пишу игры.
Моя статья на эту же тему: Как я люблю программировать. trurl123.blogspot.ru/2012/10/blog-post.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
За что я люблю программирование