Comments 66
Очень хорошая статья и очень неплохой перевод. Спасибо.
Подпишусь под каждым словом! Спасибо за отличное изложение.
Очень интересно написано. Однажды мне сказал бывший директор, что нельзя вечно сидеть на снежной вершине горы в одиночестве и медитировать. И лично мое мнение, это то что «мыслитель» и «творец» в человеке должны жить в гармонии, все должно быть в меру и это будет настоящий дзен программист постигший все вершины.
у этого знака все ответы
у этого знака все ответы
Если просто начать копать, то методом последовательных приближений, скатишься на дно потенциала сложности. Крутые стенки дна уже не позволят тебе легко из него выскочить.
Если потратить немного времени на изыскания, то можно сначала нащупать оптимальную точку приложения усилий, и уже после этого начинать копать.
Либо нужно делать свои продукты так, чтобы избегать крутых стенок у ямы, так, чтобы в любой момент можно было свернуть в сторону. Собственно, все ООП и прочие способы блочного кодинга именно для этого и нужны.
Если потратить немного времени на изыскания, то можно сначала нащупать оптимальную точку приложения усилий, и уже после этого начинать копать.
Либо нужно делать свои продукты так, чтобы избегать крутых стенок у ямы, так, чтобы в любой момент можно было свернуть в сторону. Собственно, все ООП и прочие способы блочного кодинга именно для этого и нужны.
Весьма важное уточнение, спасибо.
Сам сейчас нахожусь в подобной ситуации, когда костыли от предудыщих решений проблем мешают реализовать новые идеи — приходится много переделывать…
Но не будь текущего кода — не появились бы и эти новые идеи, как заменить его на более совершенный. Так что и кодить в поиске решения наощупь надо, и теорию прорабатывать предварительно тоже надо. Баланс необходим, как и везде )
Сам сейчас нахожусь в подобной ситуации, когда костыли от предудыщих решений проблем мешают реализовать новые идеи — приходится много переделывать…
Но не будь текущего кода — не появились бы и эти новые идеи, как заменить его на более совершенный. Так что и кодить в поиске решения наощупь надо, и теорию прорабатывать предварительно тоже надо. Баланс необходим, как и везде )
Автор, иди клепай горшки дальше, а то теоритизировать и иделы строить тут вздумал.
Первое мое приложение для Android я начал писать по принципу «чтобы работало», я написал его быстро, хоть и писал на java впервые, все прекрасно работало, получилось около 5 тыс строк кода и всего 5-6 выполняемых операций. Затем я начал дополнять приложение новыми функциями и по мере надобности переписывать, и оптимизировать код. Все шло достаточно быстро и вот моя программа уже выполняла более 60 операций и имеела большое количество настроек, а код при этом умещался в 700 строк.
Но потом произошло страшное, я прочитал кучу теории о том как надо и как правильно писать приложения под Android, о том какими они должны быть внутри и снаружи, ровно в этот момент развитие приложения остановилось и теперь мне очень сложно заставить себя начать дальнейшее его развитие.
Согласен с автором, на все 100%
Но потом произошло страшное, я прочитал кучу теории о том как надо и как правильно писать приложения под Android, о том какими они должны быть внутри и снаружи, ровно в этот момент развитие приложения остановилось и теперь мне очень сложно заставить себя начать дальнейшее его развитие.
Согласен с автором, на все 100%
Наша математичка всегда говорила, задавая 40 интегралов на дом, что количество рано или поздно переходит в качество. Очень мудрая женщина, кстати говоря.
… теперь когда я своим студентам задаю 40 и больше интегралов — говорю им то же самое. Нужно только придумать еще пару фраз, чтобы они еще и решали их дома.
Количество никогда не переходит в качество. Какое бы количество дерьма у вас не было, в мёд оно не перейдет. Оригинал звучал примерно так (по памяти): количесвенные измененеия, при определенных условиях *могут* переходить в качественные.
Количество никогда...
количественные измененеия, при определенных условиях *могут*…
Хорошо, что Вы заметили ошибку с кванторами у оппонента. Жаль, что не заметили у себя.
количественные измененеия, при определенных условиях *могут*…
Хорошо, что Вы заметили ошибку с кванторами у оппонента. Жаль, что не заметили у себя.
Ошибки нет. Я говорю в первом предложении об абсолютных величинах, а во втором об изменениях. Вы даже сами их выделили, «количество» vs «количественные изменения».
Количество всегда переходит в другое качество.
Количество абсолютно всегда переходит в качество, ибо закон сие есть. Вопрос лишь в критической величине этого количества и неизвестности получаемого качества. Ваш пример: собирая говно дома мед конечно не получите, однако в определенный момент в дом войти не получится, или к примеру крышу у него сорвет.
Количественные изменения == изменения в количестве, что и имеют в виду, говоря «количество».
Не соглашусь — большое количество дерьма можно загнать как удобрение (или в биореактор на метан:)). Переход количества в качество — это скорее психологический феномен, нежели физический там или математический. Хотя в математике примеры есть такого перехода — счетные и континуальные множества например обладают разными качествами.
Зато вы научитесь превосходно делать дерьмо, намного лучше чем те кто делает мёд. А кто знает, может в вашей задаче вам нужно 100 кг дерьма а не ложка мёда?
К Не бойтесь сделать неаккуратно в первый раз. и Не бойтесь переписывать код. можно добавить Делайте прототипы (которые точно не пойдут в production). Чтобы ещё больше снизить страхи можно делать прототип, на языке который не соответствует ТЗ. Иногда, когда требования не сформулированы ещё толком и подводные камни не ясны, я делаю прототип на RoR (очень удобны для этого), а после утверждения и нащупывания камней, пишу на PHP. Код, который писал на рельсах не жалко «выбрасывать», он с самого начала был для этого предназначен.
Владимир, а можете статью написать об этом? Было бы интересно почитать.
А о чём собственно? Каких-то общих принципов нет вроде, прототипирование по сути является итеративным процессом сбора требований и формированию подробного ТЗ по ним, плюс проверка «на прочность» выбранного интуитивно на первом этапе разделения ответственностей между сущностями приложения. В общем слабоформализуемый процесс, по-моему, чтобы описать его в общем. Конкретные языки или фреймворки особого значения не имеют, разве что должны следовать одной парадигме (ООП в частности) и использовать схожую архитектуру (MVC). А так процесс можно считать комбинацией agile методологий и водопада — по первой создаем прототип, до его окончательного утверждения заказчиком, а по второй релизим продукт.
Причина, думаю, в том, что сделав в первый раз и получив определенный опыт, в следующий раз хочется нового опыта. Начинаешь задумываться, а как лучше, универсальнее, эстетичнее. Вылезают такие вещи как архитектура приложения, шаблоны, абстракции, фреймворки. А реальный результат затягивается. Затем начинаешь применять различные теории, парадигмы, методологии типа TDD, etc… Результат становится практически недостижим, потому что ориентация уже становится на сам процесс, а не на результат. Потом становится мало языка программирования для элегантного выражения всей полноты мыслей. Наиболее талантливые изобретают свой язык, а другие начинают использовать что-то экзотическое. И под конец заканчиваешь карьеру как полный теоретик парадигм и импотент в продуктивном плане. Отсюда, кстати, идет извечная борьба между тем как «правильно» и тем как «удобно». Излишнее теоретизирование и повсеместное насаждение шаблонов и парадигм — одна из современных проблем IT.
Поэтому главный рецепт — не терять цель из виду, быть ориентированным на результат, а программирование рассматривать как средство достижения результата.
Поэтому главный рецепт — не терять цель из виду, быть ориентированным на результат, а программирование рассматривать как средство достижения результата.
Все правильно.
Но далеко не у всех цель сделать как можно проще с меньшими затратами времени. У некоторых цель выжать как можно больше денег с заказчика и сделать сложный продукт, который кроме них никто поддерживать не сможет.
Но далеко не у всех цель сделать как можно проще с меньшими затратами времени. У некоторых цель выжать как можно больше денег с заказчика и сделать сложный продукт, который кроме них никто поддерживать не сможет.
Надеюсь, скоро у них закончатся заказчики.
Разные цели, вернее подцели, могут быть. Например растянуть разработку по времени, если других заказов не предвидится. Или сделать хоть одну работу достойную упоминания в портфолио. Или изучить новую технологию, язык, фреймворк и т. п. за счёт заказчика. Много ещё можно перечислить мотивов по которым разработчик не хочет (иной раз на подсознательном уровне) сделать как можно проще с меньшими затратами времени. Особенно учитывая, что как можно проще зачастую сложно отделить от говнокода.
По большей части соглашусь с автором статьи. Однако, как выше написали, стоит не просто сразу “набрасываться“, а начинать с прототипа. Если речь о коммерческой разработке, то потенциальные ошибки в начале могут очень дорого обойтись в конце. Стоит с начала все-таки хоть немного подумать над проектом, в том числе задавая вопросы “Как?“.
Если речь о разработке для себя или тренировке в освоении новой технологии, то конечно стоит полностью следоавать подходу автора.
Если речь о разработке для себя или тренировке в освоении новой технологии, то конечно стоит полностью следоавать подходу автора.
Я предлагаю лишь стараться искать решение оптимальное на 90 процентов, зная, что можно будет вновь вернуться к проблеме, если вам действительно нужно будет найти лучшее решение
Как быть, если принятое решение будет невозможно изменить впоследствии? Например, если речь идет о неправильно выбранной архитектуре.
Как быть, если принятое решение будет невозможно изменить впоследствии? Например, если речь идет о неправильно выбранной архитектуре.
Архитектуру, правильную на 90%, уже не так сложно поменять, а практика показывает, что «идеально» выбранная архитектура, вдруг тоже становится неподходящей, когда меняются требования.
Тогда тем более верно. Надо написать проект архитектуры — и потом рассуждать, чем хорош уже написанный проект, а не каким должен быть проект идеальный. В первом случае за 2-3 итерации у вас может уже появиться готовый проект, а во втором вы станете обладателем толпы отговорок, почему ничего делать не надо.
Не вам всем точно книгу надо «Как перестать писать статьи и начать программировать».
Очень хорошо написано, вот только не пойму как TDD сюда привязать. С одной стророны хорошо подходит, ели код затестирован то изменяй его сколько влезет. А с другой стороны, разработка тестов столько времени занимает, а при TDD с помощью тестов вообще, так сказать, концепность закладывается.
Как вы считаете, нужны тесты, или это таки тормоза оптимальной разработки?
Как вы считаете, нужны тесты, или это таки тормоза оптимальной разработки?
Очень сложный вопрос. Лично я смотрю по задаче. Ключевые места архитектуры тестируются достаточно тщательно, а общая логика — весьма поверхностно. На моей практике тесты всегда не успевают за динамикой проекта, и просто требуют обновления, вместо того, чтобы давать уверенность. В любом случае нельзя считать, что корректный запуск тестов означает правильность очередного изменения.
Как минимум первые четыре совета хорошо ложатся на TDD, имхо:
Набрасывайтесь, прежде чем осмотреться — делаем то, что знаем как сделать, подставляя моки и стабы в тех местах где (пока) не знаем.
Перестаньте волноваться о том, как. — тестами мы изолируем, что делает код от того, как он это делает.
Не бойтесь сделать неаккуратно в первый раз. — изолировав мы абстрагируемся от реализации, она может быть неаккуратной, но мы её всегда можем поправить
Не бойтесь переписывать код. — тесты дают нам уверенность, что переписывание кода не изменит его (документированной) функциональности.
Набрасывайтесь, прежде чем осмотреться — делаем то, что знаем как сделать, подставляя моки и стабы в тех местах где (пока) не знаем.
Перестаньте волноваться о том, как. — тестами мы изолируем, что делает код от того, как он это делает.
Не бойтесь сделать неаккуратно в первый раз. — изолировав мы абстрагируемся от реализации, она может быть неаккуратной, но мы её всегда можем поправить
Не бойтесь переписывать код. — тесты дают нам уверенность, что переписывание кода не изменит его (документированной) функциональности.
Сильно от задачи зависит. Вот вам мысленный эксперимент:
Нужно написать индекс для какой-то кастомной базы данных. Одному разработчику даем несколько попыток, второму — время и книжку Кормена по структурам и алгоритмам.
Я уверен, что последний справится лучше.
Нужно написать индекс для какой-то кастомной базы данных. Одному разработчику даем несколько попыток, второму — время и книжку Кормена по структурам и алгоритмам.
Я уверен, что последний справится лучше.
Хорошо напишет индекс только тот у кого будет реальная база с реальными пользовательскими данными, совсем в вакууме его написать не выйдет. А пользу книжек никто не оспаривал, тем более в таких тонких вещах как базы данных, или алгоритмы.
Но если тот, кто напишет быстрее, напишет что-то, что работает хоть как-то, то вокруг этого можно уже состряпать презентацию и выбить кусок финансирования на проект в целом. К этому времени как раз уже подоспеет качественная реализация.
Вывод: надо иметь как рвущихся в бой не сильно опытных разработчиков, так и умудренных опытом, и конечно же, так сказать, средний класс, который уже не так богат объемом но и уже поднаторел в качестве.
Вывод: надо иметь как рвущихся в бой не сильно опытных разработчиков, так и умудренных опытом, и конечно же, так сказать, средний класс, который уже не так богат объемом но и уже поднаторел в качестве.
С чего-то всегда надо начать и наскок — довольно хороший вариант. Однако от теории не убежишь все равно. Согласен с автором выше, что должен быть баланс.
Если бы не было паттернов и стандартов, то сопровождение кода превратилось бы в сущий ад. Особенно при работе в команде.
Да и вообще, лучше немного поковыряться проблему, потом сесть подумать и уже начинать писать как надо.
Если бы не было паттернов и стандартов, то сопровождение кода превратилось бы в сущий ад. Особенно при работе в команде.
Да и вообще, лучше немного поковыряться проблему, потом сесть подумать и уже начинать писать как надо.
Если бы дети сначала учились читать, то они бы потом не смогли научиться ходить.
Хороший пример — KDE.
Выход KDE4 был откровенным провалом, но она была построена на новой архитектуре, все было недопилено, но продумано, и вот прошло несколько лет — GNOME 3 проходит то же самое, а у KDE все уже сделано, осталось только тихо и спокойно фиксить мелкие баги, набирая при этом тонны новых юзеров каждый день.
Выход KDE4 был откровенным провалом, но она была построена на новой архитектуре, все было недопилено, но продумано, и вот прошло несколько лет — GNOME 3 проходит то же самое, а у KDE все уже сделано, осталось только тихо и спокойно фиксить мелкие баги, набирая при этом тонны новых юзеров каждый день.
В курсе Human-Computer Interaction на courcera рассказывали про эксперимент с рисованием баннеров или чего-то такого вместо горшков. Результат аналогичный.
Я очень надеюсь, что военный, медицинский, банковский и транспортный софт пишут «непродуктивные» программисты, которые много думают, прежде чем что-то сделать.
Все что касается чего-то государственного, исходит из других критериев: критерий вины.
Ты должен написать так, чтобы ты не оказался виноватым. Это не обязательно ведет к качеству.
Ты должен написать так, чтобы ты не оказался виноватым. Это не обязательно ведет к качеству.
за другие виды софта я отвечать не буду, но часть пограничного и военного софта пишут студенты в НИИшках в качестве первой работы (сам писал), и еще часть — срочники (друг был свидетелем). Но да, наверное, где-нибудь существуют много думающие боевые программисты. Российский государственный медицинский софт — я не советую вам много об этом думать. Ну а у финансистов всё хорошо, да.
В этом софте важнее тестирование, чем программирование.
Считаю, что в теме можно смело убрать слова «разработка» и «ПО», с точки зрения сисадмина полностью поддерживаю и соглашаюсь с приведенным подходом.
Если горшки принимают по весу — я бы слепил один большущий кусок грязи и назвал его горшком. Если по количеству — много маленьких кусочков грязи. Без контроля качества никуда, ибо приемные показатели оптимизируются в ущерб всему остальному.
Нужна и теория и практика. Я знаю пару человек, которые очень любят изучать всё. Функциональную парадигму вдоль и поперек. Десятки языков, теории. На каждом могут программировать.
И один из них мне жаловался, что он завидует профессионалам в программировании. Нет, он работает программистом, это не хобби. Но тем не менее, жалуется, что не может создать что-то сложное.
С другой стороны, вижу намного чаще и обратную ситуацию: говнокодеры. Это люди, которые пишут не думая. Тонны кода пишут, а багов столько — что лучше бы не писали. И проблема их не в том, что они плохо соображают. А в том, что они не знают, что код может быть лучше.
Думаю, тут проблема, которая в статье описана, немного не так моделируется. Скоростью возможно и можно слепить горшок. Но программирование немного сложнее. Предлагаю такую модель. Человек не может одновременно концентрироваться на многих объектах. Допустим, может только на 5. Таким образом ему надо доводить работу до автоматизма. Именно кодированием, т.е. писать и читать код, пока эти навыки не уйдут в подкорку. Далее, приступать к изучению новых знаний.
Когда будущий программист только начинает учиться, изучая циклы, ветвления, он не сможет понять, как писать автоматический тест. Пусть наработает начальные навыки программирования. И так все время. Придет время изучать ООП. Всё это надо делать по очереди и отрабатывая обязательно кодированием.
При изучении ООП и паттернов, учащийся обязательно попадает в ловушку: сам способ обучения предлагает сразу решения. Поэтому учащийся концентрируется на том, чтобы сразу для любой задачи найти «красивое решение». Это неизбежный этап. Сопоставление задачи с уже решенными кем-то примерами и паттернами. Это помогает систематизировать знания, помогает набить руку на паттернах.
Тут пришло время поизучать функциональное программирование. Взглянуть иначе на программирование, на паттерны и рефакторинг.
И также — ТДД. Вот как раз оно и заставляет отказываться от паттернов и набрасываться на код. Здесь человек уже настолько привык к языку программирования, что больше ему ничего не нужно. Не нужны паттерны, не нужны диаграммы.
Как-то когда я был давно совсем маленьким, гладил рубашку. Никак не мог это сделать, расправлял ее, но не мог, где-то сминалась. Отец сказал: цель — чтобы утюг помещался и было еще немного места. Тебе не надо идеально расправлять. И тогда у меня начало получаться.
Необычный, конечно, пример. Но из жизни и близкий.
Вам не надо код представлять весь. Это нарушение инкапсуляции. Надо научиться работать с кодом на ограниченном участке. Видеть, что в нем не так, даже если вы всего не знаете о структуре. И это повышает и производительность и качество. Потому как качество кода в целом прямо зависит от качества его частей.
Так, сумбурно описал то, к чему вы пришли.
И один из них мне жаловался, что он завидует профессионалам в программировании. Нет, он работает программистом, это не хобби. Но тем не менее, жалуется, что не может создать что-то сложное.
С другой стороны, вижу намного чаще и обратную ситуацию: говнокодеры. Это люди, которые пишут не думая. Тонны кода пишут, а багов столько — что лучше бы не писали. И проблема их не в том, что они плохо соображают. А в том, что они не знают, что код может быть лучше.
Думаю, тут проблема, которая в статье описана, немного не так моделируется. Скоростью возможно и можно слепить горшок. Но программирование немного сложнее. Предлагаю такую модель. Человек не может одновременно концентрироваться на многих объектах. Допустим, может только на 5. Таким образом ему надо доводить работу до автоматизма. Именно кодированием, т.е. писать и читать код, пока эти навыки не уйдут в подкорку. Далее, приступать к изучению новых знаний.
Когда будущий программист только начинает учиться, изучая циклы, ветвления, он не сможет понять, как писать автоматический тест. Пусть наработает начальные навыки программирования. И так все время. Придет время изучать ООП. Всё это надо делать по очереди и отрабатывая обязательно кодированием.
При изучении ООП и паттернов, учащийся обязательно попадает в ловушку: сам способ обучения предлагает сразу решения. Поэтому учащийся концентрируется на том, чтобы сразу для любой задачи найти «красивое решение». Это неизбежный этап. Сопоставление задачи с уже решенными кем-то примерами и паттернами. Это помогает систематизировать знания, помогает набить руку на паттернах.
Тут пришло время поизучать функциональное программирование. Взглянуть иначе на программирование, на паттерны и рефакторинг.
И также — ТДД. Вот как раз оно и заставляет отказываться от паттернов и набрасываться на код. Здесь человек уже настолько привык к языку программирования, что больше ему ничего не нужно. Не нужны паттерны, не нужны диаграммы.
Как-то когда я был давно совсем маленьким, гладил рубашку. Никак не мог это сделать, расправлял ее, но не мог, где-то сминалась. Отец сказал: цель — чтобы утюг помещался и было еще немного места. Тебе не надо идеально расправлять. И тогда у меня начало получаться.
Необычный, конечно, пример. Но из жизни и близкий.
Вам не надо код представлять весь. Это нарушение инкапсуляции. Надо научиться работать с кодом на ограниченном участке. Видеть, что в нем не так, даже если вы всего не знаете о структуре. И это повышает и производительность и качество. Потому как качество кода в целом прямо зависит от качества его частей.
Так, сумбурно описал то, к чему вы пришли.
У меня проблем схожего толка. В голову приходит мысль о проекте или модуле, после дня продумывания я вижу столько деталей и проблем, что опускаются руки. С другой стороны постоянно наблюдаю, как неопытные группы, не особо вникая в мелочи, бросаются на амбразуру… и чуда не случается, они вязнут в достаточно предсказуемых местах, но по факту создается чуть больше. Х/з кто тут прав и что с этим делать.
Лучшее враг хорошего!
Sign up to leave a comment.
Когда быть хорошим плохо