Ai-je une mauvaise idée du génie logiciel? [fermé]

J'ai une question qui a été soulevée par mon dernier emploi (plutôt stagiaire).

Juste pour mettre les choses en contexte - j'ai 21 ans et j'ai terminé ma deuxième année d'université avant que j'ai eu environ 2 ans d'expérience dans des emplois d'administrateur système / AQ et, fondamentalement, je peux dire que j'ai vu à quel point différent Secteurs informatiques exploités. Revenons à l'heure actuelle et voici que je décroche un stage dans l'une des premières institutions de recherche au Royaume-Uni.

Ce que je dois faire, c'est créer des outils internes en utilisant un mélange de technologies - principalement AWS / Java / Bash - vous obtenez l'image. Tout va bien, je fais mon travail MAIS je ne suis pas content. Pourquoi est-ce parce que je suis censé travailler dans une affaire ponctuelle. C'est créer des choses rapidement, sans passer de temps à concevoir. Mon directeur a explicitement dit qu'il devait "se précipiter" à travers les problèmes à mesure qu'ils surviennent et nous essentiellement. En conséquence, il s'est avéré que les choses devaient être refaites et remaniées et elles ne sont toujours pas parfaites. En ce qui concerne les tests - gardez-le au minimum, tant qu'il semble fonctionner, c'est OK.

Suis-je en faute pour être en désaccord avec cette façon de travailler? Est-ce mal de vouloir penser le système dans son ensemble, puis se concentrer sur les différents composants et voir comment ils pourraient interagir, pour se concentrer sur différents "points clés" qui pourraient s'avérer problématiques à l'avenir? Est-ce un crime de vouloir faire un bon travail et non un "travail rapide"? Est-ce une erreur ou une mauvaise attitude de vouloir rechercher les structures de données applicables à un problème afin que vous puissiez choisir le meilleur en fonction d'un ensemble de problèmes particulier? Au mieux de ma compréhension, le bit "Ingénierie" dans "Génie logiciel" doit faire exactement cela - recherchez votre domaine de problème et trouvez une solution éclairée puis affinez si nécessaire?

Je suis allé à une entrevue dans un bureau d'Arm au Royaume-Uni et ils m'ont montré leur chambre SCRUM et il semblait qu'ils avaient une assez bonne idée de la façon de gérer leur projet - ils avaient un carnet de commandes, ils avaient des mesures quant à la durée de chacun le problème pourrait prendre à résoudre - les choses habituelles pour SCRUM - complètement différentes de la façon dont les choses sont exécutées "ici"

Ai-je construit une mauvaise idée de l'industrie du logiciel en général? J'aimerais entendre vos commentaires à ce sujet. Je veux dire que je suis "entré" dans le développement de logiciels uniquement parce que je veux créer des choses - simples et simples, mais je veux créer des choses de qualité. Je veux voir mon logiciel utilisé dans divers scénarios, je veux le voir à l'épreuve des balles - n'est-ce pas la force motrice de tous les ingénieurs logiciels? Je pense que tout le monde peut être programmeur / codeur en apprenant simplement la syntaxe, mais pour moi, où le vrai plaisir commence, c'est quand vous devez réellement trouver un design réalisable dans le monde réel.

