Максим Гаврилов

Я бы начал разговор с менеджмента. Конечно git хорошая, полезная штука, но тем не менее git это система контроля версиями в первую очередь, а потом уже стоит говорить что при разработке командой контроль получается у разного программиста своя версия и дабы кто не слил все свои наработки на dev сервер которые заменят разработки соседа который вылил все часом раньше. Можно даже сказать что гит не заменим, но также с гитом можно работать и при одиночной работе и в этом он тоже очень хорошо поможет контролировать процесс заливки файл на сервер и внесение изменений в файлы. Поэтому хочу также сказать что внедрение одного гита конечно упростит работу, но не так что все станет кул.

Говоря о менеджменте командной разработки можно говорить о том что должен быть тим-лид (идейный вдохновитель проекта) который будет нести ответственность за его реализацию, что должен быть менеджер проектов в проекте который будет переводить с языка клиента на язык тим-лида потом объединять мнения тим-лида с мнением клиента и выписывать user-story для программиста. Однако и многое другое сказано в описании методологий командной разработки используя гибкую систему Agile с методологиями Scrum, Kanban. Думаю это то, что надо изучать для орагнизации командной работы над проектом. Тех. сторона (git, jira) процесса тоже важна, но если организация будет успешно выполнять проекты используя ftp и при этом не будет вопросов вроде ты заменил мои новые файлы на свои, а на сервере они были в единственном виде. И также не будет вопросов о безопасности где кто-то с ftp сольет файлы себе на флешку и уташит домой то никто из клиентов против не будет. А если будет методология водопад вместо Agile то клиент может пойти в другую контору с Agile потому что это реальный бонус для клиента и разработчиков.

Если уж совсем все хреново то как крайний вариант можно нанять опытного тим-лида с опытным менеджером проектов которые наладят весь процесс Agile с методологиями Scrum, Kanban для вас.

P.S. мы тоже на работе используем NetBeans но вместо ftp - git.

Ну как тебе сказать?! Сначала бизнес логика, потом предметная область, потом реализация предметной области в классах (ER диаграмма) что даст представление о БД которая разрабатывается после и на основе предметной области. Далее мигрируем диаграмму БД в код для конкретной СУБД. потом классы предметной области дополняются функциональностью и параллельно разрабатывается визуализация (фронт-энд). Потом наступает момент интеграции где предметная область интегрируется с БД и фронт-энд интегрируется с бэк-эндом и все уходит на тестирование. Как правило это все разрабатывается в один момент времени потому что работает команда, а если же трудишься и стараешься сам, то надо распределять время и заниматься часть дня тем, часть дня сем, и еще часть дня вот этим и так по кругу стремясь использовать спиральный метод разработки ПО с принципами Agile. Водопад не рекомендую.

Массив в БД? А как же нормальные формы?! Наверное надо менять архитектуру

Подожду пока свой код покажешь :)!

Мне больше нравятся задания типа: сделать телефонную книгу, набросайте небольшую доску объявлений и т. п.

Но задание подобное вашему тоже имеет место быть. Кроме того: не факт что свой гит смотрел кто-то из разработчиков, может быть это был HR мэнэджер для которого код ничего не значит, а выполненное тестовое задание это кул. Помните об HR.

Лучше не терять соединение:

$this -> pdo = new \PDO(
                "mysql:host=" . $this -> DB_HOST . " ;dbname=" . $this -> DB_NAME . ";", 
                $this -> DB_USER, 
                $this -> DB_PW,
                array(\PDO::ATTR_PERSISTENT => true)
            );

Думаю что курсы предполагают домашние задания и слушатели тех курсов будут заниматься по 2 часа ежедневно, но слушать лекции только 2 часа 2 раза в неделю. Практика тоже важна в обучении.

Прямой ответ на вопрос: да, можно. Будут ли полезны курсы? Понятия не имею.

chmod 700 filename

Вредно ли пользоваться калькулятором? Если вы школьник 1-9 классов - да вредно, если вы бухгалтер с 20 летним стажем - нет не вредно, если кассир в магазине - нет не вредно и т.д. Также и с программированием. Вам трудно будет запомнить структуру оператора for если вы новичок и постоянно пользуетесь копипастой, а если вы программист левела сеньор то копипаста оператора цикла (уверен что ни один сеньор так делать не будет) из соседнего класса вам сэкономит пору долей секунды которые будут направленны на размышление об алгоритме и т.д.

file_put_contents('file.json', $json);

С/С++

Чтобы полностью уничтожить объект своей собственной функцией то никак потому, что для его уничтожения его надо выгрузить из памяти, а пока не отработал его внутреняя функция никак. Для уничтожения объекта надо завершить выполнение всех внутренних функций во внешней функции обнулить ссылку на объект удобным способом. Как сказано в первом ответе придет сборщик мусора и освободит память. Вызывая unset ($this) вы уничтожаете указатель ссылающийся на собственный объект, но не сам объект.

Те которые инклудятся можно оставить без наймспейса если нет на него отдельной необходимости (например на разные нейспейсы разные конфиги в одном файле и т.п.). А в файлах модели наверное без неймспейсов будет немного неудобно. В модели я бы оставил неймспейсы. Автолоад с нейспейсами удобно создать с помощью spl.