Je pense que nous sommes tous conscients que nos actions ont des conséquences pour nous-mêmes et, souvent, pour les autres. Je vais parler d'une telle situation qui est pertinent pour les développeurs iPhone.
J'ai dû refuser certains travaux de développement lors de l'écriture Plus l'iPhone 3 de développement. Ce n'est pas une grosse affaire, comme je m'y attendais que cela arrive lorsque j'ai accepté de faire le livre, et je tiens à le voir, car il me dit que notre plate-forme se porte encore bien. Cependant, un nombre étonnant de projets que j'ai refusés ont été de fixer les applications iPhone écrits par les développeurs autre contrat, chose que je ne considère pas comme tel un bon signe.
Même si je n'étais disponible pour prendre le travail, il ya quelque chose de foncièrement mal à l'aise ces situations. Certains développeurs, dont l'identité est inconnue m'a écrit ce code. Ce développeur n'a aucune chance de répondre à mes critiques et moi, à leur tour, n'ont absolument aucune idée de la situation dans laquelle le code a été écrit. Je me sens comme il n'ya pas de bonne façon de souligner les défauts dans le code comme ceci. Pourtant, pour résoudre le problème ou même donner une estimation précise, ces problèmes doivent être identifiés.
Dans un cas récent, le potentiel (et très confiants) client réalité m'a envoyé son code ainsi que la description du problème. Je savais que je ne pouvait pas prendre sur un projet de lourdes jusqu'à ce que le livre est terminé, mais la description du problème semblait être quelque chose que je pourrais être capable d'être corriger rapidement et facilement, alors j'ai regardé le code, ce soir.
Le problème était exactement ce que je pensais que ça allait être fondée sur la description, et je pensais que je serais capable de le fixer avec une douzaine de lignes de code plus quelques pas plus de quelques heures, ce qui serait une victoire pour le client potentiel et les utilisateurs du client qui éprouvaient des problèmes de performance significative avec des volumes relativement faibles de données. Dans une application bien conçue, la fixation de ce problème spécifique ne serait pas touché quelque chose en dehors d'une classe unique ou, au pire, une poignée de classes. Il a été un goulot d'étranglement dans le plus pur «modèle» du code dans le sens MVC. En théorie, tant que je n'ai pas changer la façon dont les données de l'objet a été consulté et mis à jour par d'autres classes, je pouvais changer les détails d'implémentation, comme la façon dont les données ont été persisté, sans nuire à rien.
Vous savez ce qu'ils disent au sujet des théories, non? Elles excellent travail, en théorie. Mais en pratique ...
Alors, oui, cette théorie n'a pas marché. J'ai commencé à regarder le reste du projet de recherche croisée potentielle depenencies et j'ai constaté que mon hypothèse était totalement et complètement faux. Le magasin de données sous-jacent a été non seulement vended travers la classe de données, il était accessible directement par littéralement des douzaines de classes. En fait, tout le code persistance réelle - à la fois charger et sauver - (à l'exception de encodeWithCoder: et decodeWithCoder:) était contenue dans les classes de contrôleur. Et il y avait des douzaines de ces classes de contrôleur, dont beaucoup étaient presque identiques, sauf pour une poignée de lignes, ce qui semblait indiquer un manque général de conception ou de prévoyance. Le cœur du problème a donc été faite de manière significative plus difficiles à corriger par un besoin désespéré et sans contrepartie pour le refactoring. Il y avait, littéralement, des classes de plusieurs dizaines qui auraient pu être écrites comme une classe unique ou, au pire, un couple de sous-classes avec un parent commun. L'ensemble du projet ressemblait jetés ensemble par un développeur tragiquement inexpérimentés, ou celui qui n'a pas eu toute utilisation de "cette merde de nouveaux OO fangled". Sérieusement, il devrait y avoir un lien à ce projet sur le Wikipedia de code spaghetti entrée, dans la section sur les "spaghetti aux boulettes de viande". La lecture du projet m'a fait sentir comme si j'étais dans un équivalent de programmation étrange de Poe loi, Je ne pense pas que je pouvais créer intentionnellement de code de cette alambiqué.
Maintenant, je voudrais pouvoir dire que je n'avais jamais vu, ni écrite du mauvais code, mais ce ne serait pas vrai. J'ai vu beaucoup de mauvais code au fil des ans et ont écrit plus que ce que j'avais bien l'admettre. Malgré cela, cependant, ce code a été pire que la plupart de ce que j'ai vu, et c'est peu dire, étant donné que mon travail depuis plusieurs années a été la résolution de problèmes dans le code des autres.
Après une couple d'heures, je suis venu à la conclusion inévitable que ce travail a été au-delà de ma capacité à prendre en ce moment. Je suis presque certain que ce serait plus de travail pour essayer de résoudre la multitude de problèmes dans ce code que ce serait à juste réécrire l'application à partir de zéro. Même s'ils ne sont pas, le résultat final serait certainement mieux. Par souci d'équité pour le client potentiel, je devais expliquer pourquoi je devais baisser le projet, quelque chose qui semble de nature à causer des problèmes pour le développeur précédent. Je ne pouvais pas, en bonne conscience, ne lui dites pas, cependant. Je l'ai fait mettre dans des conditions beaucoup plus diplomatique que je fais ici dans mon blog, au moins, où j'ai parfois personnifient le fait que «tact» est un mot de quatre lettres.
La forte demande pour les développeurs iPhone a fait un gagne-pain rentable et, je pense, a causé beaucoup de gens à offrir leurs services en tant que développeurs iPhone sans expérience vraiment adéquat. Enfer, je travaille avec le SDK aussi longtemps que quiconque en dehors d'Apple, et je me sens parfois comme je n'ai pas de "véritable expérience adéquate» avec lui - c'est le péril d'une nouvelle technologie, je suppose. Peu importe, quand vous êtes en développement pour un client ou un employeur plutôt que vous, vous avez vraiment besoin d'être conscient qu'il y aura des développeurs en aval concernés par la décision que vous faites ou ne réalisent pas sont là en premier lieu. Lorsque vous coupez un coin pour gagner du temps ou de ne pas utiliser un bon design, car vous ne savez pas tous les soins mieux ou pas, cette décision peut très bien avoir des conséquences importantes pour votre client et pour d'autres développeurs qui héritent de votre code.
Architecture de l'application de bonnes et de l'écriture de code de bonnes prend un peu plus dans le court terme, mais dans le long terme, elle nécessite beaucoup moins d'un investissement de temps à entretenir. Oui, je sais que la plupart d'entre nous le projet de loi à l'heure et l'écriture du mauvais code est beaucoup plus rentable que d'écrire du bon code, mais ne pas le faire. Sérieusement. C'est pire que d'être simplement ignorants de la façon d'écrire du bon code. Malgré l'économie, il ne manque pas de travail de développement iPhone en ce moment, et même si ce n'était pas le cas, vous devez à vos clients pour leur donner le meilleur code que vous êtes capable d'écrire.
Addendum: Basé sur certains des commentaires, je crains que ce poste est apparu comme un peu plus de jugement que prévu. Contrat de développement logiciel, en particulier pour les clients qui ne sont pas familiers avec le processus, est extraordinairement difficile. Aucun développeur contrat a jamais, jamais créé un parfaitement conçu, sans bug application. Dans le monde réel, vous avez à traiter avec des délais, des demandes déraisonnables, et des tonnes d'autres facteurs qui agissent contre vous livrera une application parfaite. Je ne suis pas insensible à cela du tout, comme je l'ai vécu moi-même à d'innombrables reprises.
J'ai voulu ce que comme un récit édifiant de vous donner quelque chose à penser avant de décider de couper un coin ou de sauter le faire réécrire vous savez que vous devez faire, non pas comme un acte d'accusation de quiconque. Croyez-moi, en regardant certains de mes travaux sous contrat au début, j'ai quelques mots assez dures pour moi.
Un des traits les plus importants dans un développeur est la volonté d'accepter que peu importe comment vous êtes bon, vous faites des erreurs. Vous ne cessera jamais de faire des erreurs et vous ne cesserez jamais d'être en mesure d'apprendre de ces erreurs. Parfois, vous pouvez même apprendre des erreurs des autres et de vous épargner un peu la douleur.
J'ai dû refuser certains travaux de développement lors de l'écriture Plus l'iPhone 3 de développement. Ce n'est pas une grosse affaire, comme je m'y attendais que cela arrive lorsque j'ai accepté de faire le livre, et je tiens à le voir, car il me dit que notre plate-forme se porte encore bien. Cependant, un nombre étonnant de projets que j'ai refusés ont été de fixer les applications iPhone écrits par les développeurs autre contrat, chose que je ne considère pas comme tel un bon signe.
Même si je n'étais disponible pour prendre le travail, il ya quelque chose de foncièrement mal à l'aise ces situations. Certains développeurs, dont l'identité est inconnue m'a écrit ce code. Ce développeur n'a aucune chance de répondre à mes critiques et moi, à leur tour, n'ont absolument aucune idée de la situation dans laquelle le code a été écrit. Je me sens comme il n'ya pas de bonne façon de souligner les défauts dans le code comme ceci. Pourtant, pour résoudre le problème ou même donner une estimation précise, ces problèmes doivent être identifiés.
Dans un cas récent, le potentiel (et très confiants) client réalité m'a envoyé son code ainsi que la description du problème. Je savais que je ne pouvait pas prendre sur un projet de lourdes jusqu'à ce que le livre est terminé, mais la description du problème semblait être quelque chose que je pourrais être capable d'être corriger rapidement et facilement, alors j'ai regardé le code, ce soir.
Le problème était exactement ce que je pensais que ça allait être fondée sur la description, et je pensais que je serais capable de le fixer avec une douzaine de lignes de code plus quelques pas plus de quelques heures, ce qui serait une victoire pour le client potentiel et les utilisateurs du client qui éprouvaient des problèmes de performance significative avec des volumes relativement faibles de données. Dans une application bien conçue, la fixation de ce problème spécifique ne serait pas touché quelque chose en dehors d'une classe unique ou, au pire, une poignée de classes. Il a été un goulot d'étranglement dans le plus pur «modèle» du code dans le sens MVC. En théorie, tant que je n'ai pas changer la façon dont les données de l'objet a été consulté et mis à jour par d'autres classes, je pouvais changer les détails d'implémentation, comme la façon dont les données ont été persisté, sans nuire à rien.
Vous savez ce qu'ils disent au sujet des théories, non? Elles excellent travail, en théorie. Mais en pratique ...
Alors, oui, cette théorie n'a pas marché. J'ai commencé à regarder le reste du projet de recherche croisée potentielle depenencies et j'ai constaté que mon hypothèse était totalement et complètement faux. Le magasin de données sous-jacent a été non seulement vended travers la classe de données, il était accessible directement par littéralement des douzaines de classes. En fait, tout le code persistance réelle - à la fois charger et sauver - (à l'exception de encodeWithCoder: et decodeWithCoder:) était contenue dans les classes de contrôleur. Et il y avait des douzaines de ces classes de contrôleur, dont beaucoup étaient presque identiques, sauf pour une poignée de lignes, ce qui semblait indiquer un manque général de conception ou de prévoyance. Le cœur du problème a donc été faite de manière significative plus difficiles à corriger par un besoin désespéré et sans contrepartie pour le refactoring. Il y avait, littéralement, des classes de plusieurs dizaines qui auraient pu être écrites comme une classe unique ou, au pire, un couple de sous-classes avec un parent commun. L'ensemble du projet ressemblait jetés ensemble par un développeur tragiquement inexpérimentés, ou celui qui n'a pas eu toute utilisation de "cette merde de nouveaux OO fangled". Sérieusement, il devrait y avoir un lien à ce projet sur le Wikipedia de code spaghetti entrée, dans la section sur les "spaghetti aux boulettes de viande". La lecture du projet m'a fait sentir comme si j'étais dans un équivalent de programmation étrange de Poe loi, Je ne pense pas que je pouvais créer intentionnellement de code de cette alambiqué.
Maintenant, je voudrais pouvoir dire que je n'avais jamais vu, ni écrite du mauvais code, mais ce ne serait pas vrai. J'ai vu beaucoup de mauvais code au fil des ans et ont écrit plus que ce que j'avais bien l'admettre. Malgré cela, cependant, ce code a été pire que la plupart de ce que j'ai vu, et c'est peu dire, étant donné que mon travail depuis plusieurs années a été la résolution de problèmes dans le code des autres.
Après une couple d'heures, je suis venu à la conclusion inévitable que ce travail a été au-delà de ma capacité à prendre en ce moment. Je suis presque certain que ce serait plus de travail pour essayer de résoudre la multitude de problèmes dans ce code que ce serait à juste réécrire l'application à partir de zéro. Même s'ils ne sont pas, le résultat final serait certainement mieux. Par souci d'équité pour le client potentiel, je devais expliquer pourquoi je devais baisser le projet, quelque chose qui semble de nature à causer des problèmes pour le développeur précédent. Je ne pouvais pas, en bonne conscience, ne lui dites pas, cependant. Je l'ai fait mettre dans des conditions beaucoup plus diplomatique que je fais ici dans mon blog, au moins, où j'ai parfois personnifient le fait que «tact» est un mot de quatre lettres.
La forte demande pour les développeurs iPhone a fait un gagne-pain rentable et, je pense, a causé beaucoup de gens à offrir leurs services en tant que développeurs iPhone sans expérience vraiment adéquat. Enfer, je travaille avec le SDK aussi longtemps que quiconque en dehors d'Apple, et je me sens parfois comme je n'ai pas de "véritable expérience adéquate» avec lui - c'est le péril d'une nouvelle technologie, je suppose. Peu importe, quand vous êtes en développement pour un client ou un employeur plutôt que vous, vous avez vraiment besoin d'être conscient qu'il y aura des développeurs en aval concernés par la décision que vous faites ou ne réalisent pas sont là en premier lieu. Lorsque vous coupez un coin pour gagner du temps ou de ne pas utiliser un bon design, car vous ne savez pas tous les soins mieux ou pas, cette décision peut très bien avoir des conséquences importantes pour votre client et pour d'autres développeurs qui héritent de votre code.
Architecture de l'application de bonnes et de l'écriture de code de bonnes prend un peu plus dans le court terme, mais dans le long terme, elle nécessite beaucoup moins d'un investissement de temps à entretenir. Oui, je sais que la plupart d'entre nous le projet de loi à l'heure et l'écriture du mauvais code est beaucoup plus rentable que d'écrire du bon code, mais ne pas le faire. Sérieusement. C'est pire que d'être simplement ignorants de la façon d'écrire du bon code. Malgré l'économie, il ne manque pas de travail de développement iPhone en ce moment, et même si ce n'était pas le cas, vous devez à vos clients pour leur donner le meilleur code que vous êtes capable d'écrire.
Addendum: Basé sur certains des commentaires, je crains que ce poste est apparu comme un peu plus de jugement que prévu. Contrat de développement logiciel, en particulier pour les clients qui ne sont pas familiers avec le processus, est extraordinairement difficile. Aucun développeur contrat a jamais, jamais créé un parfaitement conçu, sans bug application. Dans le monde réel, vous avez à traiter avec des délais, des demandes déraisonnables, et des tonnes d'autres facteurs qui agissent contre vous livrera une application parfaite. Je ne suis pas insensible à cela du tout, comme je l'ai vécu moi-même à d'innombrables reprises.
J'ai voulu ce que comme un récit édifiant de vous donner quelque chose à penser avant de décider de couper un coin ou de sauter le faire réécrire vous savez que vous devez faire, non pas comme un acte d'accusation de quiconque. Croyez-moi, en regardant certains de mes travaux sous contrat au début, j'ai quelques mots assez dures pour moi.
Un des traits les plus importants dans un développeur est la volonté d'accepter que peu importe comment vous êtes bon, vous faites des erreurs. Vous ne cessera jamais de faire des erreurs et vous ne cesserez jamais d'être en mesure d'apprendre de ces erreurs. Parfois, vous pouvez même apprendre des erreurs des autres et de vous épargner un peu la douleur.
Aucun commentaire:
Enregistrer un commentaire