J'avais l'habitude de faire mes travaux universitaires en les regardant simplement et en commençant directement le codage et je pouvais facilement obtenir des notes supérieures à 75% et je n'ai jamais vraiment apprécié le module "cycle de vie du développement logiciel". Mais maintenant, quand j'ai vu dans le monde réel à quel point il est mauvais de travailler sans aucun processus formel et la frustration inhérente à une situation où vous ne savez pas si les exigences vont changer demain (oh, ai-je dit que nous ne avez pas d'analyse des besoins clairement définie?)

J'aime vraiment croire que je viens de décrocher une position où certaines personnes avaient juste besoin d'un singe de code pour faire leur sale boulot et ce n'est pas le cas de la façon dont le monde du logiciel fonctionne dans son ensemble.

Rendre les logiciels réutilisables et à l'épreuve des balles n'est pas le moteur de l'ingénierie logicielle. L'ingénierie consiste à résoudre les problèmes du monde réel de manière optimale dans le cadre des contraintes du monde réel . La plupart des ingénieurs préféreraient travailler sur une Ferrari - mais un break a besoin d'autant d'ingénierie, et la raison pour laquelle un break ne fonctionne pas aussi bien (à certains égards) est due à des contraintes de conception plus difficiles, pas à une ingénierie pire .

Lorsque vous dites que vous voulez faire un "bon travail" plutôt qu'un "travail rapide", la plupart des ingénieurs le font, mais parfois ce qui définit le bien, c'est sa rapidité à l'achèvement. Il n'est donc pas juste de considérer «bon» et «rapide» comme des choix opposés. Ou penser que vous faites un mauvais travail, ou que vous êtes juste un "singe de code", pour faire le meilleur travail possible dans le temps disponible.

Bien sûr, il est tout à fait possible que le processus ne soit pas optimal et ferait mieux avec un peu plus de conception à l'avance. Le test d'acide serait, la manière actuelle de faire les choses crée-t-elle plus de problèmes qu'elle n'en résout pour les utilisateurs , ou est-ce juste un bug pour les développeurs qui doivent travailler de cette façon? Si cela cause réellement des problèmes aux utilisateurs, une partie de votre travail consiste à essayer de démontrer que c'est le cas, et à essayer de convaincre les gens d'un processus légèrement plus contrôlé.

En fait, cela me dérange. Vous êtes dans une profession où vous développez des outils pour les chercheurs, n'est-ce pas? Cependant, on vous dit de rendre ces programmes rapides et de les faire fonctionner de manière minimale. Surprise Surprise. Il s'agit simplement de l'approche typique du chercheur en matière de programmation, l'argent remis à un véritable programmeur.

La principale préoccupation ici étant que le manque de tests en particulier peut être éthiquement douteux si les outils ont un objectif important. Si l'on n'est pas sûr que le logiciel présente des défauts car l'un est limité à un temps de test minimal, cela signifie que PERSONNE n'est tenu responsable de l'état de fonctionnement du logiciel et Atlas hausse les épaules.

Arrêtons-nous et réfléchissons à cela pendant une seconde cependant. Quel type d'outils développez-vous? Si vous développez un logiciel qui modélise les données, il y a un gros dilemme éthique ici. Dans certaines situations, la recherche scientifique conduit à des décisions qui affectent beaucoup de gens à grande échelle.

Supposons un instant le sujet controversé des changements climatiques d'origine humaine. Disons qu'ils ont placé les mêmes normes sur le logiciel de modélisation qu'ils utilisent pour tirer les conclusions qu'ils ont aujourd'hui. Le sujet a un impact important sur la façon dont nous abordons correctement la gestion de l'environnement et la politique internationale.

N'est-il pas éthique de s'assurer que le logiciel de modélisation n'a pas de problèmes majeurs avec ses prédictions?

Tout le problème n'est pas que les gaz à effet de serre réchauffent la terre. Le problème est de savoir si le résultat net des effets de rétroaction est un gain de température accéléré qui, après avoir franchi un seuil, ne serait plus réversible.

Si ce gain se produisait, la preuve d'un résultat net serait marginale, probablement dans la plage d'erreur.

Ainsi, de légères erreurs de calcul, même une méthodologie impliquant le stockage et la récupération de données à l'arrière, pourraient entraîner soit l'ignorance d'un grave problème environnemental à une extrémité de l'échec, soit une politique internationale qui affecte beaucoup de gens (détruit des emplois, détruit des pensions, etc. ) de l'autre.

Alors oui, vous avez raison. Peu m'importe le rythme de la recherche ... Si les chercheurs veulent s'appuyer sur des outils logiciels pour gérer les données et effectuer des calculs pour eux, ils doivent apprendre à attendre que le logiciel soit bien fait. Sinon, ce logiciel devient un point de vulnérabilité dans leurs théories dont ils ne sont pas tenus responsables, ce qui entraîne une inconduite éthique.

Vous n'avez pas la mauvaise idée de ce qu'est le génie logiciel. Cependant, il vous en manque un aspect très important: c'est une industrie de services. Certains d'entre nous commencent à travailler sur un produit pendant des années et passent par la conception, puis de nombreuses itérations avant qu'il ne soit en v1. D'autres doivent produire quelque chose en 3 heures. Cela dépend de qui vous faites l'entretien et de son objectif.

Si vous pouvez produire une application en 3 heures (ou jours) qui fait ce qu'elle est censée faire, pourquoi y consacrer plus de temps à la conception dès le départ? Vous gaspillez simplement de l'argent. Gaspiller de l'argent n'est généralement pas une bonne idée ™.

Comme d'autres l'ont déjà dit, une grande partie de ce qu'est le génie logiciel concerne les «contraintes extrinsèques». par exemple. Temps, budget, service, soutien, satisfaction des demandes idiotes irrationnelles, etc.

Beaucoup d'entre nous (moi y compris) nous sommes lancés dans la programmation en pensant qu'il s'agit de la programmation elle-même - coder de beaux et élégants logiciels dans un vide (ou un vide relatif au moins). C'est rarement le cas. Il peut y avoir de rares emplois universitaires ou en R&D qui s'en approchent, mais pour la plupart, la grande majorité des travaux de développement de logiciels n'a rien à voir avec ça. Surtout dans la phase de maintenance - qui représente généralement plus de 90% de la durée de vie d'un produit - et dans la routine quotidienne du pain et du beurre de la plupart des logiciels commerciaux permanents.

Pendant longtemps, j'ai eu un conflit interne à ce sujet qui m'a souvent rendu mécontent de mon travail (et cela fait partie de ce qui a finalement conduit à un épuisement professionnel l'année dernière). J'ai toujours senti qu'un travail était nul s'il ne s'agissait pas de créer un beau code et de prendre le temps de le faire correctement. Mais vraiment, c'est la réalité - et certaines personnes se développent en fait sur un flux de travail très orienté services. C'est ce qui les rend pragmatiques et utiles. Même si les aspects réels de «pure ingénierie logicielle» d'un projet deviennent relativement précipités et bâclés.

Quoi qu'il en soit, c'est bien que vous remettiez cela en question maintenant. C'est une de ces choses qu'ils n'expliquent jamais vraiment correctement à l'école. Et les entreprises adorent prétendre qu'elles suivent de très bonnes pratiques d'ingénierie même si elles ne le font pas. Astuce: la plupart ne le font pas.

Cela dit, les choses varient. Certaines entreprises (principalement celles pour lesquelles le logiciel est leur activité principale et celles qui travaillent sur des logiciels hautement critiques pour la sécurité tels que les équipements médicaux) suivent un processus d'ingénierie très strict. Mais dans l'ensemble, oui, je vais vous dire maintenant que la plupart des logiciels commerciaux sont relativement bâclés. Il existe généralement un processus formel, mais le respect strict de celui-ci prend presque toujours un siège arrière pour réagir aux commentaires des clients et à d'autres pressions commerciales. Ce n'est pas vraiment de la «négligence» en soi, c'est simplement une utilité pragmatique. L'astuce consiste à trouver votre créneau et à considérer un rôle du point de vue du service qu'il fournit, plutôt que de la fraîcheur de l'aspect "programmation pure".

EDIT : Je pense que je pourrais avoir semblé trop unilatéral dans mon évaluation initiale. Je voudrais ajouter que souvent, il y a aussi de véritables problèmes avec des choses trop bâclées et un manque de bon processus - au point où cela entraîne le projet dans la dette technique et est en fait mauvais pour l'entreprise. Mais voir cela vient avec l'expérience. Le point initial est toujours fondamental: la plupart des logiciels commerciaux aujourd'hui ne sont pas aussi rigoureusement orientés vers l'ingénierie que les puristes le souhaiteraient.

Quelle excellente question! Parfois, vous pouvez faire quelque chose de précieux en étant rapide . C'est généralement le cas dans un laboratoire de recherche où plus vite nous pouvons apprendre ce que nous ne savons pas, mieux nous serons. Le logiciel que vous produisez existe uniquement pour répondre aux questions. C'est du "code à jeter". C'est également le cas des startups qui ne savent pas vraiment ce que veulent les clients. De plus, la première fois que vous faites quelque chose, ce sera merdique. Lisez le Mythical Man-Month .

Parfois, vous pouvez faire quelque chose de précieux en étant bon . C'est généralement le cas avec des logiciels sous film rétractable comme Adobe Photoshop. La recherche a déjà été effectuée il y a des années et maintenant la question est de savoir comment ajouter la liste des fonctionnalités que les clients souhaitent d'une manière qui n'introduise pas de bogues. C'est une question d'architecture, de conception et de test, de test, de test. Le code lui-même est ce qui a de la valeur, pas ce que vous en tirez.

Si vous n'êtes pas satisfait de la recherche (faire le premier de quelque chose, apprendre de nouvelles choses que personne ne connaissait auparavant), essayez le logiciel sous emballage rétractable. En fait, à votre âge, vous devriez essayer autant de choses que possible. Allez prendre des risques! Vous apprendrez beaucoup et vous serez mieux à long terme.

Je pense que vous avez remarqué très tôt dans votre carrière que faire les choses rapidement, sans une conception ou des tests appropriés, a tendance à revenir vous mordre. De toute évidence, vous n'aimez pas cela et vous avez de bonnes raisons de ne pas le faire. Il est ridicule de s'attendre à "se précipiter à travers des problèmes", surtout si vous devez les réexaminer plus tard lorsque les solutions initiales sont incorrectes ou incomplètes. Vous ne pouvez apporter des solutions aux problèmes que si vous les comprenez parfaitement, ce qui prend du temps et une planification minutieuse.

Je vous suggère de faire savoir à vos supérieurs que cela vous dérange et de leur suggérer une meilleure approche pour faire votre travail. S'ils ne sont pas d'accord et veulent que vous continuiez à vous précipiter dans votre travail, je commencerais à chercher du travail ailleurs. Cela n'a aucun sens de faire les choses d'une manière qui ne correspond pas à vos propres normes, et encore moins à une norme de qualité de développement logiciel que l'industrie attend.

Voici mes conseils basés sur mes expériences, j'ai 20 ans et je suis actuellement en stage pour une grande institution financière au Royaume-Uni et j'ai eu les mêmes sentiments que vous aviez il y a quelques mois, ce que j'ai remarqué, c'est que cela peut être dû à la nature de le travail que vous faites.

Ce que je veux dire par là, c'est que vous avez dit:

«Ce que je dois faire, c'est créer des outils internes en utilisant un mélange de technologies - principalement AWS / Java / Bash»

J'ai également dû créer des outils internes pour aider à gérer et automatiser certains processus et le fait est que dans un environnement au rythme rapide, de «petites» choses doivent être mises en œuvre rapidement. Je n'ai pas eu le luxe d'appliquer la plupart des principes d'ingénierie logicielle ou d'algorithmes et de structure de données qui m'ont été enseignés en 2e année, car une version de travail de l'outil était requise en quelques semaines. pas mal du tout car j'ai appris à écrire un meilleur code plus lisible.

Je devais être patient et j'ai récemment fait une rotation dans une nouvelle équipe qui travaille sur une nouvelle itération du système construit en interne utilisé par les utilisateurs 10K + et je peux vous assurer que l'aspect génie logiciel de celui-ci est pris très au sérieux. On m'a dit que je gagnerai une exposition au cycle de vie complet du logiciel, de la capture / analyse des exigences jusqu'à la mise en œuvre et les tests. Je crois que je vais acquérir cette expérience parce que je ne travaille pas sur des outils internes mais que je travaille sur un système à grande échelle avec une large base d'utilisateurs.

Ce que je recommande, c'est que vous soyez patient, que vous finissiez de créer les outils et que vous fassiez un très bon travail afin que vos superviseurs aient plus confiance en vous et vous assignent des tâches plus difficiles qui nécessiteront l'utilisation de principes d'ingénierie logicielle. Acquérir des connaissances supplémentaires en faisant des lectures supplémentaires et en appliquant ces connaissances à ce que vous faites actuellement, je me souviens avoir fouillé toute la bibliothèque de livres électroniques de l'entreprise juste pour approfondir mes connaissances muhahah, de tous les livres que j'ai lus, je sentais que java efficace était très bon livre qui m'a beaucoup aidé.

Soyez patient, investissez massivement dans vos propres connaissances et appliquez-les lorsque cela est possible. Si vous faites du très bon travail, quelqu'un le remarquera bientôt.

Je conviens que la façon dont fonctionne votre travail actuel n'est pas optimale, oui. Cependant, si vous voulez dire que cela ne fonctionne pas du tout, je serais en désaccord avec vous car il y a différents résultats et l'institution est toujours là.

Ma principale question pour vous est de savoir dans quelle mesure vous vous occupez d'incendies qui nécessitent des solutions immédiates faites rapidement de la même manière que de donner les premiers soins à un patient médical par rapport aux demandes qui pourraient être configurées en tant que projets et traitées à une échelle très différente similaire à celle du patient médical. avoir à planifier des tests et diverses procédures qui ne sont pas nécessaires pour le faire immédiatement mais à court terme.

Prendre le temps de bien faire un travail dépend un peu de la maturité de l'organisation ainsi que de l'importance de bien faire quelque chose par rapport à la prétention de le faire.

La question de la recherche des structures de données est de savoir combien de temps ils souhaitent le faire. Si vous voulez prendre une décennie pour rechercher une structure de données qui est tout à fait différente de vouloir quelques heures. Bien que je puisse apprécier le désir d'obtenir la meilleure réponse, il y a quelque chose à dire pour les rendements décroissants après avoir passé un certain temps sur un problème, par exemple, pourriez-vous passer des heures à trouver une solution à FizzBuzz comme vous pouvez essayer de le résoudre dans différentes langues sur divers matériels pour optimiser la vitesse de fonctionnement.

S'il peut être important de faire des recherches, il est également important de fournir quelque chose. Si vous ne livrez pas quelque chose, êtes-vous vraiment bon? Duct Tape Programmer serait plus un exemple sur la façon de faire avancer les choses ici.

Scrum est une méthodologie spécifique que vous pourriez éventuellement essayer d'adopter sur votre lieu de travail actuel. Ne pensez pas que Scrum est une solution miracle. Dans quelles circonstances les projets sous Scrum et Agile peuvent-ils échouer? serait un blog sur ce sujet qui pourrait être intéressant.

Je suppose que vous ne voyez pas à quel point les processus de votre lieu actuel sont informels et que l'herbe est immensément plus verte de l'autre côté où il existe une méthodologie formelle. Bien que cela puisse être mieux là-bas, certaines personnes peuvent préférer ce que vous avez maintenant avec l'immense liberté d'être un cow - boy .

Je pense que votre situation est toujours à l'échelle du monde réel vers moins d'accent sur le côté qualité. Votre préférence va à l'autre bout du monde réel. Les spécifications changent, surmontez-le. Il faut faire les choses.

Envisagez des moyens d'identifier ces types d'entreprises lorsque vous postulez pour votre prochain emploi. Peu d'endroits ont un modèle d'entreprise où ils peuvent se permettre d'avoir des développeurs pour analyser leurs conceptions pour toujours (même les professeurs doivent enseigner.). Les clients paient rarement si votre travail ne quitte pas le tableau effaçable à sec. Je déteste vous voir devenir fou si tôt dans votre carrière.