Все бы хорошо, смущает призыв отказаться от юнит-тестов, например, и подача этого как некой новой методологии проектирования и разработки. Но я это тоже третий (или больше?) раз пишу.
Ну, есть проекты, в которых изменение архитектуры — не такой уж затратный момент. В маленьких проектах даже лучше делать сразу некий прототип с минимальным проектированием (можно и по ходу разработки), с которым у заказчика будет возможность поиграться и, возможно, изменить требования, которые уже в свою очередь могут серьезно поменять получившуюся архитектуру.
Очевидно, что это произойдет раньше, чем если бы сначала все было детально запроектировано, потом реализовано, потом оттестировано и было бы показано заказчику, который внес бы небольшие изменения, которые бы поменяли архитектуру и т. д.
Также очевидно, что это экономит время, деньги и нервы как заказчика, так и разработчика.
К сожалению, не работал с InterfaceBuilder, но подозреваю, что как и все современные среды, представлять архитектуру он умеет в виде диаграммы классов (что является только частью документации), и то только настолько, насколько написано кода. Так что вначале разработки охватить весь проект целиком не сможем, а значит, не сможем понять, как можно распараллелить разработку, что можно отдать на аутсорс, в общем, не получится эффективно использовать имеющиеся ресурсы (если их больше одного-двух программистов).
Тесты — да, с ними надо будет разбираться. Но зато они _моментально_ отвечают на вопрос: а если я вот этот метод заставлю работать несколько иначе, что у нас сломается? А это очень ценно на этапе сопровождения.
Хотя еще раз повторюсь, на отдельных задачах и даже маленьких проектах на одного-двух человек без сопровождения и без проблем с кадрами такой подход вполне оправдывает себя.
Ну, проектирование, как самостоятельный этап, не для всякой задачи нужно — относительно маленькую и простую систему можно проектировать по ходу дела, и там описанный автором подход вполне себе применим (да и похожим образом такие проекты и делаются в большинстве случаев). И если развития продукта не планируется, и никто из команды не заболеет и не уволится, то ничего страшного не будет.
Еще раз, основные мысли статьи:
— отказываемся от написания юнит-тестов
— разрабатываем сверху вниз, продумывая архитектуру на этапе написания кода
— в качестве тестов на этапе продумывания интерфейса выступает компилятор/линкер
— в процессе разработки приложения не заморачиваемся архитектурными изысками, и пишем «как пишется», по возможности стараясь реализовывать похожие алгоритмы одинаково.
— при удобном случае одинаковые куски оборачиваем в классы/методы
— далее тесты становятся не нужны, т.к. мы помним архитектуру системы, а все ее компоненты реализуют элементарные операции, в тестировании не нуждающиеся.
Я правильно понял? Если так, то тут минимум забыли еще один важный этап — сопровождение, на котором написанные тесты и документированная архитектура ой как пригодятся.
Масштабы проекта тоже важны, т.к. что хорошо для пары-тройки человекомесяцов, не очень подходит для пяти человеко-лет и сильным распараллеливанием работ. Объяснять «почему» нужно?
Не, серьезно. Статья непонятна не из за уровня читателя. Уровень тут минимальный нужен, но вот врубиться в это…
Сбивают с толку:
а) заголовок (copy-paste традиционно имеет несколько другой смысл, нежели описываемый подход)
б) лирика, не имеющая отношения к основной мысли (история взаимоотношений с TDD тут несколько притянута)
в) недостаточно четко выраженная сама основная мысль (не сделан упор на то, как именно используется копипаста).
Как то в комментарии выше в двух строках понятней у вас получилось, может, и не нужно больше строк? ;-)
Это я уловил (несколько раз вдумчиво прочитав статью с начала до конца). Сам принцип далеко не нов, вполне себе обычная разработка «сверху вниз» с проектированием «по ходу дела» и забиванием на написание тестов. Где и как отражается архитектура (в коде или на диаграммах) — не принципиально.
Спорно тут то, что автор, не делая оговорок о масштабах и особенностях проектов, к которым это применимо, и не сообщая о возможных подводных камнях, призывает следовать данной методике. А самый существенный минус у нее в данном варианте — сложность сопровождения и модификации полученного кода.
А это смотря какая система, и какие там компоненты. Например, есть проекты, где стадия начального проектирования (на бумаге) таки важна и необходима — там, где важно в относительно короткие сроки (по сравнению со сроками на весь проект) определиться с примерной архитектурой и распараллелить разработку.
Более того, есть проекты, где не работает отказ от написания юнит-тестов, т.к. опять же есть поддержка (которой занимаются совсем другие люди обычно).
И если в случае (допустим) с игрушкой под консоли/мобильники жизненный цикл приложения заканчивается с печатью диска/отправкой операторам, то в корпоративных приложениях печать диска и внедрение решения — это далекая от завершения модификации продукта стадия.
Т. е. зачастую софт недостаточно написать и оттестировать, а его необходимо модифицировать множество раз на протяжении длительного времени (и силами разных разработчиков). Таким образом, один и тот же компонент будут изменять и доводить до совершенства разные люди и неограниченное количество раз.
А если компонент используется десятком других компонентов, то при его модификации (по вашей методике, т.е. забив на написание тестов) придется детально изучать работу этих компонентов (а то и большего количества, т.к. каждый из них тоже может использоваться другими). А вот если есть тесты — то все сильно проще.
Таким образом, описанный метод подходит при разработке сравнительно небольших систем, которые либо разрабатываются одним человеком, либо хорошо бьются на сравнительно небольшие куски, взаимодействие между которыми очевидно, и каждый такой кусок разрабатывается отдельным человеком (ну, например, графика, звук, физика, игровая механика, инструментарий в случае игрушек), не имеющих длительного периода сопровождения. Например, игры, приложения для мобильных платформ, небольшие сайты (с натягом, т.к. их сопровождать хотят обычно), ну и другие подобные.
Также не совсем понятен смысл всего текста: то расписываются прелести TDD (и далее следует призыв отказаться от него), то рассказывается о способе разработки архитектуры «сверху вниз» (который тоже не нов).
Паттерны проектирования нужны не для того, чтоб при решении задачи перерывать их список и пытаться найти наиболее подходящую комбинацию. Нужны они только в плане обучения (как у художников — гипсовые фигуры), их надо знать (не по названию, а по смыслу), и где надо — не изобретать велосипед.
Отказ от тдд и сохранение возможности безболезненного рефакторинга возможно, если рефакторингом занимается человек, который проектировал систему (ну или минимум знает ее досконально).
BTW, у вас во флешка на 7touchgroup.com/ баг (?) — попробуйте попереводить мышку с about на services и обратно.
Кстати, если при включении зажать ресет, то насколько я помню, там произойдет откат к заводским настройкам, и нормальная загрузка, которую можно прервать (передав Ctrl+C), и перепрошить (даже в случае глючной основной прошивки). Это есть и в оригинальном лоадере, и в лоадере от DD-WRT. Но вот если проблема с лоадером, то тут уже никак.
Ну, хз, сам не брикал (жалко было, потому 30-30-30 и прочее честно выдерживал), но судя по форумам и всяким гайдам народ достаточно часто их брикал.
А вот восстановить родную не получилось — при передаче Ctrl+C в редбут последний намертво вис.
Если на нем самом включать PPTP-клиент (для корбины и других подобных провайдеров), то работает очень плохо — жрет под 100% CPU, скорость около мегабита. Хотя РРТР не очень и на Linksys'е работает (если все по дефолту делать), та же фигня, только порядка 5Мбит/с. Если выставить для pptp/pptpd флажки sync, --sync и --nobuffer, и отключить все сжатия/шифрования — будет порядка 10Мбит на Линксисе, и, возможно, побыстрее на DIR-300 (не проверял).
Общее впечатление — сырая еще до безумия (смотрел последнюю preSP2). Откат на стандартную нетривиален, хотя возможен. Шансов брикнуть много как при переходе на DD-WRT, так и обратно.
Если PPTP поднимать на компе, то все ок, но тогда либо интернет только одному человеку доступен, либо надо отдельную станцию.
Да, кстати, есть готовая статья по настройке всего этого на DD-WRT — но кармы нет ;-)
Мы вроде как обсуждаем варианты регистрации в сервисах, которыми пользуются раз в год, и где взаимодействия пользователей не планируется. Форумы как то не сильно сюда подходят ;)
Это не нужно и даже вредно — стойкость LaRAb33 ниже, нежели просто случайный набор символов. Достаточно сгенерить пароль (из диапазона [a-zA-Z0-9]), отправить его на почту и авторизовать пользователя «навечно» (чтоб ему вообще не заморачиваться паролями/авторизациями). В большинстве таких случаев пользователь нажмет галку в браузере «сохранить пароль» — важность данных не ахти какая, да и заказывают в основном со своей машины (дома или в офисе), а продвинутые товарищи, которые парятся насчет безопасности всегда могут и пароль поменять, и нажать кнопку «выход».
А на форме регистрации/авторизации рядом с полем ввода пароля поместить ссылку «напомнить пароль», и при нажатии на нее отправлять пользователю письмо (на указанный e-mail) с новым паролем.
Ну вот, теперь сделали и электромеханический вокодер. Такой эффект уже сто лет как в поп-музыке используется, только в качестве несущего сигнала там обычно органы берут (зажал аккорд — и говори, не надо на каждый слог его по новой нажимать), получается такой «роботовый» голос =)
Чекбокс лишний 100%, а регистрация раздражает все равно фактом своего существования.
Имхо надо:
— Если в момент нажатия «оформить заказ» пользователь не залогинен, то отображаем форму из трех полей (почта, телефон и адрес доставки).
— Аяксом чекаем почту на предмет наличия в базе, если есть — отображаем поле с паролем, если ввели правильный пароль, то подставляем недостающие (т.е. незаполненные) данные.
— После отправки смотрим — регистрация/нет (почта уже была зарегистрирована/нет), если регистрация — создаем учетку, генерим пароль, авторизуем пользователя «вечно», отправляем ему письмо с паролем. Если почта не была заполнена — не регистрируем, но заказ оформляем.
Алгоритм даунгрейдится до версии без Javascript'а — та же форма, только все поля отображаются и все проверки происходят только на сервере, при ошибке отображается эта же форма с заполненными данными (кроме пароля, конечно).
Очевидно, что это произойдет раньше, чем если бы сначала все было детально запроектировано, потом реализовано, потом оттестировано и было бы показано заказчику, который внес бы небольшие изменения, которые бы поменяли архитектуру и т. д.
Также очевидно, что это экономит время, деньги и нервы как заказчика, так и разработчика.
Что тут плохого?
Тесты — да, с ними надо будет разбираться. Но зато они _моментально_ отвечают на вопрос: а если я вот этот метод заставлю работать несколько иначе, что у нас сломается? А это очень ценно на этапе сопровождения.
Хотя еще раз повторюсь, на отдельных задачах и даже маленьких проектах на одного-двух человек без сопровождения и без проблем с кадрами такой подход вполне оправдывает себя.
— отказываемся от написания юнит-тестов
— разрабатываем сверху вниз, продумывая архитектуру на этапе написания кода
— в качестве тестов на этапе продумывания интерфейса выступает компилятор/линкер
— в процессе разработки приложения не заморачиваемся архитектурными изысками, и пишем «как пишется», по возможности стараясь реализовывать похожие алгоритмы одинаково.
— при удобном случае одинаковые куски оборачиваем в классы/методы
— далее тесты становятся не нужны, т.к. мы помним архитектуру системы, а все ее компоненты реализуют элементарные операции, в тестировании не нуждающиеся.
Я правильно понял? Если так, то тут минимум забыли еще один важный этап — сопровождение, на котором написанные тесты и документированная архитектура ой как пригодятся.
Масштабы проекта тоже важны, т.к. что хорошо для пары-тройки человекомесяцов, не очень подходит для пяти человеко-лет и сильным распараллеливанием работ. Объяснять «почему» нужно?
Сбивают с толку:
а) заголовок (copy-paste традиционно имеет несколько другой смысл, нежели описываемый подход)
б) лирика, не имеющая отношения к основной мысли (история взаимоотношений с TDD тут несколько притянута)
в) недостаточно четко выраженная сама основная мысль (не сделан упор на то, как именно используется копипаста).
Как то в комментарии выше в двух строках понятней у вас получилось, может, и не нужно больше строк? ;-)
А изо всех сил сводить задачу к набору паттернов (чтоб все стандартно было) не стоит.
Спорно тут то, что автор, не делая оговорок о масштабах и особенностях проектов, к которым это применимо, и не сообщая о возможных подводных камнях, призывает следовать данной методике. А самый существенный минус у нее в данном варианте — сложность сопровождения и модификации полученного кода.
Более того, есть проекты, где не работает отказ от написания юнит-тестов, т.к. опять же есть поддержка (которой занимаются совсем другие люди обычно).
И если в случае (допустим) с игрушкой под консоли/мобильники жизненный цикл приложения заканчивается с печатью диска/отправкой операторам, то в корпоративных приложениях печать диска и внедрение решения — это далекая от завершения модификации продукта стадия.
Т. е. зачастую софт недостаточно написать и оттестировать, а его необходимо модифицировать множество раз на протяжении длительного времени (и силами разных разработчиков). Таким образом, один и тот же компонент будут изменять и доводить до совершенства разные люди и неограниченное количество раз.
А если компонент используется десятком других компонентов, то при его модификации (по вашей методике, т.е. забив на написание тестов) придется детально изучать работу этих компонентов (а то и большего количества, т.к. каждый из них тоже может использоваться другими). А вот если есть тесты — то все сильно проще.
Таким образом, описанный метод подходит при разработке сравнительно небольших систем, которые либо разрабатываются одним человеком, либо хорошо бьются на сравнительно небольшие куски, взаимодействие между которыми очевидно, и каждый такой кусок разрабатывается отдельным человеком (ну, например, графика, звук, физика, игровая механика, инструментарий в случае игрушек), не имеющих длительного периода сопровождения. Например, игры, приложения для мобильных платформ, небольшие сайты (с натягом, т.к. их сопровождать хотят обычно), ну и другие подобные.
Также не совсем понятен смысл всего текста: то расписываются прелести TDD (и далее следует призыв отказаться от него), то рассказывается о способе разработки архитектуры «сверху вниз» (который тоже не нов).
Паттерны проектирования нужны не для того, чтоб при решении задачи перерывать их список и пытаться найти наиболее подходящую комбинацию. Нужны они только в плане обучения (как у художников — гипсовые фигуры), их надо знать (не по названию, а по смыслу), и где надо — не изобретать велосипед.
Отказ от тдд и сохранение возможности безболезненного рефакторинга возможно, если рефакторингом занимается человек, который проектировал систему (ну или минимум знает ее досконально).
BTW, у вас во флешка на 7touchgroup.com/ баг (?) — попробуйте попереводить мышку с about на services и обратно.
А вот восстановить родную не получилось — при передаче Ctrl+C в редбут последний намертво вис.
Общее впечатление — сырая еще до безумия (смотрел последнюю preSP2). Откат на стандартную нетривиален, хотя возможен. Шансов брикнуть много как при переходе на DD-WRT, так и обратно.
Если PPTP поднимать на компе, то все ок, но тогда либо интернет только одному человеку доступен, либо надо отдельную станцию.
Да, кстати, есть готовая статья по настройке всего этого на DD-WRT — но кармы нет ;-)
А на форме регистрации/авторизации рядом с полем ввода пароля поместить ссылку «напомнить пароль», и при нажатии на нее отправлять пользователю письмо (на указанный e-mail) с новым паролем.
Имхо надо:
— Если в момент нажатия «оформить заказ» пользователь не залогинен, то отображаем форму из трех полей (почта, телефон и адрес доставки).
— Аяксом чекаем почту на предмет наличия в базе, если есть — отображаем поле с паролем, если ввели правильный пароль, то подставляем недостающие (т.е. незаполненные) данные.
— После отправки смотрим — регистрация/нет (почта уже была зарегистрирована/нет), если регистрация — создаем учетку, генерим пароль, авторизуем пользователя «вечно», отправляем ему письмо с паролем. Если почта не была заполнена — не регистрируем, но заказ оформляем.
Алгоритм даунгрейдится до версии без Javascript'а — та же форма, только все поля отображаются и все проверки происходят только на сервере, при ошибке отображается эта же форма с заполненными данными (кроме пароля, конечно).
Электронные кубики =)