Мені просто при прийомі на роботу задали зробити гостьову книгу. Потрібно було зробити тільки можливість додавання, видалення і редагування записів. Я зробив це все компактно майже в одному файлі. Коли подивилися мою роботу, то сказали, що немає поділу логіки та інтерфейсу а також не використовується ООП. Ось у мене і постало питання, чи потрібно в елементарних вещях використовувати поділ логіки. До речі з приводу ООП теж стало цікаво. Я думав що в такій роботі немає сенсу використовувати ООП. - dima-opr 24 Лютого '12 в 12:09
Потрібно, в першу чергу, ТЗ. Де будуть прописані і вимоги до функціонала і вимоги до зовнішнього вигляду, і вимоги до архітектури, і, якщо вони є - вимоги до коду. При співбесіді, звичайно, можна все зробити НЕ письмово, а усно, але завдання повинно бути явно детальніше «зроби нам гостевушку». Мабуть, при співбесіді варто було поставити питання «а що ви хочете отримати, і на що хочете подивитися?» А ООП та інше - це вже питання другорядне. Є у замовника вимоги або побажання по архітектурі - тоді має значення. Ні - тоді все визначається тільки, еее, думкою розробника. - drdaeman 25 Лютого '12 в 0:40
Ви маєте рацію, але зі свого боку. Роботодавець же хотів зрозуміти (оцінити) інше.
Не пам'ятаю хто (Ф. Брукс?), Написав, що програми діляться на 3 типи. Зубочистка (пишемо, використовуємо, викидаємо). Молоток (пишемо, довго використовуємо, не змінюємо). Хмарочос (пишемо, використовуємо, змінюємо, використовуємо, змінюємо.).
Від Вас хотіли маааленький небоскребчік (це для його життєвого циклу важливо ООП і модні шаблони проектування), а Ви їм молоточок (або зубочистку).
А ще знадобляться тести (TDD адже наше все), профайлинг, можливості з масштабування, документація (і розробника і користувача), пакетування для зручності деплоймента і так далі і так далі, див. Будь-який довгий список best practices. Хід думок розумієте? І, в результаті, таким легким рухом думки, завдання по створенню гостевушкі на «покажи-і-викинь» (пів-години з перервою на чай) переходить в роботу зі створення сферичної системи в вакуумі, якою можна займатися дуже довго. Тільки, все ж, питання - «а чи треба?» - варто підняти заздалегідь, до того, як приймається за роботу. - drdaeman 25 Лютого '12 в 0:51
@drdaeman - до чого такі крайнощі? О так, без TDD написати гостьову ніяк, ви що не в настрої прокинулися. DDD - Zowie 25 Лютого '12 о 8:13
відповідь дан 23 Лютого '12 о 10:20
Мені хтось казав, що MVC використовується тільки для двигунів і великих сайтів. Або для найпростіших він теж підійде? - dima-opr 23 Лютого '12 о 14:48
Так, цілком. MVC це просто підхід (патерн) до програмування. Тобто в разі поділу моделі і контролера, постаратися що-б все sql запити були в одному місці, а звернення до бази даних йшло через якісь методи (функції) моделі. - chernomyrdin 23 Лютого '12 о 19:18
Pavleman: згоден, написати свій (може навіть і не мікро) фреймворк - на мій погляд, найкращий спосіб зрозуміти, як правильно треба працювати з іншими фреймворками. Правда, цей спосіб вимагає більше часу, ніж просто використання готового фреймворку, і підходить, якщо в майбутньому дійсно буде цікаво всім цим займатися. PS. А як тут ники виділяти відповідальний? - Drakmail 23 Лютого '12 о 22:53